Potential Evasion Where IPS Fails to Validate TCP Checksums

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} ->

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!


  1. TCP checksum is validated at firewall normally. Thus reducing the risk at the production environment.

    However, I do agree that it is still a weakness at IPS (if TCP checksum is turn off).

  2. Curses! Hope you get more than enough students for your course. It sounds fascinatnig and educational, I sadly have no chance of making it to SANS NS at all this year, being pretty busy and living outside the states and all. I wish I could though.

    Are you able to reply to this comment on where to find and buy your book?

  3. If IPS removes a session from sessions table prematurely due to false session reset packet, would not it alert on or drop following packets within the same session based on the fact that they are out of state?

  4. You can also play with the TTL field to make a packet reach the IPS device but not the final target.

    I don't know if that apply to Snort but you can also fool some IPS devices by sending some valid TCP payload only for them (bad checksum, short TTL, ...) and then re-sending the same frame (ie. same TCP seq) with malicious TCP¨payload. The final target will only process the malicious content while the IPS may not detect it because it will only look at the valid one.

  5. Irina - You can buy the book on Amazon or anywhere else they sell books. Sorry you can't make the class.

  6. Dmitri - Funny you mention that - Snort does alert on this:
    07/12-13:52:19.010514 [**] [129:8:1] Data sent on stream after TCP Reset [**] [Priority: 3] {TCP} ->

    But, I wouldn't expect the IPS to do this. I would think most IPS solutions would close and clean up the session information. What if I wait 30 seconds and second the malicious payload? There is some efficiency to be gained by cleaning up immediately especially when the IPS is working at maximum throughput.

  7. Jet - Do all firewalls validate TCP checksums? I figured they validated IP checksums, but wasn't aware they performed TCP checksum validation as well. I guess that would certainly foil this ruse. But, I'd still prefer not to rely on the firewall.

  8. Fascinating stuff Judy! I have already been to SANS training this year...so my budget is already blown....otherwise I'd be signing up for your class.

    However, I will be purchasing your book at Amazon.


  9. I don't quite see the point. Please help me out here: Did you do a packet capture at the end side? What packets actually reached their destinations? Would an "attack" after an RST reach its destination?

    In the checksum-checking scenario, the IPS would drop everything from the RST packet on.

    In the checksum-ignoring scenario, the IPS would drop the RST packet for sure. The next packets would depend on the rule.

    Do you have a higher-priority Snort rule that matches out-of-state packets that does not raise an alert? Could this be Snort-specific?

  10. In the above scenario, all packets reach the IDS/IPS and since I used Snort as an IDS, all packets reach the destination host.

    The out-of-state packets got a "Data sent on stream after TCP Reset" Snort alert, but I do believe that is Snort-specific.

  11. Good stuff to keep us thinking creatively. I hope people start singing up for you class soon!

  12. For those of you considering buying the book - please understand that it is several years old and doesn't cover the topics I've been posting. Just wanted to make sure that I wasn't misleading you into buying something that may not be useful to you.

  13. Excellent stuff as usual, Judy. "Network Intrusion Detection" was one of the first books I bought when I got started, and I was very glad I did. As Mike would say, "I'm not worthy...I'm not worthy...." =-)

  14. Hiya Judy! Why don't you and SANS create a CBT version of the Scapy course like the securing windows and unix courses? This way you all wouldn't have to discontinue the materials altogether?

  15. Hi Marcos - I've forwarded suggestions to them about an online course. They're considering it based on interest. But, it doesn't bode well that there isn't much interest in the conference course. Thanks for the suggestion!

  16. Is it possible that using an RST is the problem? What would happen if the IDS sent a FIN instead to try and actually close the connection? Would it solve this problem? And why would anyone with serious security concerns turn off TCP Checksum verification on an IDS? It seems to me like that would be a great way to catch malformed packets. I'm no expert in this field by any means so I may be way off here.

  17. Chris,

    The RST is not the problem - the TCP checksums are. I don't think you really want to burden the IPS to send FIN's to all RST's.

    Several years ago, I tested a commercial IPS that failed to validate TCP checksums - I suppose to save some processing time. I agree; it's something that should be performed.

  18. I think a key part here that is being understated is that you're also fragmenting the request in order to force the IPS to reassemble. While you did indeed state this, I think it's easy for readers to overlook.

    I would be interested to see a more comprehensive study, such as using bad checksums without fragmentation, as well as to test these techniques against various IPSs & firewalls.

  19. Thank you for presenting a wide variety of information that is very interesting to see in this artikle

    paket karimunjawa
    and minimalis jepara
    or mebel jati
    and tenun rangrang