Slashdot Mirror
New Denial-of-Service Attack Is a Killer
ancientribe writes "Hacker RSnake blogs about a newly discovered and deadly denial-of-service attack that could well be the next big threat to the Internet as a whole. It goes after a broadband Internet connection and KOs machines on the other end such that they stay offline even after the attack is over. It spans various systems, too: the pair of Swedish researchers who found it have already contacted firewall, operating system, and Web-enabled device vendors whose products are vulnerable to this attack." Listen to the interview (MP3) — English starts a few minutes in — and you might find yourself convinced that we have a problem. The researchers claim that they have been able to take down every system with a TCP/IP stack that they have attempted; and they know of no fix or workaround.
Neither interview nor Link provides much information about the kind of attack. Between the lines they seem to be doing something with the ressource usage by manipulating tcp session parameters. But that's idle speculation for now.
CU, Martin
Coral Cache (just in case): http://debeveiligingsupdate.nl.nyud.net/audio/bevupd_0003.mp3
Forget world peace, bring on -1 pointless
http://blog.robertlee.name
Here's a link to an article in English:
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html
From the article:
Many TCP servers use a technique known as a SYN cookie in order to prevent attackers using spoofed IP addresses from launching SYN flood denial-of-service attacks against them. The cookie is essentially a chosen TCP initial sequence number that is calculated using some specific hashed metadata that reflects the details of the specific TCP connection. Once the client returns a correct packet to the server, the server knows that the client isn't using a forged IP address.
Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.
The interview is in Dutch, not Swedish. And since the researchers' names are Robert E. Lee and Jack C. Lewis, I don't believe they are Swedish either.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
What? WinME was simply repackaged Win98. Windows _NT_ was built by David Cutler, on a VMS foundation rather than a DOS foundation, because Cutler was one of the core authors of VMS and there were some fascinating lawsuits about his duplicating his old VMS work for Microsoft.
The technique was created by Daniel J. Bernstein and Eric Schenk in September 1996. The first implementation for SunOS was released by Jeff Weisberg a month later, and Eric Schenk released his Linux implementation in February 1997 (the current implementation uses e.g. net.ipv4.tcp_syncookies).
From an old 2001 syn cookies vulnerability report:
syncookies can be disabled on a running system by executing the command:
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
(To the editors: Mind adding the above line to the summary? Thanks!)
Patch your systems. NOW! (note that this makes them vulnerable to syn flood attacks, but at least those won't leave your system unusable until reboot!)
http://blog.robertlee.name has more information... still searching for transcript though...
It wasn't our intention to fear monger. In fact if you listen to the whole podcast we actually comment on the "Chicken Little" phenomenon in security research.
For those wanting to stay abreast of these issues as more information is shared publicly, keep an eye on my blog.
I'm trying to keep a link to most news articles there. I've also been able to answer a few questions in the comments through that medium.
--Robert
If you are running Ubuntu 8.04, you probably aren't vulnerable (or at least I am not). See if you get what I got in the terminal:
collin@collin:~$ cat /proc/sys/net/ipv4/tcp_syncookies
0
collin@collin:~$
You can find more information at my friends blog http://blog.robertlee.name/ he is one of the researchers at http://www.outpost24.com/ that discovered this vulnerability together with Jack Louis. This is probably the best place to find links for intervies, other articles and keep yourself updated with this issue. They will among other things present this at T2 in Finland this friday http://www.t2.fi/schedule/2008/#speech8
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.
Test your net with Netalyzr
Sockstress computes and stores so-called client-side SYN cookies
This isn't supposed to be possible. SYN cookies are supposed to contain at least 24 bits worth of entropy, produced by running a server-side secret through a one-way hashing function. You can easily obtain a SYN cookie by performing the initial SYN with the server. A SYN+ACK comes back which contains the SYN cookie (as the initial sequence number). The cookie so received is unique per TCP connection (IP address and port numbers at both ends), and valid only for a limited time. The server side does not maintain any state information until the cookie is returned in the client's ACK.
If they are actually computing SYN cookies on the client side, it's evidence of a weak SYN cookie implementation. Computation of the cookie should be infeasible without access to the server-side secret. Of course, this may be a case of sloppy reporting. As usual, we aren't given all the details of this earth-shattering vulnerability. We are simply left to guess whether these folks (and those that report on them) know what they're talking about or not.
They could be guessing cookies, and that would explain the "it will hurt intermediate systems" excuse they used for not demonstrating it, since they'd need to flood the peer TCP with millions of randomly-guessed initial sequence numbers. Incidentally, if this is a TCP SYN-flood attack of this sort, the "after effects" they mention have to do with the fact that all the TCP connections must time out naturally -- a process which might take several minutes per connection, depending on the configuration of the listening server application. The process is naturally limited by bandwidth and the size of the TCP state table: you have to be able to send successful fake ACKs fast enough to fill the TCP state table. All the usual mitigations for TCP SYN floods apply, such as increasing the state table size and reducing the timeout for open but idle connections.
It's not at all clear that this is any worse than the kind of DDoS attack that a typical botnet can unleash. In that case, you get thousands of perfectly real TCP connections from multiple addresses almost simultaneously. So maybe this attack doesn't require a botnet, but I don't see that it's a big new threat (as I've described it).
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Dude, did you just tell one of the guys who discovered this issue to *not* post links to his blog which may contain relevant information? I mean I'd understand if his blog had a ton of advertisements or something. But it's pretty much just blog entries and that's it.
Weird.
"This calls for a very special blend of psychology and extreme violence" - Vyvyan "The Young Ones"
On RedHat distros, and probably others, there is a utility called 'sysctl' and a config file called '/etc/sysctl.conf'. In Redhat, the following appears in /etc/sysctl.conf:
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
Just change the 1 to a 0
Now we see that a little bit of knowledge can be a dangerous thing.
The point that's in the grandparent's post is not that your own syn-cookies can be used against you. Syn cookies on your server are doing the right thing and are protecting you against normal syn floods.
What's happening in this attack is that the client side (the attacker) is using their own syn cookies to store information about connections on your server (instead of in their own memory). This allows them to handle more connections than otherwise. Unfortunately there is nothing you can do to stop this. They are using required behavior of the TCP stack for their information storage.
Some mitigation strategies that I can think of
The parents "fix" will make things slightly worse during this attack since turning off syn-cookies will mean that your server will have to track even more TCP connections. Not just those that are active, but also those that have just started. Of course, it will also make the new attack pointless since they can just do a normal syn-flood instead.
The best current full fix I can think of is to use IPSEC and ensure that all incoming connections are authorised. Your own users will still be able to DOS you, but at least you can hunt them down.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Piffle yourself. The memory management, as an example, was definitely theft from DEC.
David was one of the three team leads on Starlet, which became VMS. And yes, according to DEC personnel of that era, he was very much a technical lead, if not the technical lead.
Or if you prefer normal pitch, install http://www.breakfastquay.com/rubberband/ , an excellent Free pitch shifter, and use:
mplayer -speed 1.6 -af ladspa=ladspa-rubberband.so:rubberband-pitchshifter-stereo:0:-8.1:0:2:0:0 [file]
NetBSD has a SYN cache instead of using SYN cookies to deal with SYN flood attacks. The difference may be enough to prevent the attack on the SYN cookie mechanism from working. The differences are discussed in this article, which I'll admit up front that I have not read.
The memory management, as an example, was definitely theft from DEC.
Should surprise no one. He did, after all, work on Starlet, in the 1980s there were many books written on VMS internals, and the source code isn't even that difficult to get.
(As an aside: at a VMS tech conference in 2002, we were told by a VMS engineer that Itanium's memory management was purposefully designed to be like that of the VAX.)
according to DEC personnel of that era, he was very much a technical lead, if not the technical lead.
I used to work with someone who was there at the time.
"I don't know, therefore Aliens" Wafflebox1
The interview does actually have a lot of detail.
Skip to ~ 5m10s for the English.
TCP is a stateful protocol. Each connection consumes resources (memory, timers, etc.) for keeping track of the connection state. Denial of service attacks used to attack the handshake phase by starting the handshake without ever finishing it. That's called SYN-flooding. SYN cookies were invented to defend against that. A lot of work has been done to make sure that computers which don't complete the handshake can't bog down a server. The rationale behind this bias is that those types of attacks can be performed with spoofed packets, which makes the attackers hard to catch, so you must defend against these attacks.
The new attack completes the handshake and then does things which consume an extraordinary amount of resources in the TCP stack of the victim. Apparently all TCP stacks are much too trusting in one way or another if the remote computer completes the TCP handshake.
The researchers have written a port scanner which tracks connections with very little overhead. While researching that application, they came across odd behavior in target machines and even found comments in TCP stack source code which hinted at possible resource problems in certain situations. They proceeded to craft attacks to trigger exactly these problems and found that they could easily bring down machines. Some of the consumed resources are so critical that their exhaustion causes other parts of the OS to fail in ways which can only be corrected by a reboot.