Tunneling ATI Flows Using TCP over DNS
Although the name sounds a bit uncanny at first, tunneling actual transport-layer payload over DNS can be a great way of evading firewalls and security systems in general.
The basic idea behind this type of tunneling method is that the malicious data is sent as part of seemingly benign DNS query requests and responses. More precisely, the client payload is generally sent in the domain name field of the DNS query for a TXT type entry while the server payload is sent via the TXT data field of the DNS response corresponding to the query.
Ixia’s Application and Threat Intelligence (ATI) team recently created an implementation to emulate this type of attack. As a starting reference point for our implementation, we’ve used the AnalogBit1 implementation of TCP over DNS, which uses as default a TXT type query (a CNAME type query can also be used but it has less advantages to the amount of data it can carry).
The implementation supports 3 types of encoding for the domain name payload and one other type called TextEncoding, which basically uses all of the valid characters for the TXT payload. The encodings are summarized in Table 1:
Table 1. Data Encodings Used in TCP Over DNS
|Encoding Name||Base||Character set|
Each exchange of data is made through a pair of DNS Query/Response messages where the actual payload may be present in the query, response, or both of the messages depending on which sides of the communication are sending data.
To facilitate data framing and tracking, a 6-byte header is added to each chunk of data. The structure of this header is present in Table 2.
Table 2. TCP Over DNS Packet Header
|Client ID||2 bytes||A numeric identifier used for tracking the current client that’s communicating with the TCP-Over-DNS-enabled server.|
|Packet ID||1 byte||This field identifies the current packet being sent.|
|Last Packet ID Seen||1 byte||Identifier used as an acknowledgement and retransmission mechanism for packets.|
|Flags||1 byte||Special flags that are set to indicate certain operations in the current data flow. This field may be set to any OR combination of the following values:
|Checksum||1 byte||Checksum field calculated by summing up all of the header fields along with the actual values of the data payload and keeping the least significant byte of the result.|
Also, to be able to distinguish between the supported domain name encodings, the first character in the domain is used and may take on the following values:
- “a” - Base16Alpha Encoding
- “b” - Base63 Encoding
- “c” - Hex0x20Hack Encoding
The AnalogBit implementation of TCP Over DNS also supports a compression scheme for the actual payload data based on the 7Zip LZMA algorithm.
Dissecting a TCP Over DNS packet
Having been acquainted with the basic structure of the protocol, let’s now look at an example presented in Fig. 1.
Fig. 1. Example TCP Over DNS Packet
So, what can we tell from analyzing this particular DNS Query? First of all, as we’ve mentioned before, the actual encoded payload is found in the domain name, which in this case is:
Quite odd for a domain name but perfectly legal from a protocol perspective. Next, we assemble the actual encoded data we’re interested in by removing the domain suffix (ixiacom.com) and the dots between the subdomains:
Next, we see that the first character is ‘a’ meaning Base16Alpha encoding. So, after removing the ‘a’ character and decoding according to the encoding scheme, we get:
|\x28\x7B\x01\x00\x00\xA2\xD6\x01\x00#\x91F\xCB+\x96\xF1\xF6\x83R*\x95\xFF)\xFB\xFB:....(more data, excluded for brevity)...|
Doing that for the next packet in the series, we get:
|\x28\x7B\x02\x00\x00\xBB\xD9\xBA\x9E\x8C\xF8\xE4\x89Q\xCD\x9C\xF6.\x97\xAF\r@\x1C...(more data, excluded for brevity)...|
From this decoding, we can identify some of the header-specific fields. The first two bytes of each packet identify the client and will remain constant throughout the conversation. The next byte (\x01 for the first packet and \x02 for the second) identifies the packet number and is incremented accordingly. The next byte (set to \x00 in both packets) corresponds to the last packet ID seen from the other side, which in this case is 0 because the server hasn’t sent any data yet. The next byte after that represents the flags byte and is set to zero meaning a non-special packet, while the last byte represents the checksum.
After this 6-byte header, the packet being the first packet in a flow that’s using LZMA compression, a 2-byte little endian uncompressed data length field is present. After that comes the actual LZMA compressed data.
Recomposing all of the data packets and decompressing the LZMA compressed payload, we obtain the original payload (in this case a typical HTTP request):
GET / HTTP/1.1
Host: 10.215.165.54…(more data, excluded for brevity)...
ATI support for TCP Over DNS
The TCP Over DNS protocol is supported in our most recent ATI release as both a standalone flow with granular actions (Single Request/Single Response/Tunnel Data), as well as an L7 transport protocol option through which any other ATI flow can be tunneled. Also, all 3 types of domain name encodings are supported so that multiple variants of the protocol can be emulated.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) program provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.