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.
Some DOS attack on Slashdot in progress?
While it is pretty interesting, and disturbing, we are once again faced with a "The Internet Will Cease To Exist And Your Brain Will Explode" vulnerability. We dont know exactly how it works, we dont know exactly what to do to stop it, fixes are not available, and we are all doomed. The podcast goes into enough detail about how they discovered it to be replicated by skilled evildoers without too much trouble, but nobody knows how long, easy or invasive a fix is going to be.
People who think they know everything are a great annoyance to those of us who do.
Doesn't affect me. I haven't used DOS in YEARS. Some folks need to move up to Windows 3.1. That is where it is at.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Do people really have time to listen to podcasts unless they are commuting?
Is there a transcript???
http://blog.grcm.net/
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
The simple fact that I'm posting this reply makes me doubt the "ZOMG UNSTOPPABLEZ" aspect of this claim, is all.
Unless it's a generic vulnerability in the TCP spec, in which case almost every implementation of it would be vulnerable - including all those Linux machines. Linux is not some magical shield, it takes responsible use to keep it secure.
Forget world peace, bring on -1 pointless
Thief! That's MY address!
Ignore the story, there's very little chance that a single virus can take down all systems, especially if the user is not running Windows.
I for instance have multiple rock solid software and hardware firewalls, and most ports blocked - I'd like to see it try taking dow
Why OpalCalc is the best Windows calc
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.
Why do I constantly find stories about how our power grids, nuclear energy sites, military bases, Federal government, etc., etc., will be taken down by Internet hackers? Please don't tell me that all of those resouces are accessible over the Internet. Why in God's name would put such resources on the Interet?
Fata viam invenient.
Typical /. reaction to potential danger:
"Hah. Until I don't taste nuclear winter snow I don't believe that's gonna happen'"
Give the man his nuke. He earned it.
mov ax,4c00h
int 21h
someones mom needs to check the basement more often...
TFA starts off with "things are a brewin' in sweden"
"Robert and Jack are smart dudes."
"I feel winter slowly coming, and it would be a shame if entire power grids could be taken offline with a few keystrokes, or if supply chains could be interrupted. I hear it gets awfully cold in Scandinavia. "
Good people go to bed earlier.
Another security researcher claims the sky is falling. There are no details, no proof of concept, nothing to prove the alleged vulnerability even exists. Here's something those researchers should learn: if you can't back up your claims with proof it doesn't exist!
Of course Linux is not a magical shield. But having a diverse eco-system is known to protect against many attacks.
One of the reasons stories about how the banana is going extinct come up every few years is because the "modern" banana that most people in the over developed world can buy, are all clones! One disease can attack all the plants in the same manner.
In the same way, computers that have the same OS tend to be vulnerable to the same attack. Because there are a lot more OSs based around Linux (and BSD), people running these OSs are less vulnerable, because they are in a diverse eco-system. Especially when these kernels and the user-land tools are FLOSS.
As such, yes, it maybe a generic vulnerability in the TCP spec. (though how likely is that?), however, it is not specified, which is why I asked if it did affect *nix.
If nothing else, due to the nature of FLOSS, the attack could quickly be coded around as soon as it is known, and then pushed out to many many people running auto-update systems (such as Debian, Ubuntu and similar). (Even if that breaks the spec.)
I wank in the shower.
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.
In summary, it works by establishing tons and tons of connections using carefully-forged SYN cookies. The irony? "SYN Cookies are the key element of a technique used to guard against SYN flood attacks". ROFLMAO.
And then it gets scarier:
From the wikipedia article:
The use of SYN Cookies does not break any protocol specifications, and therefore should be compatible with all TCP implementations.
Now, are you ready to scream?
the 2.6.26 Linux kernel added limited support of TCP options.
Scream.
Quickly, go yank the cable/dsl connection right out of the wall before its too late!
Come on... I'm not going to listen to mp3, but the /. summary and the article both are dangerously low on details. This effects every machine with a TCP/IP stack? IPv4 and IPv6? Leaves the machines in a permanent state of DOS? There's no prevention? No fix? And you can't even test it because it might take down "other devices between here and there"?
Pardon me, I'm off to find myself a huge grain of salt.
This doesn't me since use I UDP all communications communications for.
This
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:~$
It sounds like a blind resource consumption attack against SYN-cookie implementations, no? (Without SYN-cookies, the attack is trivial, just spoof SYNs).
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html
SYN-cookies are a simple idea. Upon receiving a SYN, rather than creating all the state, the server returns a SYN/ACK with the SEQ value = H(IP,ACK value). Thus when it sees the ACK packet it can check that the value is returned, and then create all the state.
If this is the case, it seems to require that a SYN-cookie be predictible, that the attacker can probe a client to predict what H(IP,ACK value) is. IF that is the case then there is an easy fix: simply use more and better random data as salt in a better hash function.
Simply because ANY blind resource consumption attack against a SYN-cookie server requires knowing what the SEQ value from the server for the SYN/ACK in order to establish a connection by sending the proper ACK (and then some data to load the server further).
If the attacker can't predict the SYN/ACK's SEQ value, it can't construct a proper ACK and cause the server to consume resources.
Test your net with Netalyzr
I don't think so. From the techtarget article, it seems that they are using a technique invented for the server side, but on the client side.
It's a way of calculating the syncookies, so that the server doesn't need to store anything, until it receives the third packet (ACK) of the three way handshake, thus being able to handle syncookie'd connections just as fast as normal connections. My understanding is that these guys use the same technique on the client, so that they don't need to store anything either.
They send the first packet (SYN), and forget about it.
When the server responds (SYNACK) several thousand packets later - this is a flood, remember - they know the server cookie, and can recalculate their own cookie. Thus they can send the third packet (ACK) and complete the handshake, establishing the connection. The server now inserts the connection into its connection table. The client does not, it's doing a DOS attack, not trying to communicate.
When the client doesn't need to keep track of its connections, it can start new connections as fast as bandwidth allows. Basically syn-cookies just became useless, and we're back at square one.
However, for servers that don't have this no-memory implementation of syncookies, but still store the syncookie itself, it gets even worse. Not only are you using up all available connections, but you also fill up the syncookie table. This may be where the "does not recover after the attack" comes in. Previously syncookies would prevent the flooding in the first place, and thus you would never fill up the syncookie table. So that part of the code never got tested.
Of course this is just how *I* understand it.
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.
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();
Ha, ha, laugh at my dial-up connection now!
Disclaimer:IANAL/MD/PhD-Just the local yokel PC "doc" ~If you're not having fun, then you are probably doing it wrong.
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.
WHY ARE YOU TAKING THE ADVICE OF RANDOM FOOLS OFF SLASHDOT? Go find out what syncookies first. Find out why syncookies were put in. Then find out what this attack is supposed to do. Then think for your self - do I want to protect against a known attack that has successfully brought down large sites, or do I want to turn that protection off because some fool suggested it on slashdot because I heard about a new scary attack?
If you are truly worried, there are other things you can do - look at your routers, firewalls, etc. Also, look at other OS'es. OpenBSD doesn't have syncookies - why not?