V |
V |
Pointer 26 |
26 Bytes |
bytes into DNS |
|
Payload |
|
Look at the hex output. You will see the query name (in bold) of evasive mode. The name starts, as before, with a label of 07 followed by the first node of the query. What had previously been all lowercase letters in "version" now is "Version". This would successfully elude any string matching software that does not do uppercase/lowercase conversions.
That is not the entirety of the ruse used here. Look at the next byte: c0. A label has a maximum value of 63 and a hexadecimal c0 is 192 when converted to decimal. Any time that a label has the two high-order bits of the byte set to 1 (a hex c), it is considered a pointer. A pointer is the number of bytes into the DNS message where the next label (or pointer) is to be found. In this case, we see that the pointer is a hexadecimal 1a or a decimal 26. Therefore, we have to count 26 bytes from the beginning of the DNS message to find the next node. The DNS message is delimited between the < > on the left side of the output.
Moving 26 bytes into the DNS message directs us to the string beginning with 0442 494e 4400. The 04 is the label 26 bytes into the DNS message, and as expected, it is followed by 4 bytes that represent the string "BIND". The query then ends when a label of 00 is encountered. It appears that resolution of the query resumes at the next byte after the first pointer in the query name. This brings us back to the string "0010 0003" that represents the query type of TXT and a query class of CHAOS. This query elicits the version of BIND running on the queried DNS server if the DNS server does not prevent queries for the version of BIND.
Sidestep can be found at www.robertgraham.com/tmp/sidestep.html.
Introduction to Packet Dissection Using TCPdump
When you run TCPdump in standard mode, it will dump the most pertinent fields in the packet. More fields will be collected than displayed in the default 68 bytes of capture (14 bytes for Ethernet frame header and the remainder for the IP packet). Yet, all of the fields will not be displayed unless you ask for TCPdump to display the output in hexadecimal mode using the –x command line option. The first thing that you have to do before attempting any kind of packet dissection is arm yourself with the standard layouts of the various kinds of TCP/IP headers such as IP, TCP, UDP, and ICMP. There are many sources of these including the RFCs.
Look at the following output to see a sample of hexadecimal output from TCPdump using the –x command line option:
11:55:52.069484 192.168.143.5 > 192.168.143.101: icmp: echo request
4500 0054 064b 0000 4001 bc12 c0a8 8f05 c0a8 8f65 0800 620a 850a 0000 889f 4b39 510f 0100 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819
It looks like a big jumble of garbage at first glance. Let's begin methodically to describe the output. First, each character you see is a hexadecimal character, as you might have astutely intuited from the fact that we are doing hex output. (Okay, enough sarcasm.) Each hex
character can have a value of 0 to 0xf, which corresponds to 0 to 15 decimal. Again, the 0x notation means hexadeci-mal. And, each hex character is 4 bits, also known as a nibble. That means two hex characters are 8 bits or one byte. Finally, each row of hex dumped by TCPdump has 16 bytes or 32 hex characters.
The trick is "superimposing" this hex output over a standard layout of the fields. In this case, we are looking at an IP header followed by some embedded protocol that we will discover as we progress. Take a look at Figure 7.1. It shows the standard IP header layout that we've examined several times before in the book. Let's just make sure we can look at a field or two before we move on. For instance, the first field you see in the IP header layout is the IP version number, which is 4 bits long. If we look at the previous hex dump, we see that the first hex character is a 4. This is the IP version number or IP version 4.
Figure 7.1. IP header layout.
That was fairly simple. Let's try something a little more advanced. Another very important field is the protocol field found in the IP header. This tells us the embedded protocol that follows the IP header. If you look at Figure 7.1, you'll see that the 8-bit protocol field is found in the third row of the IP header. This layout is different from the hex dump because each row contains 32 bits of output or 4 bytes. No matter, we can still find the displacement of the protocol field from the beginning of the IP header (again, another annoying reminder that we start counting at offset 0). So, each row contains 4 bytes, and we find the protocol is located in the 9th byte offset of the IP header. The 9th byte offset found in the hex dump is 01. A value of 01 in this field means that the ICMP protocol follows the IP header. Other common values that we will examine are a value of 06 means TCP follows, and a hex 11 or decimal 17 means that UDP follows the IP header.