How To Crash The Internet With One UDP Packet

As an extra treat for those celebrating the 20 year anniversary of DNS, I figured it was a good time to spread a little fear uncertainty and doubt (FUD).

If you would like to bring down the entire Internet with one UDP packet; here’s how:

]]>< ![CDATA[

1) You need to read and understand the impact of a rogue UDP packet. Study the technical details of the SQL Slammer UDP packet.

2) You should already know that DNS runs on UDP port 53 on over 350,000 servers on the Internet. That’s a big pool of attach zombies.

3) You need some background in the insecurities of the Berkley Internet Name Daemon (BIND). According to SANS and CERT, BIND vulnerabilities are a perennial “Top 10” target of attacks on the Internet today. Here’s a quote from a Wired Magazine article from 1997 that highlights how insecure the DNS system was (and is):

What’s worse, the domain name system is fundamentally insecure. By transmitting rogue packets to a computer, a hacker or information terrorist can confuse that machine, cajoling it into contacting one machine on the Internet when it means to reach another. Under certain conditions, a hacker can use DNS spoofing to break into a computer. DNS spoofing can be used to redirect or steal electronic mail, intercept pages sent over the World Wide Web, or impersonate other Web surfers. It’s easy, untraceable, and becoming more common all the time.

Interestingly the article mentions DNSSEC as a solution. Well it is 6 years later and we’re not much closer to wide spread DNSSEC deployment than we where when the article first appeared.

4) Here is where you are on your own. You need to find an as yet unknown buffer overflow error in BIND. If you are not successful in that endeavor you could try a buffer overflow on another version of DNS, but your pool of zombies is going to be very small in comparison to BIND. You need to be able to inject your code in much the same way as the Slammer packet did – that part shouldn’t be too hard. Finding the vulnerability will be the hard part.

5) Once you’ve crafted your packet, you’re ready to go. What you do with your knowledge is up to you; you can sit on the knowledge, announce the buffer overflow error to security news lists, or sell your knowledge to a rouge state of terrorist group

6) Send your first packet and the entire Internet should crumble under the weight of hundreds of thousands of packet spewing BIND servers in less that 15 minutes. The extra bonus in this case is that the standard port blocking defense by administrators shuts down the Internet as well, since no one can resolve machine names to IP addresses.

Does this sound like a doomsday scenario? The Internet as we know it would be down for a few days to a week. Certainly not end of the world material, but the cost to the US economy alone would probably make the observed economic costs of 9/11 look like a small market correction. The really scary part is that the “magic” packet could already exist.

Update: This doomsday scenario requires an, as yet, unknown vulnerability be discovered. There are also a number of different scenarios (not discussed here) where an existing vulnerability could be exploited in a way that would create the kind of multiplier effect that SQL Slammer did. Much smaller attacks have already placed the DNS root servers in jeopardy.

What a variety of knowledgeable folks are saying in the aftermath of the SQL Slammer episode is that UDP hacking will increase and BIND could be the next recipient of a magic packet attack. Remember no one ever traced the author of the SQL Slammer packet.

Just in case you were wondering about known DNS vulnerabilities, here the SANS List on DNS Vulnerabilities. Notice the frequent use of the term “buffer overflow”.

BIND is a frequent target of attack and its security posture (when properly maintained) is good. The problem is that most BIND servers are either improperly maintained or improperly configured.

Sleep tight!