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?
I'm pretty certain that my firewall would flag the bursts. If not, seems a simple rule or two would suffice to flag them. I'd like to see this in action. I suspect that it is pretty lame and easily detected.
My guess is that by Friday night, the kiddies will have thousands of these going. So, I guess I can do see for myself tomorrow.
"If you want to improve, be content to be thought foolish and stupid." - Epictetus
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.
a step-by-step recipe on how to screw up the internet even worse. I thought common sense dictated that you don't release documentation of a vulnerability until there is a fix available for it. I know security by obscurity doesn't work, but in the case of fundamental flaws in the TCP architecture... well, I'd rather the script kiddies find out about it later rather than sooner. Aren't we overdue for a TCP replacement anyway? One that supports sequenced packets as well as byte streams, and one that allows windows that scale to gigabyte sizes (yes, I know there's already a window scaling kluge). Do we even have a good defense against syn-floods yet? Seems like the only way of fixing the problems would be to add an unspoofable signature to ever packet so we can be certain where it came from, but this would add serious packet overhead... perhaps you could make the packet size much larger to compensate. (Will terabit ethernet still use a 1496 byte maximum packet size? How long a preamble does it need at that bit rate?)
"Freedom means freedom for everybody" -- Dick Cheney
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
In my vague understanding of TCP, I thought that the retry timers were supposed to have a random element to them. In fact, some systems talk of using cryptographic random sources so that the delays aren't predictible.
If that isn't the case in implementations, it would seem to be implementation error, not really a fault with the protocol itself.
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.
...resonance frequency.
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.
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!!!
I already discovered this about 1.5 years ago while working on a networkmonitoring application. I was keeping it quiet because of the low cost way of causing a lot of trouble with this would be to much for script kiddies to ignore.
In a test run from the local LAN to the WAN, my colleages where complaining terribly about slow connections, but when I looked I was only using about 5% of the bandwidth, so why would I be the problem.
The thing I discovered that I was sending out small packets (64 byte) at the frequency of the latency, thus causing packet fragmentation (no 1500 byte packet fitted in between my well timed transmissions). The result was packet fragmentation on the local network, and retransmits of smaller packets needed over the internet. They caused more trouble on the line, further degrading the performance. My test however didn't seem to suffer. The test data was perfect (-:
This was a 2mbit line connected to my local 100mbit line. What I am wondering is how you can get this way of attach going if you don't have enough control over the timing. If you put packets on the line on your own line (DSL, typical latency 16 to 17ms), and attack a 6ms line, your packets will arrive with way to big gap in between to do any harm (except suck up a part of the bandwidth and in that way becoming a standard DOS attack. So the only way to do this is if your line has a equal or lower latency, or use perfect timing millisecond timing over several slower lines.
The internet itself is causing some trouble too: Every hop in between means bigger bandwidth and lower latencies. A chance for the router to insert good working packets in between the packets of the attack.
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