Details on the denial of service attack that targeted Ars Technica

Take a "booter" site survey, earn attacks like ones that targeted Ars, Brian Krebs.

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."

Enlarge/ 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.

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

Update: PayPal payments for the site are routed to Lariviere Security. In an email to Ars, the operator of the company said "I manage sales for different online developer teams. I have no affiliation pretty much to the projects."

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.

Update: Brian Krebs did some further reporting on the TwBooter hacker's identity today. Krebs found the same individual may have been involved in the Krebs swatting, the Ars DoS, and the identify theft executed on Wired's Mat Honan last fall. Information about Krebs' findings have be spun out into an additional post.

Ars was pretty unusable the entire day, at least as far as the forums were concerned... it sure as hell wasn't 90 minutes.

Yeah, the forums were down pretty much all day for me. Half a page would load, then it would stop loading (I'm guessing it was a filter kicking in or something). I don't remember noticing any effect on the Ars mainpage, but maybe I just didn't notice.

Worth noting that we've got an entire series of articles on securely setting up Nginx and doing fun & useful things with it, starting here. Nothing's immune to a big distributed denial of service attack, but a well-configured web server can help you dodge some of the sneaker methods (as well as anything aimed at older versions of Apache!).

Ars was pretty unusable the entire day, at least as far as the forums were concerned... it sure as hell wasn't 90 minutes.

Interesting, because you and I are geographically similar, and yet once the filtering kicked in I was able to use Ars as normal, with some occasional lags or slower responses than I'm used to. Forums and all.

After the initial couple hour period, everything worked very close to normal except for the article comments. Comment pages would stop loading after only a few showed up on the page and when they sometimes did show up, the delay was very noticeable. This behavior lasted, for me, all the way through the evening on Eastern time.

I was very pleased with how everything worked, considering, and I'm glad you took the time to follow up with the specifics!

I didn't even notice any problems on Friday. Then again our work firewall went ape and started trying to block large swaths of the Internet by recategorizing everything, that kinda masked what was going on.

At my university, you guys were inaccessible via the campus internet completely for a number of hours on Friday, but I could still connect via LTE from phone/iPad. The IT people said it was probably due to routing disruption upstream (a traceroute died at the first jump, inside the campus). What part of the DOS would cause that?

What kind of retard 'hacker' DDoSes a site for simply reporting news of a hack?

It's a shame that these tools are available to any greasy basement-dweller who thinks the world owes him wealth and respect. It used to be only people who had the brains to hack who could perform a hack, but money makes all things available in the end.

Meh. We tried out RioRey at the data center where I work. We were not impressed. It has a large false-positive rate and a low true-positive rate. Meaning, it blocked more of the legit traffic than the attack. Their support wasn't able to improve that. This over the course of a month of various DDoS's. (It did best for SYN floods and UDP floods, worst for GET/POST type of attacks).

Hmm, if those "pay for DoS" sites were really serious about only using their services for legitimate purposes, they could simply contact the target site's webmaster(s) and say "hey, did you authorize this" or something similar.

Heck, they could have it in their ToS that says "if they say no, we still get to keep your money." They keep the dollars, and nothing gets DoS'd. Won't happen, though, I think, as it would still cut down on much of their revenue.

Any instability later in the day on Friday was likely due to some agressive packet filtering being done by our provider. It seemed to be more harmful to people connecting using Windows or through certain corporate proxies.

Ars was pretty unusable the entire day, at least as far as the forums were concerned... it sure as hell wasn't 90 minutes.

Interesting, because you and I are geographically similar, and yet once the filtering kicked in I was able to use Ars as normal, with some occasional lags or slower responses than I'm used to. Forums and all.

Check the mods e-mail from that day, forums were pretty much unusable for the entire day, at least as far as e-mails to the moderation team as well as the internal discussion the mods were having showed.

Not sure if it might've been ISP dependent? Then again it was across multiple ISP's for me that day so I don't think that was it.

Eric wrote:

We were really focused on keeping the front page and CMS humming along, which we managed to do after the first 90 minutes or so.

Ars was pretty unusable the entire day, at least as far as the forums were concerned... it sure as hell wasn't 90 minutes.

Interesting, because you and I are geographically similar, and yet once the filtering kicked in I was able to use Ars as normal, with some occasional lags or slower responses than I'm used to. Forums and all.

It was pretty much unusable all day for me, too. Both from here in the Bay Area, and from one of my remote sites in San Diego. FWIW.

No offense, but why does half the article seem to be marketing for a DDOSing service? Is it really necessary to explain to people how cheap it is to do this kind of thing to sites? Isn't it kind of counter-productive?

And yet no mention of your ISP's name who was able to protect you from it. Kind of backwards, isn't it?

But the fact remains that anyone with some spare change, spare time, no life to speak of, and an axe to grind can turn to sites like TwBooter and stage DOS attacks at will—with little fear of retribution.

No offense, but why does half the article seem to be marketing for a DDOSing service? Is it really necessary to explain to people how cheap it is to do this kind of thing to sites? Isn't it kind of counter-productive?

And yet no mention of your ISP's name who was able to protect you from it. Kind of backwards, isn't it?

Obviously the author's intent is to cast light on how easy it is to buy a DDoS, and how anonymous the whole thing is. There oughta be a law and all that.

Sean Gallagher / Sean is Ars Technica's IT Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland.