Slashdot Mirror
New Low Bandwidth Denial of Service Attacks
An anonymous reader writes "A paper from Rice University
appearing at the
2003 ACM Sigcomm Conference presents a new denial of service
attack where the attacker only needs to send at a low rate
to shutdown TCP flows. The trick exploits the retransmission timeout
mechanism in TCP. By sending small bursts of packets at just the right
frequency, the attacker can cause all TCP flows sharing a bottleneck
link to simultaneously stop indefinitely. And because the attacker
only needs to burst periodically, the attacker will not be
distinguishable from normal hosts. The presentation, and other
presentations from the conference, are available online (live
streaming)."
When I read the title, I imagined a hoard of old geezers, using walkers, coming at me with sticks... but seriously, I don't see how this type of attack could prove as unstoppable or undetectable as claimed; I'm not particularly briefed with the mechanics of Retransmission Time Out, but can the mechanism not be tweaked to avoid these types of attacks without sacrificing all of its benefit?
Actually the paper address defense mechanisms, such as randomly varying the time out interval, but it turns out that the performance lost in TCP efficiently nulls any benefits. Interesting paaper.
Not to rain on the parade here, but I thought there were a number of more interesting papers from sigcomm this year. Namely:
- Peer-to-Peer Information Retrieval Using Self-Organizing Semantic Overlay Networks
- Quantum Cryptography in Practice
- Making Gnutella-like P2P Systems Scalable
Just some more food for thought....
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Back in my days as a satellite network controller for the Army it was common knowledge all it takes to saturate the whole frequency range for the commo payload is a nice 75Khz spike (enough carrier for a FM orderwire signal). People would argue it could not be done since we pretty much owned the 7.25->8.4 GHZ spectrum, but it worked pretty damn well. This is the equivalent of saturating a T1 with a 14.4 modem.
Pedro
----
The Insomniac Coder
When the number of flows in the system is high, a fraction of flows' retransmission timers will expire sufficiently near time (alpha) such that those flows can partially recover and utilize the available bandwidth in the period from time (alpha) to time (beta), when all flows will again experience an outage.
Bah, the paper isn't that bad. Heck, without reading the whole thing and knowing a little bit about what they discuss (based on the first section), I can understand what you've quoted (if I'm correct, this is from their section on mitigating attacks using randomized RTOs).
Really, the basic concepts are *incredibly* simple. Send a burst of traffic which causes drops in the short term. This results in the TCP stack backing off and re-transmitting the packet after the defined RTO. So, if you hit the stack with another burst of packets just as the RTO is expiring, the stack will back off again. Lather, rinse, repeat. This requires a lot less traffic, since your bursts are spaced apart (roughly a second per burst, typically, since that's a pretty standard RTO).
Really, all you need is a basic understanding of TCP flow control to understand the concepts in this paper (which, BTW, they attempt to explain in the first section). The rest of the content (modelling TCP flow rates relative to DoS flow rates, etc) is really just the formal analysis of the basic attack, which certainly isn't important if all you care about is implementing it.
Essentially this says that all you do is to continually convince TCP that the 'pipe' is full of information and to take counter measures.
TCP will do this with a preset procedure that was designed to elminate deadlock situation. The problem occurs when everytime the TCP stack trys to resend the information, you can fool it by filling the 'pipe' again. As long as you know when the TCP stack will retry again, you can continue this over and over. Because it does not take a lot of information to fill the 'pipe' for the short time that TCP attempts to resend, you can have a low bandwidth attack.
In the latest Lovsan.* worm outbreak, the worm was programmed to generate a DDoS attack to www.windowsupdate.com, only the attack was not very successful because that domain was just a means of redirection to the real Windows Update site (windowsupdate.microsoft.com), so Microsoft just shut it down and avoided any harm.
But with this low-bandwidth exploit, which I believe is actually not a new idea, since IE uses a tricky method to increase speed by leaving persistent connections until they time out that could be exploited, now a worm can potentially DoS any website, even dynamically selecting the target from the users' IE favorites and performing the attack very quickly (maybe in a matter of hours) without having to rely it on being a widespread, coordinated DDoS or what the target OS/Server is.
The paper even claims that in order to protect a server from this type of attack you'd need to sacrifice a good deal of performance, which in most cases is not acceptable so many people can't really afford to implement defenses. Either a clever workaround is made for this exploit, or we have tough times ahead from worm outbreaks and script kiddies.
- Otaku no naka no otaku, otaking da!!!
The phone system has an 8 KHz bandwidth... I think it's something like ~150 Hz - ~8000 Hz. At least that's the spec. Some very old lines aren't that good, some newer lines are far better.
:)
:) (although that's not true world wide...). Interesting stuff.
And there's a boatload of various technologies (loading coils for example) that are designed around maintaining those frequencies at the cost of all others, which causes problems with high speed modems and utterly breaks DSL.
It's ok that your data is from the 1990s... the phone system was designed in the 1930s and hasn't changed dramatically since
I had the pleasure of seeing the inside of a CO in downtown Atlanta in the early 90s. From the battery room with 45 gallon drums of baking soda in case of an acid spill, to the entryway with cables varying from the thickness of your arm (old, old, old copper) to less than a pencil (fiber), to 40 foot by 3 foot by 6 foot long switches that were being replaced by a pair of boxes the size of Coke machines. All an interesting mish mash of old and new technologies and all working together. At least they'd gotten rid of the mechanical switches