Wednesday, October 01, 2008

DoS Me Like It's 1996

This one's in my wheelhouse, but details are sketchy. So far the best simple article is New attacks reveal fundamental problems with TCP by Dennis Fisher. Nick Weaver's Slashdot comment provides the best technical explanation of one of the attack vectors, I think:

The observation: You can use a SYN-cookie like trick on the client side as well for an attacker:

You send SYNs where the initial seq # = H(sip, dip, sport, dport).

Now when you get a SYN/ACK back, you can send the ACK to complete the handshake. You can use the ACK field back from the server to know where you are in what data to send (just subtract the value from the initial sequence # to know what the next piece of data to send is), and you can know where you are in the received data (if necessary) by storing just the server's initial sequence #.

As a result, you can now interact with the server without having to maintain ANY TCP session state, or just a single word (the server's initial seq #), allowing the attacker to use vastly fewer resources to tie up server resources.

On one hand, this is a cool trick, and potentially useful for an attacker: if you have only a couple of machines and really want to tie up server resources, you can use this quite quickly.

But OTOH, attackers already have so many zombie resources that this really doesn't necessarily buy the attacker all that much: If you have 10K machines banging on a server, the 10K machines have a good 2000x more state than the servers. So who cares about stateholding requirements on the zombie side? Thus I think its only really relevant if you wanted to DOS google, akamai, or some similar very-high-resource infrastructure.

And as the attacker can't SPOOF packets with this (it needs to see the SYN/ACK), the zombies can be filtered if the DOS is detected and the attacker's identified as well.
(emphasis added)

So that's pretty clever... clever like the original 1996 problem of SYN flooding, which exploited resource limitations on the server. Reference Mike Schiffman's original Phrack article for details and remember 12 years ago we worried about k1dd13z with dial-up modems DOSing NT 4 servers with 7 packets.

With regard to the latest, we should give some credit to BindView RAZOR's Naptha research from 2000, as noted by Jose Nazario. So-called Naptha attacks are any mechanism that forces the victim's TCP/IP stack to consume more resources than the intruder's, thereby eventually forcing the target to submit. Robert Graham's post implied one attack vector acted what sounded to me like a reverse LaBrea implementation. I would like to incorporate this "sockstress" tool into my next TCP/IP Weapons School class.

I guess we can stay tuned to Robert E. Lee's blog. (Funny that a researcher in Sweden is named after the commander of the Confederate Army.)

Anyone who thinks this is again the end of the world should please keep vulnerabilities in perspective. Also, this is about the best vulnerability we could request. If you're vulnerable, and you're attacked, you'll notice. Even the most rudimentary IT shop has availability monitoring in place. To quote Han Solo:

Bring them on! I prefer a straight fight to all this sneaking around.

I'd much rather deal with availability attacks than confidentiality or integrity attacks.

5 comments:

Pete Markowsky said...

So the one thing I don't get about the "trick" you described earlier is why not just use a fixed ISN and skip the hash entirely?

You could achieve the same effect if you know that the ISN is always some constant.

Remember syn cookies as DJB described them require both a timer that changes (increments) every 64 seconds and a cryptographic function often a hash, linux uses a sha hash in it's implementation. The timer is used as the first 5 bits of the ISN and part of the 24-bit hash portion of the ISN. The remaining three bits are supposed to be an encoding of the maximum segment size.

Gettisburg said...
This comment has been removed by a blog administrator.
Chris said...

I think we'll find that they are using this concept of client-side SYN cookies as a means to further the other attack vectors.

There is speculation (!!!) that they have anywhere between 3-5 vulnerabilities that they leverage to play havoc on TCP state tables.

Errata Security has a decent stab at what might be expected next week at the conference:

http://erratasec.blogspot.com/2008/10/tcp-dos-probably-real.html

111 said...
This comment has been removed by a blog administrator.
wow gold said...
This comment has been removed by a blog administrator.