Comments on Packetstan: IDS/IPS Evasion - Step 1. Awareness

Marcos - great to hear from you. Glad this was he...

2010-06-17T17:21:28.177-07:00

Marcos - great to hear from you. Glad this was helpful. When I get some time, I'm going to post the Scapy code for this.

Hi Judy, Great article! This just solidifies my ...

2010-06-17T09:28:33.791-07:00

Hi Judy,

Great article! This just solidifies my love for Scapy. This will be great for our QA testing in house.

Dude, great article. Now, if only you could make t...

2010-06-16T11:00:30.735-07:00

Dude, great article. Now, if only you could make that font legible enough without having to zoom in using magnifier...

I kept thinking about this, and ended up writing a...

2010-06-16T09:08:10.833-07:00

I kept thinking about this, and ended up writing a blog posting about how I see the specifics working.

http://blog.bmurray.ca/2010/06/idsips-evasion-with-syncookies/

I just wanted to reiterate that this is not a univ...

2010-06-16T03:18:56.633-07:00

I just wanted to reiterate that this is not a universal evasion against Snort. This "issue" was discovered when I worked on stream5 research at Sourcefire. As I mentioned yesterday, the default stream5 policy of "windows" will actually not be fooled by this because of what it considers an invalid reset sequence number.

At Sourcefire, we never truly understood this weird behavior. As Ashok astutely commented - it is a protection mechanism against SYN flooding that is implemented by SYN cookies. I sent this information to Steve Sturges,the author of stream5, at Sourcefire.

famousjs - That was the next post I was planning o...

2010-06-16T03:10:40.408-07:00

famousjs - That was the next post I was planning on doing! I'm going to cover it again in some detail so please don't think I'm pirating your idea. Thanks for the post. One of my motivations for this and many of the other blogs I plan to do is to show how awesome Scapy is. Thanks for helping me in this regard.

Judy, I just posted a blog with a sample scapy scr...

2010-06-15T22:21:45.304-07:00

Judy, I just posted a blog with a sample scapy script using this evasion technique.

http://www.malforge.com/node/35

Thanks for the packet-crafting fun!

stream5 would have to handle this as an OS-specifi...

2010-06-15T09:41:46.802-07:00

stream5 would have to handle this as an OS-specific policy because not all OS's respond this way. Some of stream5's policies ensure that the sequence number on the reset is the next expected one - in other words one more than the last value - not two more as seen in the above reset. If this is the case, Snort will not be fooled. This is not a universal policy because some OS's allow a reset to be any value in the current window.

This is almost definitely a syncookie thing. Since...

2010-06-15T08:34:10.565-07:00

This is almost definitely a syncookie thing. Since the linux host is using its magic algorithm to generate a sequence number, you could theoretically open a SYN-less connection, if you knew the magic data. Since syncookies uses the source and destination host and port numbers as part of its hash, using a ack + 2 wont validate against its syncookies algorithm, but using ack + 1 will validate. So to the webserver (in this case), doesn't actually have any entries in its table until that second connection (ack + 1) opens it.

I suppose someone now needs to write a patch for IDS's to understand syncookies a little better. I wish I had the time to set up snort to test this, but syncookies most definitely does look like the culprit.

Now the next question is why does stream5 handle it better. Interesting thing to look into.

oops, did not notice the "ACK 1" in pack...

2010-06-15T08:22:11.022-07:00

oops, did not notice the "ACK 1" in packet 5, so it will make syn-cookie happy.

but i do recall seeing something like syn-cookie won't kick in until a certain number is reached. (i might be wrong)

hmm, i am not sure this is really caused by syn-co...

2010-06-15T08:10:22.964-07:00

hmm, i am not sure this is really caused by syn-cookies, on some linux, syn-cookie is enabled by default but they won't kick in until some threshold has been reached.

also, even if syn-cookier kicks in, it should wait for the ACK, and decrypt the sequence number, and the "ACK 2" just won't match...

Great post Judy. I might add this in to Rule2Alert...

2010-06-15T07:21:24.852-07:00

Great post Judy. I might add this in to Rule2Alert to stress test systems such as Snort.

Ashok - Wow, thanks so much for the insight! That...

2010-06-15T03:53:02.593-07:00

Ashok - Wow, thanks so much for the insight! That's amazing to associate this behavior with SYN cookies - now I better understand the seemingly bizarre behavior.

Brian - It looks like Ashok has the answer why Lin...

2010-06-15T03:50:56.416-07:00

Brian - It looks like Ashok has the answer why Linux does this because it uses SYN cookies. I just checked on the Linux system I use:

sysctl -a | grep net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1

IIRC, if Snort is configured to use preprocessor stream5_tcp: policy windows, I believe it will not be duped into resetting the connection. I know this isn't intuitive since we're using Linux, and I'm not necessarily recommending it, it's just the way that the stream5 preprocessor handles reset sequence numbers.

Hi Judy, I think this kind of behavior is expected...

2010-06-15T01:41:07.286-07:00

Hi Judy, I think this kind of behavior is expected with any implementation using syn-cookie, (which explains why you don't see the SYN+ACK being retransmitted), as the wrong ACK is just a stray packet and the GET is considered as valid final ACK of three-way handshake since the syn-cookie will match.

Very Nice, at one point i was really close to gras...

2010-06-15T01:22:53.548-07:00

Very Nice, at one point i was really close to grasping this possibility. But the actual proof of such attack-vector being plausible is a thumbs-up for my natural paranoid state of being.

Judy, as always, nice work. Look forward to seein...

2010-06-14T21:41:13.780-07:00

Judy, as always, nice work. Look forward to seeing more.

Very interesting. I wonder if it's by design o...

2010-06-14T19:35:49.687-07:00

Very interesting. I wonder if it's by design or a bug. Do you know what ids systems this affects?

Also, the colour scheme burns my eyes. It even comes through as white on my rss reader, making it nearly impossible to read. You may want to reconsider that decision.