Nail in the TCP Options Coffin

I just listened to the relevant part of a recent SANS Webcast that mentioned my response to their conspiracy theory on SYN ACK and other packets with weird TCP options. At first all I wanted to do with this post was link to Michal Zalewski's Museum of Broken Packets and say that SANS ISC is wasting time on a non-issue. Then I started reading some of the MOBP entries. I nearly fell out of my chair when I read this.

Exhibit 7: DoS tool changes into DoS exploit

Internet Protocol Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x6fbb
Flags: 0x04 (DF)
Fragment offset: 0
Time to live: 127
Protocol: TCP (0x06)
Header checksum: 0x63b6 (correct)
Source: 64.190.25.48 (64.190.25.48)
Destination: XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

Transmission Control Protocol, Src Port: 1113 (1113), Dst Port: 490 (490),
 Seq: 269484601, Ack: 0
Source port: 1113 (1113)
Destination port: 490 (490)
Sequence number: 269484601
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 16384
Checksum: 0x023b (correct)
Options: (8 bytes)

Maximum segment size: 1460 bytes
NOP
Maximum segment size (option length = 4 bytes says option goes past end of options)

0000 XX XX XX XX XX XX XX XX XX XX XX XX 08 00 45 00 ..............E.
0010 00 30 6f bb 40 00 7f 06 63 b6 40 be 19 30 XX XX .0o.@...c.@.....
0020 XX XX 04 59 01 ea 10 10 02 39 00 00 00 00 70 02 ...Y.....9....p.
0030 40 00 02 3b 00 00 02 04 05 b4 01 02 04 03 .. .. @..;............

Yes, those last eight bytes are exactly the same as the TCP options in the SANS packet on their slide.

Michal explains:

This one comes from Andy Brown, who "does security" for a large web portal. It is a nice example of how simple error in DoS tool turned it into potential DoS exploit, and that conspiration theory is not always the best answer :). The packet you see above is generated by a DoS SYN tool called Juno-z. This tool was used against their site. As Andy describes, the fun is in the TCP options: 0x020405B4 MSS=1460, 0x01020403 NOP, MSS=0x03??

Normally the NOP option (0x01) is used to pad options so they lie on 4-byte boundaries, causing the actual MSS value to lie conveniently on a 16-bit boundary. Here, it's not - this NOP causes MSS value to end past the end of this packet. Might cause some dumb stack to have a bus/alignment fetch error because the MSS is shifted. Also, it could cause a dumb stack to read past the end of the packet causing a segmentation fault. Turns out, this was all unintentional - I talked to the author, and it was a coding glitch :-)

Here is juno-z. Notice dre mentioned juno-z and bang.c as tools that produce malformed packets. Apparently the real victims in this DoS attack repeated the bad TCP options they saw.

So, between my previous post and this one, I've identified the real DoS victim (compton.ameri.ca), the botnet C&C ordering a related attack, (thanks to the ShadowServer project), and the actual tool used to conduct the attack. I think it's time for SANS ISC to give up on this one. You are not seeing scanning, you are not seeing OS identification, you are not seeing another grand conspiracy whose secret lies in TCP options. You're seeing traffic caused by SYN floods.