New Denial-of-Service Attack Is a Killer 341
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.
Go for it, take on my machine! (Score:3, Interesting)
My IPv4 address is 127.0.0.1 ...
More seriously, I wonder if this actually affects *nix machines, and how the various environments in that area affect the attack.
After all, they may find a single attack against all MS Windows XP machines, but they need a lot more then one to attack all Linux based systems (and then you throw in BSD based ones as well...).
Meh, the article doesn't give much detail.
Things that make you go 'Hmmm...' (Score:4, Interesting)
The simple fact that I'm posting this reply makes me doubt the "ZOMG UNSTOPPABLEZ" aspect of this claim, is all.
Comment removed (Score:4, Interesting)
The sky is falling! (Score:4, Interesting)
How it works (Score:5, Interesting)
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 [wikipedia.org]. 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.
Re:Pfffft (Score:4, Interesting)
Haha!
Pentium? Microsoft advertised that 3.1 would run on a 386 with 16 meg of RAM, so that's what we installed it on to evaluate against our lovely Netware 3.11 fileservers.
Guess what?
It sucked ass - 10 minutes to boot, and funny looks were a definite no-no.
I have a lawn you could get off, if you like...
Re:Pfffft (Score:2, Interesting)
No lie, I once had Windows 3.1 running on a 286. Not sure how much RAM I had. Oh, and the monitor was monochrome orange and black (or may have just been broken). The keyboard connected with something resembling a phone jack. I probably still have that machine in the attic. Note that I said it was running. I can't comment on if it was running *well* or not because I just booted it for curiosity's sake, then shut it down and promptly forgot about it until just now. This was well into the days of the Pentium 233, and someone had just given me the machine as a cast-off. I do remember it took a hell of a time to boot though...
Actually, thinking about it now, I may have deleted those memories out of sheer trauma.
Off-topic, I know... but... (Score:3, Interesting)
...something about this article made me think of something else.
With these caps and limits being placed on customers of Comcast and others, I have to wonder if the customer is being protected or endemnified against people attacking their accounts with massive data packets in order to fill up their limits? This wouldn't be a [D]DoS exactly, but potentially, it could be an [E]DoS in effect -- E meaning "Expensive."
I know personally, after having realized this, if I knew any Comcast customers I didn't particularly like, I might be tempted to set up a dyndns entry for their IP address and mention them on slashdot...
Re:So it's a DoS abusing SYN cookies? (Score:4, Interesting)
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.
Re:More scares, AND A TEMPORARY FIX! (Score:3, Interesting)
Re:Pfffft (Score:2, Interesting)
built by David Cutler, on a VMS foundation
What piffle. He took ideas from VMS, that's all.
Cutler was one of the core authors of VMS
More piffle. He was part of a technical design committee that worked on the FIFTH iteration of the OS/hardware combo, and left the project before v1.0.
SYN SHIELDS UP! (Score:1, Interesting)
/sbin/iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN -j DROP
Aye captain!
Umm... (Score:2, Interesting)
TFA> I asked him if he'd be willing to DoS us, and he flatly said, "Unfortunately, it may affect other devices between here and there
So, if it takes out other devices before reaching it's target, isn't there a reasonable chance that the attacker will just isolate himself from the net ?
PDOS (Score:2, Interesting)
I believe this new attack is called a PDOS attack. It specifically targets router firmware.
More can be found at
http://hackaday.com/2008/05/20/phlashing-denial-of-service-attack-the-new-hype/
State based firewalls anyone? (Score:2, Interesting)
If you set up a state-based firewall that limits the number of SYN requests in a given second and drops the rest, I believe that will greatly reduce if not eliminate the threat.