From Security Weekly Wiki
Jump to navigationJump to search


PaulDotCom Security Weekly - Episode 217 - For Thursday October 28th, 2010.

  • Mark Baggett teaches SANS 504 during SANS San Antonio for 6 days. Come learn Hacker Techniques, Exploits & Incident Handling! November 13th thru 20th.

Special Guest Tech Segment: Judy Novak presents "A Technique for Crafty Packet Evasion"

Judy is a senior security analyst at works at G2 Inc. where she creates, trains, and performs research on IDS evasions. In the past, Judy served as a principal research engineer for Sourcefire doing development, testing, and research on packet reassembly. Judy has authored for SANS classes SEC503: Intrusion Detection In-Depth and SEC567: Power Packet Crafting with Scapy. Judy is the co-author of Network Intrusion Detection - An Analysts Handbook. You can catch more of Judy's work at the Packetstan blog

Look for Judy's "Power Packet Crafting Using Scapy" OnDemand class (SEC567) to be listed in the near future!

TCP Checksum IDS/IPS Evasion


This technical segment discusses an IDS/IPS evasion technique that may be effective if the targeted solution does not validate TCP checksums. Most IDS/IPS solutions validate TCP checksums; however, I performed some testing years ago and discovered a commercial solution that did not. I assume that this was for efficiency purposes to save some processing time on each TCP segment.

TCP is a very complex protocol and there are many nuances and operating-system implementations where opportunities for TCP evasions may exist. As Ptacek and Newsham discussed in their landmark paper "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", evasions were and still are an issue. A TCP evasion is particularly nasty because any signature, rule, or protocol decode that examines TCP traffic can be circumvented. The majority of Internet traffic rides over TCP; therefore a TCP evasion can render a targeted IDS/IPS solution pretty ineffective.


This particular TCP evasion uses an invalid TCP checksum in conjunction with an "expired" TCP timestamp. TCP timestamps are optional values stored in the TCP options portion of the TCP header. Most modern operating systems use them. The notion of time in TCP timestamps is relative to the last reboot for most operating systems. A clock tick is not the same for all hosts, it is just important to know that the value increases until the next reboot. Therefore TCP segments that contain a TCP timestamp reflect greater values than those sent before them.

One use of timestamps is something known as Protection Against Wrapped Sequence numbers. This was meant to protect against timestamps wrapping back to zero and accidentally arriving at the same time as an older segment in the same window with a smaller timestamp value. It is unlikely that this will ever occur. A host that receives an older TCP timestamp in a TCP session should silently discard it.

TCP timestamp implementations vary significantly making them very useful for evasion techniques. If you'd like to learn more about them, look at the paper I co-authored with Steve Sturges "Target-based TCP Timestamp Technical Study - PDF "

A description of the particular evasion technique employed in this presentation follows. First, I'm going to craft traffic using Scapy, a Python application, where I send a SYN segment with a bad checksum and a sender 's TCP timestamp value of 100. Next, I'm going to send another identical SYN with a good checksum yet a TCP timestamp of 10. To complete the ruse, I'll send all the rest of the segments in the associated session, including evil content with a timestamp of 10.

If the IPS doesn't validate checksums, it should accept the SYN with the timestamp of 100 and ignore the duplicate SYN with the timestamp of 10. If the IPS properly processes TCP timestamp values, it discards all the subsequent segments because they have an older timestamp value of 10.

The receiving host discards the SYN segment with the bad checksum and timestamp value of 100. It accepts the second SYN with the good checksum and the lower timestamp value of 10. And, it accepts all subsequent segments including those with the evil content.

The consequences of this are that there is an evasion of any TCP traffic that uses this technique when the IPS doesn't validate the checksum.

Here is what the tcpdump output looks like:


I've abbreviated the output to show you relevant fields only. In packet 1 I've crafted a source IP of going to destination IP port 80 to have the SYN flag set and a sending TCP timestamp value of 100. Although you cannot see it reflected in the tcpdump output, I've also put a bad checksum value in the segment. Packet 2 is the same except it has a valid checksum and a TCP timestamp value of 10.

Packet 3 shows the acknowledgement of the three-way handshake. Packets 4 and 5 are the ones with payload. All have a TCP timestamp value of 10. Suppose there is a rule that looks for "EVILSTUFF" in an HTTP URL request. Packets 4 and 5 contain parts of this content. The content is split between the two segments to force the IPS to reassemble the segments. If the entire content of "EVILSTUFF" were placed in a single segment, it's possible that some IPS solutions may fire even though there is a bad checksum earlier. This is just a failsafe method most IPS solutions use in the event of dropped packets and malicious content is discovered in a single segment payload.

Scapy Program

Scapy is a Python application that makes packet crafting very easy and manageable as you'll discover as we craft the packets required to attempt this evasion.


The first part of the Scapy program is shown above. It imports the required modules first. All text that is in red is related to Scapy syntax. A random source port is generated and a destination IP of "" is defined. The next statement creates an instantiation of an IP header called "ip" using Scapy to define the IPv4 header using the "IP()" syntax. All the IP header field/values are assigned between the parentheses. A destination IP address is assigned and all other fields assume default values that Scapy uses in the IP header.

Next, the timestamp options are defined using a combination of a Python list and Scapy syntax. The notable field is the sender's timestamp value of 100. The TCP header is defined next as the variable "SYN". The Scapy syntax for defining the TCP header is similar to that of the IP header. Field values are assigned – the random source port, a destination port of 80, a SYN flag, a TCP sequence number of 10, a bad checksum value of 1234, and our previously defined TCP options. Next, a Scapy layer 3 send is used to send the packet that consists of the crafted IP header followed by the TCP header. The slash signifies to append one layer after the other.


Let's continue with the second part of the program. The TCP options are redefined in preparation for our duplicate SYN with a lower timestamp value of 10. Next, the duplicate SYN is created, but this time, it has a redefined timestamp value of 10 and no assigned checksum value. This allows Scapy to perform the accurate checksum computation. The next statement is the most complex of all so far. First, look on the right side of the equals sign. The new SYN segment is assembled as before, however this time a different Scapy send command is used. The "sr1" command not only sends the segment, but stores the matching response – in this case the SYN/ACK from the server. The matched frame is appropriately saved in the variable "SYNACK".

The reason that this is performed is because the third segment of the three-way handshake requires the client to acknowledge the server's SYN/ACK by incrementing the server's TCP sequence number by 1. And, that's what the next statement accomplishes. It takes the attribute associated with the instantiation of the SYN/ACK frame known as "seq" for the TCP sequence number, adds 1 to it, and stores it in the variable "my_ack". Also, the client SYN consumes one sequence number so it has to be incremented by 1.

Next, the TCP options are redefined to remove the maximum segment size since that should be found on the SYN segment only. The TCP timestamp value remains 10. The TCP header of the acknowledgement segment is created using the computed server's SYN/ACK value plus 1, an appropriate acknowledgement flag, and the new TCP sequence number. The packet is assembled and sent with the Scapy "send" command since we are not concerned with a response.


The final part of the program is seen above. A TCP header is crafted for the PUSH segment. It is the same as the ACK segment TCP header except it has the PUSH and ACK flags set. We send the first payload packet by appending the first part of the payload stored in "pay1" after the IP and TCP headers. The next TCP sequence number has to be computed by incrementing the current one with the number of bytes send in the variable "pay1". A second delay is introduced to allow the server time to process the packet.

The second payload segment is sent using the same logic as the first one. It contains the remainder of the original HTTP request we defined in variable "pay2". Finally, the connection is reset.


Unfortunately, we encounter some issues due to Scapy's use of raw sockets. Raw sockets allow you to alter all packet values, including all the IP and TCP header values along with the payload. We need to alter these fields in order to manipulate the TCP checksum and timestamp values as well as other header values. Scapy uses a raw socket API to write directly to the network card driver. This circumvents the TCP/IP stack. Why do you care?

When you send the crafted SYN using Scapy it does not pass through the TCP/IP stack. Therefore when the SYN/ACK is returned, the host that is used to craft the packets has a TCP/IP stack that looks for a matching SYN and finds none so it resets the connection. As far as it is concerned the SYN/ACK is a rogue unsolicited SYN/ACK. We have to find a resolution for this because a reset means game over.


We cannot stop the native TCP/IP stack from attempting to reject the “unsolicited rogue" returned packets from our crafted packets. But, we can prevent these reset packets from leaving the host. If we can block TCP resets from leaving the host, the destination host we’re communicating with will never receive them and will not reset the connection. The way we can do this is by telling iptables or the native host firewall to block the outbound resets.


The following iptables command resolves the issue:

   iptables -A OUTPUT -p tcp --tcp-flags RST RST  -s -d --destination-port 80 -j DROP


Assume that the python program is stored in a file called "multiple-syns.pcap". First, you need to be the root or superuser to craft Scapy packets. We'll capture the traffic from the Scapy program using tcpdump and write to a pcap file named "multiple-syns.pcap" using the following command:

 tcpdump –s0 -w multiple-syns.pcap  "port 80"

Run the program as follows:

   python multiple-syns.py

After this is done, we want to run Snort to demonstrate the implications of enabling/disabling TCP checksum validation. Specifically, we want to run it first with TCP checksum validation enabled – the default for the Snort TCP preprocessor stream5. We include a single rule to check for "EVILSTUFF" in the URL content. A second run using the same pcap file "multiple-syns.pcap" demonstrates the impact of disabling checksums.


The first configuration file is stored in file "normal.conf" and the second in "turnoff-checksums.conf". The first run of Snort uses the "normal.conf" configuration, the second uses "turnoff-checksums.conf". They both use command line switches to display the alerts to the screen, quiet start-up messages, disable logging and take input from the file "multiple-syns.pcap".

   snort –A console –q –K none –c normal.conf –r multiple-syns.pcap

10/16-04:40:53.086205  [**] [1:12345:0] EVILSTUFF [**] [Priority: 0] {TCP} ->

   snort –A console –q –K none –c turnoff-checksums.conf –r multiple-syns.pcap

10/16-04:40:53.033669  [**] [129:4:1] TCP Timestamp is outside of PAWS window [**] [Priority: 3] {TCP} ->
10/16-04:40:53.086205  [**] [129:4:1] TCP Timestamp is outside of PAWS window [**] [Priority: 3] {TCP} ->
10/16-04:40:54.134649  [**] [129:4:1] TCP Timestamp is outside of PAWS window [**] [Priority: 3] {TCP} ->


Snort alerts when allowed to use default configuration of performing TCP checksum validation. This is because it drops the SYN with bad checksum, but accepts one with good checksum. The SYN with the good checksum has a TCP timestamp value of 10 and all subsequent packets have a valid timestamp value of 10 and are accepted and scrutinized.

However, Snort does not alert when TCP checksum validation is disabled. This is because it keeps the SYN with bad checksum, ignores the SYN with the good checksum, and subsequently discards other segments with lower timestamp values and malicious content. The Snort stream5 preprocessor was configured with the "detect_anomalies", causing the second run to issue a warning that "TCP Timestamp is outside of PAWS window". This warning was generated for the three segments with a timestamp value of 10.


While this TCP evasion may not work against all IPS solutions, it demonstrates the methodology that can be used to attempt an evasion. There are many other TCP manipulations than using bad checksums that may cause TCP evasions issues for IDS/IPS solutions. That's because TCP reassembly is a complex process for an IDS/IPS to emulate perfectly.

If you are interested in learning more about Scapy, SANS is in the process of preparing the course I authored [SEC567 "Power Packet Crafting Using Scapy" http://www.sans.org/ondemand/courses.php]for OnDemand delivery to be listed soon.

Guest Interview: Felix "FX" Lindner

FX runs the German based Recurity Labs, a security consulting and research company. FX's research topics include Cisco IOS, HP printers, SAP and RIM BlackBerry.

  1. How did you get your start in information Security?
  2. Tell us about your router exploitation work.
  3. How are you Defending the Poor
  4. Have often do you estimate a typical user runs into Flash based attacks?
  5. What about DNS rebinding?

Tech Segment IDS / IPS - Darren Wigley

What is an IPS / IDS?

IDS stands for intrusion detection system and IPS means Intrusion Prevention system. The only difference is that IPS can actively block traffic and IDS cannot only watch.

Vendor Considerations

The Marketing Numbers

They lie just a question of by how much. Just don't trust the numbers because they were derived in a ideal lab environment. They still do give you a good baseline to start with.

Bandwidth Consideratoins

make sure you get enough bandwidth to cover you for the life of the device. Plan for 3 years that is about the average life of a piece of IDS/IPS hardware. Don't get something that barely covers you right now and then have to buy all new devices next year.


There are two types of signatures open source, like with Snort and SourceFire. Or closed source like with nearly every other vendor. The difficulty is you may not get a clear picture of what a signature is looking for. Your just left to trust that the vendor did the right thing. This also means you may or may not have the ability to write your own signatures on the fly. Some vendors include user requested signatures as part of the maintenance package but some do not. Most Vendors today will read Snort style signatures so this is becoming less of a concern.

Ask what the frequency of signature releases is. Vulnerabilities are disclosed everyday. Does your $VENDOR have a release schedule that makes you happy? Ask how they have handled critical 0-days in the past.

How does the vendor make signatures do they have their own research team? make their own copy of the Snort signature feed? just write one for a new CVE?

Examples of a bad signature versus a good one... written for the exploit or the vulnerability? Code red had a clear pattern of A's a signature written to detect that is bad cause the vulnerability was to many chars being sent not just A's so I would just modify my code red attack to put some random letters in.

Here is a good article I found on writing good signatures or what can go into writing your own signatures.

Fail out conditions

Nearly all devices will have a breaking point where they cannot process the traffic they are receiving. What happens when this condition occurs? Does the box just turtle over and give up? Does it simply start dropping packets. Will it fail closed and prevent network traffic flow until it can catch up? How can you be alerted when this condition exsists? Again this is all dependent on the risk your buisness wishes to take on. Can you absolutely not have network traffic passing uninspected? Then you may want to consider running IPS in fail closed mode.


What DDoS protection does your device offer and how is it configureable. Every environment is different.

Bypass Attacks

We know they exsist and so does the vendor. What do they do about it?


Metasploit, TCPREPLAY oh my

This may lead to another different tech segment but some thoughs are to set up a environment where you have Metaspoit attacking a vulnerable VM farm that is running DVL, and other old known vulnerable software. You could even have copies of what is already running in your environment you are looking to protect.

TCPREPLAY on the other hand is something we use cause we are more concerned with how a device generates alerts cause we are vendor neutral. For this I have a collection of Malicious Packet captueres that I have found on the web from DefCon competitions, Malware exapmples, and Packet data taken from what some of our devices have seen in the field.


Through put testing

I am not aware of any free ware tools to do this but there are products that can just push through raw traffic and see where your device starts to fail. Products made by Ixia and Breakingpoint can do this but cost money.

Management ease

Every vendor will have some sort of management interface for the devices. Depending on the size of your deployment you may just access the devices individually or have a central management console. Either way this is going to be just as important as any other aspect from a given vendor. If the method for deploying signature updates and policy changes is onerous and difficult, you or the security team may be lax in making updates cause the tools blow.



If you don't already have a visio or any diagram of your network now is the time to create one. This will allow you to look at a map and find where you want to watch traffic. Do you want to watch all partner connections? Everything that comes into the server farm? everything that comes into your ISP connection (i.e. before the firewall)

Also know where you are NOT seeing traffic. are you not watching client to client traffic on your network. So you will not see attempts of one infected client trying to infect another. This will allow you to see what you are accepting as a risk and why. It may simply be you don't have the budget to put sensors EVERYWHERE. This needs to be noted and documented and what risk a lower budget puts on the buisness. Always good CYA move.

Policy work

now its time to decide what to look for. Well everything right? WHOA hold on there cowboy. Most filter sets I have seen in my work are up to 10000 signatures. If you turn on all alerts then you will crush the box as now a devices has to compare each packet to 10000 different signatures. a device is only effective as the size of the policy... if you have one signature enabled it will be great at finding that one alert in your network, and scales down from there.

To start with most signatures from vendos are broken up into sub groups for OS and application. Start by enabling only the ones that you need protection. Not running windows in your web server farm? Then you probably don't need to enable signatures that look for windows attacks.

You will have false positives. It dosen't matter what the vendor promised in false positive reduction it can and will happen. So you will always be tunning. One of the common things I have seen is that internal groups made a custom application quick and dirty to hit a server and pull back data. This program causes some signature to trip that an attack is under way. You will either need to get your internal team to re-write the application to NOT cause the signature to fire or you will need to modify the signature to white list the traffic in quesiton or diable the signature all together. This is a never ending process for your organization as things are always changing just stay on top of it so your policy doesn't become stale only checking for 2 year old CVEs you patched a long long time ago.

Log Retention

Depending on what you have done for your policy you may need a TON of storage if you have a 12 month log retention policy and you have enabled full packet capture for all critical alerts. Rememer that depending on what you want to capture it can really add up over time.

On going monitoring

Who is going to be watching alerts come in and respond to them? Make sure those individuals get a say in the process. Make sure they have clearly documented operating procedures for how policies get updated, signature sets are deployed and what do do in the event of catastrophic IPS / IDS failure.

Stories For Discussion

  1. SpyEye v. ZeuS Rivalry Ends in Quiet Merger - KrebsonSecurity - [InternMike] - We wish that malware business were required to file a 10K with the InfoSec community. We would love to get the back story on this "merger".
  2. The sheep the sheep is on fire! - [the other guy] - I like sheep. I like warm sheep. This sheep is on FIRE!!!
  3. NO, NO, NO a thousand times NO! - [Larry] - So, I see this vulnerability in HP Procurve switches that indicates a Security bypass that would have been asweome to use at a recent customer site. Even though I found it too late, I figured I check it out to keep in my back pocket for the next test, only to be met with "The vulnerability is caused due to an unspecified error and can be exploited to gain unauthorized access. No further information is currently available." Whiskey Tango Foxtrot. Ok, so why bother telling me about it, and jsut patching it silently. Discuss before I rant again.
  4. Defeating Credit Card Fraud - [Larry] - To me this is clearly cases of building a better mouse. As defender's we are always a step behind. However I thought that it was ironic that attack was interesting in that "they noticed withdrawals from 100 ATMs all over Canada within 10 minutes", but that "There's no way to catch this fraud with the fraud detection systems unless they start looking at location or behavior". Ummm…wait. Really? This coming from fraud detection stuff that thinks there is fraudulent activity buying international airfare IN THE NAME OF THE CARDHOLDER (yes, they get that info from that airline at time of purchase). This stuff sounds like an IDS that needs some tuning, which as we know can be difficult to accomplish.
  5. Just because we HAVE to mention it - Firesheep - [Larry] - Yes, the elephant in the room that everyone is talking about. Awesome too, and yes this is an attack that has been around for a long time; the change now is that is is so easy ANYONE who can install a browser plugin can do it. It think that once an attack has been made easy enough for the masses to use, that's when it starts getting some real traction.

Other Stories of Interest