How Spamhaus’ attackers turned DNS into a weapon of mass destruction

A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet's Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, "Operation Global Blackout" (later dismissed by some security experts and Anonymous members as a "massive troll"), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.
This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn't brought the Internet itself down, it has caused major slowdowns in the Internet's core networks.
DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or "volunteer" systems within their networks to stage such attacks. But thanks to public cloud services, "bulletproof" hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.

Hello, operator?

The Domain Name Service is the Internet's directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a "root" DNS server keeping a list of each of the "authoritative" DNS servers for each domain registered with them. If you've ever bought a domain through a domain registrar, you've created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.
When you type "arstechnica.com" into your browser's address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you've requested a host name that's in a local "hosts" table for servers within your network, or one that's stored in your computer's local cache of DNS addresses you've already looked up.) But if it's the first time you've tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google's Public DNS.
There are two ways for a resolver to get the authoritative IP address for a domain name that isn't in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain's DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or "zone" within a larger domain—such as www.subdomain.domain.com—it may tell the resolver to go ask that zone's DNS server. The resolver "iterates" the request down through the hierarchy of DNS servers until it gets an answer.
But on some networks, the DNS resolver closest to the requesting application doesn't handle all that work. Instead, it sends a "recursive" request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.

How DNS queries are supposed to work—when they're not being used as weapons.

To save time, DNS requests don't use the "three-way handshake" of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a "connectionless" protocol that lets the server fire and forget requests.

Pump up the volume

That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.
The "amplification" in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers' victim.
DNS amplification attacks wouldn't be nearly as amplified if it weren't for the "open" DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was "as high as 10Gbps and used as many as 140,000 exploited name servers," Vaughan and Evron reported. "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."
But even if you can't find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A "root hint" request—sending a request for name servers for the "." domain—results in a response 20 times larger than the packet the request came in. That's in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.

A comparison of a "root hint" query and the response delivered by the DNS server. Not all data shown.

 

 

 

In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider's site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.
But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.

No fix on the horizon

The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that "simple" fix isn't exactly easy—or at least easy to get everyone who needs to participate to do.
There's been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force's BCP 38, an approach to "ingress filtering" of packets. First pitched in 2000  1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even "root hint" responses received from outside their own networks, that would require action by the owners of the network. It's an action that doesn't have a direct monetary or security benefit to them associated with it.
ISPs generally do "egress filtering"—they check outbound traffic to make sure it's coming from IP addresses within their network.  This prevents them from filling up their peering connections with bad traffic.  But "ingress" filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.
Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets.  DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it's unlikely that would ever happen, considering that you can't even convince people to properly configure their DNS servers to begin with.
Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn't seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And maybe pigs will fly.

Bron: Arstechnica

Details on the denial of service attack that targeted Ars Technica

Last week, Security Editor Dan Goodin posted a story about the "swatting" of security reporter Brian Krebs and the denial of service attack on Krebs' site. Soon after, Ars was targeted by at least one of the individuals behind the Krebs attack. On Friday, at about noon Eastern Daylight Time, a denial of service attack struck our site, making connectivity to Ars problematic for a little less than two hours.
The attack continued to run throughout Friday. At 9pm EDT, when our hosting provider brought down one of the filters that had been put in place to thwart it, it quickly became apparent that the attack was still underway, and the filter was restored. The most aggressive filters were finally removed on Saturday.
At least in part, the offensive used the same attack tool and user credentials that were involved in the denial-of-service (DoS) attack on Krebs On Security, as Krebs himself revealed in a blog post. The attackers used multiple accounts on TwBooter, a "booter" site that provides denial of service attacks as a paid service (ostensibly for security testing purposes), to launch an automated, denial of service attack on Ars. And at least one of those logins was also used to attack Krebs' site.
TwBooter masks all of the complexity of launching attacks against sites. Users of the site can, depending on how much they pay, launch up to three simultaneous automated attacks against sites through a simple Web interface. TwBooter users can even set up multiple accounts and fill up the queue of the service's "attack server."

Individual accounts using TwBooter's server can be "licensed" for up to three simultaneous attacks lasting up to two hours, if you can come up with the cash. Free plans can be set up in exchange for filling out a few surveys.

It doesn't cost much to get in on the ground floor with TwBooter—an account with rights to a single automated attack of up to 60 seconds in length is $10 for a month. This means you can launch as many 60 second attacks as you want, one at a time, all month long. The "license" to launch up to three attacks at a time of up to two hours duration is $169 a month—but there's a 20 percent discount if you pay through Liberty Reserve instead of PayPal. There's also a free plan that allows for attacks up to 300 seconds long. That service requires users to pick an attack type from a pull-down menu in a Web form.

The Web form for launching attacks from TwBooter's free attack service.

PayPal payments for the site are routed to Sebastien Lariviere, a former IT technician for the county government (MRC) of Pierre-De Saurel in Quebec (now operating as Lariviere Security). Lariviere did not respond to e-mails from Ars for comment.
Obviously, sites like TwBooter generate a lot of ill will and are ironically the target of DoS attacks themselves. Like many legitimate and "black hat" sites—such as the site exposed.su, a website that recently posted the personal information of many public figures—TwBooter runs behind the CloudFlare content delivery network as a way of shielding itself from attacks.
TwBooter may not have been the only service used to launch the attacks on Ars and Krebs. "There are dozens of these booter services out there, most of them based on the same source code," Krebs told Ars. But Krebs received a tip pointing to a dump of TwBooter's customer database—openly accessible on the services' website. It's clear the TwBooter site was part of the attack. A snippet from the SQL dumps Krebs provided to Ars show that multiple attacks (including Slowloris, TCP amplification, and SYN flood attacks) were queued up by multiple accounts on the site.

Pick your poison

Some of the attacks served up by TwBooter are targeted at Web servers themselves. For example, HTTP Get and Post attacks attempt to overwhelm the ability of the targeted server to respond by filling up buffer memory with requests. But there were a few attacks thrown at Ars that don't require the massive traffic of a million-PC botnet.
Slowloris, for example, takes a less brute-force approach—it's a slow HTTP attack that exploits a misconfiguration of the Apache Web server. It sends partial HTTP requests to its intended victim, which forces the server to keep the connection open while waiting for the rest. Because it relies on very little traffic to do the job, it doesn't have to be distributed to work. But since it's dependent on the target being an Apache server that hasn't been tweaked against the slow HTTP style attack, it's not very effective against high-volume Web servers (especially sites using NGINX Web servers, like Ars).
Another attack used against Ars was the RUDY, or R-U-Dead-Yet attack, which also uses relatively few packets. Instead of sending partial requests, it sends what seems like an unending HTTP POST, sending a very large value for content-length in the POST request header. That keeps the server waiting for the rest of the POST to come until the length is reached... which never happens.
Other attacks in the "booter" arsenal go after the network connections of the targets themselves. SYN Flood attacks, for example, attempt to overwhelm the target's network connection by creating a huge volume of "half-open" network connections, using the nature of the TCP protocol's "three-way handshake" to use up server resources. The attacker sends SYN, or "synchronize," requests to the target; the target responds with a synchronization acknowledgement (SYN-ACK), which would normally prompt a return acknowledgement (ACK) message from a legitimate user connection. Instead, the attacker never sends ACK packets back, and the target is left with unfinished connections filling up its network buffers until it can't handle any more connections. These packets are usually sent with forged headers (since the attacker never has to actually get the SYN-ACK from the server), so they're difficult to trace and can appear to be more distributed than they actually are.
Another attack type flung at Ars was a UDP-LAG attack. It just uses a large stream of UDP packets in an attempt to overwhelm a target's network connection and knock them offline. UDP-LAG attacks on "booter" services are often used by online gamers who want to slow down the network connections of a competitor. This way, they can camp on their location and kill them while they lag, respawn, and lag some more. Because they use UDP packets, UDP-LAG attacks in large volume can look like DNS amplification attacks—attacks that use responses from DNS servers to spoofed requests that give the address of the target.

Shrugging it off

Fortunately, Ars' hosting provider was able to quickly identify the attacks that were causing the most damage to site availability. Our IT team alerted our provider to the problem at 12:09pm EDT on Friday; the problem was mostly in hand by 1:30pm through the application of traffic filters at the provider's router.
But the fact remains that anyone with some spare change, spare time, and an axe to grind can turn to sites like TwBooter and stage DOS attacks at will—with little fear of retribution. The sites come and go, hiding behind the thin veil of a "terms of service" agreement that asks users, pretty please, to not misuse their attack servers. These booters profess that they are for "security professionals only"—yet they do little to track the actual identities of those who use the servers.

Bron: Ars technica