Is it a problem if an Intrusion Protection System (IPS) does not validate TCP checksums? If you aren't familiar with the concept of TCP checksums, they're used as a means to ensure that data in the TCP header and TCP payload has not gotten corrupted in transit. This is done by taking the one's complement of all 16-bit fields of the TCP header and payload layers and some select fields from the IP header, adding them up, and placing the value in the checksum field of the TCP header. A receiving host performs this same calculation. If the value that the receiving host calculates matches the one found in the delivered TCP header checksum, the packet is accepted. If there is a mismatch, the packet is silently dropped.
Now, it might be tempting for an IPS solution to skip this validation process to save some time. I used to think that the only harm that could come from this was a false positive. For instance, let's say that someone sent a TCP segment with an invalid TCP checksum that contains malicious content "EVILSTUFF" covered by a rule or signature. The IPS would alert, but the end host would drop the packet. That's annoying but not harmful.
But, after some consideration, there are some ruses we can use for evasions. What if we can fool the IPS into resetting a session by sending a TCP reset with a bad checksum and then sending segments with malicious content? In this case, the IPS prematurely terminates the session with the bad reset, but the receiving host keeps the session open to receive the malicious data. Let's take a look at how this can be done. I'll use Snort to demonstrate the concept by using a default configuration that validates TCP checksums and later one that disables TCP checksum validation.
I've crafted a session and emulated the client-side of the conversation using Scapy. Here is the tcpdump output of the client's part of the session.
Assume that we have a Snort rule that looks for the content of "EVILSTUFF" in the payload. Segments 1 and 2 are part of the three-way handshake that establishes the session. Segment 3 is a bogus reset segment since it has an invalid checksum. Segment 4 sends contains half of the malicious content and segment 5 contains the other half. When the malicious content is split into two separate segments, the IPS is forced to reassemble the content. Finally, we send a valid reset in segment 6.
Let's run Snort using the pcap named "badchksum-rst.pcap" that captured both sides of the session created from the Scapy script. First, let's use the following configuration that defaults to performing TCP checksums.
This pertinent portion of the configuration simply uses the default stream5 configuration and contains a single Snort rule that looks for the uricontent of "EVILSTUFF" in an established session going to destination port 80. This configuration is stored in a file named "normal.conf".
Next, we'll run it using the following configuration.
The only difference is that I've added a configuration option to disable TCP checksum validation. This configuration is stored in a file named "turnoff-checksums.conf".
This first run using the default configuration of checksum validation generates an alert.
snort –A console –q –K none –c normal.conf –r badchksum-rst.pcap
07/04-21:56:59.145909 [**][1:123435:0] EVILSTUFF [**] [Priority: 0] {TCP} 192.168.1.100:18484 -> 192.168.1.199:80
However, the second run fails to alert using the configuration where TCP checksum validation has been disabled.
snort –A console –q –K none –c turnoff-checksums.conf –r badchksum-rst.pcap
This demonstrates that it is fairly easy to evade an IPS that fails to perform TCP checksum validation. There are several more tricks that can cause IPS evasions when TCP checksums are not validated. I'll demonstrate one or more in upcoming posts.
If you're interested in learning packet crafting such as the session I created for this experiment, I'm teaching a one-day SANS Scapy course at SANS Network Security at 2010 in Las Vegas in September.
I still have no students signed up for the course and I'm getting desperate. I've got 6 copies of the book I co-authored with Stephen Northcutt "Network Intrusion Detection: An Analyst's Handbook" sitting in a box in my basement gathering cricket legs. If you are one of the first six students to sign up and actually show up, I'll give you one of these copies free – cricket legs and all! And, I'll even sign it for you if you'd like if you feel it won't devalue it! Just tweet me - judy_novak - to let me know you've signed up!
