[Maarten Van Horenbeeck] [Information Security] [Resources]

Entity tags as an HTTP covert channel

During a recent penetration test I was faced with an issue. I obtained access to a network and needed to "smuggle" out a certain binary file. However, DNS was not an option as resolution could only be performed on the HTTP proxies. In addition, we wished to avoid audit activitites taking place after the test identifying what data exactly travelled the network.

With HTTP Tunneling, this is usually difficult to achieve. Most of these tools perform tunneling either through a GET or POST request that contains the actual data in the URI request string. This means that after the fact, it is possible to identify what has been tunneled. The request string is often stored in proxy logs and can easily be retrieved.

In HTTP however, there is a certain interaction between the "Etag" header (on the server side) and "Match-If-None" (and some related tags, on the client side). Upon a connection, a server can provide an Etag, or entity-tag, which is used by the client to identify the version it has in its cache. Proxies can also put this field to use.

As is the case with e.g. basic authentication, these headers can be lengthy and offer good performance in sending through data. More importantly, the headers themselves are usually not logged. For the Etag header, no particular format is described. It is merely a random value contained by "" thatt identifies the entity and "may" be used for caching.

So, I put it to use a bit differently. I split up a file into small groups of bytes and launched requests through the proxy with these parts of the file (base64 encoded) as an Etag header. On the other end I had an application running which received each of the Etags and stored them to a file locally.

Naturally, the proxy would normally have cached my requests, if they were for one file, so I added a return "no-cache" header in the response. One disadvantage with this method is that in your proxy logs, you will have a high amount of GET requests with very little content. An example:


1148834194.664    258 10.0.0.1 TCP_MISS/200 64 GET
http://64.246.44.158/file.txt - DIRECT/64.246.44.158 -

1148834195.073    258 10.0.0.1 TCP_MISS/200 64 GET
http://64.246.44.158/file.txt - DIRECT/64.246.44.158 -

This is quite apparent even to the untrained eye. As such, I used the "byte-range" header in the request so that they would be logged as 206 entries, and had the server create a random ASCII text file so that the size of the transactions would be higher. This is a bit less obvious, as 206 means that a partial transfer is taking place - it could just be a client that's downloading a file in pieces.

Potential countermeasures that can be implemented:

Implement stateful Etag checking on perimeter proxies. In general, an If-None-Match should always match the previous Etag seen for a certain entity. Nevertheless, as some hosts will have made the initial request from the outside, the first Etag may not be available and will need to be accepted at face value.
Perform Etag inspection; in general, Etags have a format of "4d008e-c87-43249525" for Apache servers. The Etags wondjina uses by default are quite a bit larger to allow for quicker transfers. If speed is not a concern, nothing will stop you from fitting it into this type of header.
Drop Etags and instead rely on the other caching mechanisms we have in place. You could also use HTTP/1.0 requests which do not support Etags.

For this purpose, I wrote a small piece of Perl code that could essentially get the job done. It is however not a software tool, as such don't expect it to work in all circumstances. It is called Wondjina.

"In Aboriginal mythology, the Wondjina (or wandjina) were cloud and rain
 spirits who, during the Dream time, painted their images (as humans but
 without mouths) on cave walls. Their ghosts still exist in small ponds."
                        http://en.wikipedia.org/wiki/Wondjina

Do note that while in fact, Wondjina only tunnels out (one way traffic) the matching between Etag and if-none-match is ideal for bidirectional tunneling. Wondjina has a lot of limitations that depending on the situation you may require to run this succesfully:

In essence, if you send 10 different requests to a proxy, nothing guarantees that these will arrive in that order. If they don't, the file at the recipient side may be corrupted. This can be solved by implementing "protocol"; a set of rules known by both sides of the connection. In itself this will make it easier to detect the tunneling, but these can ofcourse be defined at both sites by the penetration tester to prevent this.
Wondjinad just keeps on running and passively stores all incoming information. If you want to tunnel multiple files, you'd need to build in some type of "stop" code that both client and server recognize. Once again, this would mean implementing a protocol, with all advantages and disadvantages that come with it.

If you'd like to give it a try, get wondjina here.
Read basic use instructions and documentation here.

Entity tags as an HTTP covert channel

Articles and discussions on HTTP tunneling

Links to HTTP tunneling tools and services

Reference works

Books that could be of help