Turning the tables on miscreants who paralyze websites with torrents of junk data, security researchers have published a detailed manual that shows how to neutralize some of the Internet's most popular denial-of-service tools.

The do-it-yourself how-to provides instructions that even hacking novices can follow to exploit critical vulnerabilities in "Dirt Jumper," a family of tools used to wage the crippling denial-of-service attacks. By targeting SQL injection flaws in the software—which is sold for thousands of dollars in underground forums—counter-attackers can commandeer the master control servers used to distribute commands to large numbers of infected computers, which act as foot soldiers in such attacks. The manual was published on Tuesday by researchers with DDoS mitigation provider Prolexic.

"The authors of this malware overlooked security for critical portions of its toolkits," the Prolexic researchers wrote in the report, which can be downloaded here, after completing the Web form at the right side of the page. "The weakest link within this malware family is the insecure coding practices used in the creation of the C&C panels. They are simple PHP/MySQL scripts that are pieced together to manage the infected bots."

A handful of command-line strings, the open-source penetration-testing tool SQLMap, and knowledge of a command server's location are pretty much all that's required to gain access to its back-end database and server-side configuration files. Compromise of the server's Web application can then be used to perform a DIY downing of the host server. Take for instance the following command:

It remains unclear just how easy it is to locate the server address of a Dirt Jumper C&C, although it wouldn't be surprising if the software transmits a unique signature that can be detected using port-scanning software or other tools. What's more, using pilfered credentials to access someone else's account may be illegal, depending on where the hacker and DDoS server are located. Readers are encouraged to seek competent legal advice before trying any of the techniques described here.

It's not the first time white hat hackers have identified crippling holes in blackhat software tools. In 2010, security researcher Billy Rios devised a script that exploited vulnerabilities in the ZeuS crimeware kit, a feat that allowed him to hijack the servers that fed commands and updates to hundreds of thousands of infected computers.

The manual comes as DoS attacks have surged 82 percent since June 2011, according to a recent report by Arbor Networks. DDoSers kept radical transparency website WikiLeaks offline for 10 days, and BitTorrent tracker Demonoid was also out of commission thanks to the attack technique.

Prolexic said the attacks can be wielded by rival malicious actors, researchers, DDoS victims, law enforcement agents, and "any other interested party in possession of a C&C identity." The attacks work against a variety of variants in the Dirt Jumper family, which Prolexic says is among the most popular DDoS attack tools on the market today. The vulnerabilities stem from amateur coding mistakes made by the Dirt Jumper developers. Witness, for example, the lack of "input sanitization" in the mysql_query function of the following PHP code:

The omission is present even in Pandora, the newest member of the Dirt Jumper family. Pandora, which boasts new functionality that makes DDoS attacks more powerful, was recently used against security journalist Brian Krebs's KrebsOnSecurity site. One ad for the new tool claims that it needs just 10 infected computers to bring down an unhardened site, or just 1,000 bots to slow response times for Russia's most popular search engine. The previously reported attack on the Krebs site consisted of "several hundred systems repeatedly requesting image-heavy pages."

In addition to a failure to clean up malicious SQL commands, Pandora contains coding errors that cause infected machines to send broken HTTP requests to C&C servers. We're guessing many of these bugs will be fixed, but it may take a while for DDoS users to apply a patch.

Promoted Comments

I'd like to make a joke out of them using PHP, and writing terrible PHP at that. I ain't no saint, I write a lot of PHP myself. But it was not until recently that I was comfortable writing PHP that I would let others download and use. Not because I did not trust them, but because I did not trust myself. If they are to use my code, then at least it should be stable, as secure as I can make it and maintainable.

The software used at Yahoo!, HB Gary, etc. are internal software, built specifically for that firm. It is never intended to be shipped to customers. Furthermore, I notice that some developers writing their own sites, tend to get rather confident in that their website won't be attacked by spam bots and what have you, because it's unique. They argue that people are more likely to target MediaWiki and WordPress, because they are much much more common.

Dirt Jumper is not internal software, it is distributed software, that many 'customers' are supposed to be using. As such, we are not just talking about a tool you need to write quick and dirty, because you need to wreck havoc now, but something you intend to sell. And your first version may not necessarily be clean, but at least after some years, it might be an idea to make a clean up run. Particularly as the article notes, that the newest version contains these similar rookie mistakes.

Even ending PHP files in ?> is also a sign of an unskilled PHP developer.

I don't necessarily think these are script kiddies, but they are not skilled developers. In any sense of the word.

And seriously, have some self-respect, who would want to maintain this code?!

I think we need some "self-defense" style laws for computing. Currently a counter-attack would be just as illegal as the initial attack.

Sometimes the best defense is offense and if you're shut down for any amount of time because of an attack, that is real money and real time lost to deal with the issue. If the fastest solution is to take down the attacking system, there should be a way to either expedite that process so that it can be legally done immediately or to vet any immediate action later in trial to declare the action necessary and legal.

Nice; he was coming right for my database server, I feared for my data and had no choice!

Although, I would like a little more leniency in the laws for that as well.

Its kindof ironic how in many cases, "hacking" scripts used by script kiddies are some of the worst written, most vulnerable software out there

quick and dirty script is quick and dirty. maybe the mentality is that even a crappy half broken hammer can punch a hole in a wall, so why fix it when you're in a rush to get to the fun part. or they may not even be considering that aspect because they're too busy staying anonymous or out of view. or maybe they're just so wrapped up in being offensive that defense never occurs to them. or maybe they're just morons wielding tools they don't completely understand.

with the hole in that code that was pointed out, you could wipe their whole database provided the script wasn't connected with a select-only account.

Its kindof ironic how in many cases, "hacking" scripts used by script kiddies are some of the worst written, most vulnerable software out there

quick and dirty script is quick and dirty. maybe the mentality is that even a crappy half broken hammer can punch a hole in a wall, so why fix it when you're in a rush to get to the fun part. or they may not even be considering that aspect because they're too busy staying anonymous or out of view. or maybe they're just so wrapped up in being offensive that defense never occurs to them. or maybe they're just morons wielding tools they don't completely understand.

with the hole in that code that was pointed out, you could wipe their whole database provided the script wasn't connected with a select-only account.

Could be that they only address security holes when they become a problem, just like everyone else does.

Its not ironic, most script kiddies are terrible programmers. Otherwise, they wouldn't be script kiddies.

What's your support for saying Dirt Jumper was developed by a script kiddie? Yes, the code is riddled with SQL-injection vulnerabilities, but the same could be said of web apps that are or were used by Yahoo, HB Gary and lots of other sites with professional developers.

Usually the real experts are the ones you never hear about because they've done stuff that would land them in jail for a good long time and they know the value of keeping their mouth shut and their profile low.

I'd like to make a joke out of them using PHP, and writing terrible PHP at that. I ain't no saint, I write a lot of PHP myself. But it was not until recently that I was comfortable writing PHP that I would let others download and use. Not because I did not trust them, but because I did not trust myself. If they are to use my code, then at least it should be stable, as secure as I can make it and maintainable.

The software used at Yahoo!, HB Gary, etc. are internal software, built specifically for that firm. It is never intended to be shipped to customers. Furthermore, I notice that some developers writing their own sites, tend to get rather confident in that their website won't be attacked by spam bots and what have you, because it's unique. They argue that people are more likely to target MediaWiki and WordPress, because they are much much more common.

Dirt Jumper is not internal software, it is distributed software, that many 'customers' are supposed to be using. As such, we are not just talking about a tool you need to write quick and dirty, because you need to wreck havoc now, but something you intend to sell. And your first version may not necessarily be clean, but at least after some years, it might be an idea to make a clean up run. Particularly as the article notes, that the newest version contains these similar rookie mistakes.

Even ending PHP files in ?> is also a sign of an unskilled PHP developer.

I don't necessarily think these are script kiddies, but they are not skilled developers. In any sense of the word.

And seriously, have some self-respect, who would want to maintain this code?!

I'm surprised Ars covered this in such detail - it's almost a cookbook for meddling with another person's computer. Whether you're breaking into and fiddling with someone else's machine for nefarious purposes, or for the lulz, or to stop that machine from attacking yours, it still feels like crossing a line, legally and ethically. Do unto others before they do unto you, or to stop them doing unto you, or something. I totally understand wanting to stick it to the bastards... but sinking to their level still seems wrong.

Couldn't the white-hat hacker breaking into a C&C machine like this, with the best of white-hat intentions, couldn't (s)he still be charged with, um, whatever it is they charge hackers with?

*snerk* Reading this made me wonder; how hard would it be to circulate some code that would identify the user before, during, and/or after the attack. Just give em the stick and let em thwack the hornets nest.

Although I appreciate the effort the white-hat hackers have put into this, I question the value of publicly releasing this information. Now that this info is public I can see three things happening:

1. Some well meaning vigilantes attack some C&C computers, potentially getting themselves in a lot of trouble.2. Some more knowledgeable black-hat crews take over some C&C computers and block future attack attempts.3. The creators of "Dirt Jumper" fix their problems.

Wouldn't it have been better to turn over this info to an organization which actively tries to take down botnets. (I seem to recall Microsoft had a hand in at least a couple of takedowns.) The attack is kept secret and C&C servers get killed without anyone being the wiser.

I'm surprised Ars covered this in such detail - it's almost a cookbook for meddling with another person's computer. Whether you're breaking into and fiddling with someone else's machine for nefarious purposes, or for the lulz, or to stop that machine from attacking yours, it still feels like crossing a line, legally and ethically. Do unto others before they do unto you, or to stop them doing unto you, or something. I totally understand wanting to stick it to the bastards... but sinking to their level still seems wrong.

Couldn't the white-hat hacker breaking into a C&C machine like this, with the best of white-hat intentions, couldn't (s)he still be charged with, um, whatever it is they charge hackers with?

From the article you're commenting on:

"What's more, using pilfered credentials to access someone else's account may be illegal, depending on where the hacker and DDoS server are located. Readers are encouraged to seek competent legal advice before trying any of the techniques described here."

That said, security researchers in multiple legal jurisdictions regularly access command and control servers and also intercept bot communications through a technique known as sinkholing. Look it up online and you'll see that employees of Fortune 500 companies do this regularly. I'm guessing these employees have gotten the blessing of their legal department.

That's right, point out the flaws in the black hats' malware so they can fix them.

We need better black hats so that we can increase demand for better white hats. Arms races are great for innovation. Besides, the opportunity for publicly shaming the script devs for using the same careless code that they're exploiting in other people's careless code is too rich to let slide.

Even ending PHP files in ?> is also a sign of an unskilled PHP developer.

I'd consider myself a 'skilled PHP developer' but I have no idea why ending a PHP file in ?> is a sign of being unskilled?

*skilled as PHP go. It's not my first or primary language.

Saying that there is only one side to this _is_ the sign of an unskilled PHP coder...

It's an ongoing debate with valid points on both sides. Omitting the closing tag makes the parser automatically add it at the EOF, which avoids inadvertently having white space after the closing tag which might output. Its an anonying problem tp troubleshoot. Anyway, thats the gist, Google for more, it's really off topic here...

*snerk* Reading this made me wonder; how hard would it be to circulate some code that would identify the user before, during, and/or after the attack. Just give em the stick and let em thwack the hornets nest.

Not hard at all, though doing that is also poking the fate bear - there's going to be more than a few people upset enough to come after you for it... and not all of them are going to be little shits wasting university bandwidth from a sexless dorm room.

I think we need some "self-defense" style laws for computing. Currently a counter-attack would be just as illegal as the initial attack.

Sometimes the best defense is offense and if you're shut down for any amount of time because of an attack, that is real money and real time lost to deal with the issue. If the fastest solution is to take down the attacking system, there should be a way to either expedite that process so that it can be legally done immediately or to vet any immediate action later in trial to declare the action necessary and legal.

"If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script."

"If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script."

And here we see the inconsistencies inherit in the language. The crap shoot that PHP is comes from this undisciplined, immature view of proper syntax and coding. It is true that "the violence inherit in the system" is the fault of the PHP developers themselves, encouraging this hackfest. it's like they wanted to be Perl programmers but can't grow a beard so the kiddos invented this to feel cool in their own right.

I've actually been able move my web coding to either Drupal (isolated from PHP, but still praying some kiddo coded the module right) or C++ via Wt ( http://www.webtoolkit.eu/wt ) when I can't trust the kiddos.

"If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script."

My statement included using the closing tag as proper syntax, but did not exclude the practice of not using the closing tag when you aren't shoving anything out the door. Either way is proper, as we both pointed out in the link. My point was that you can't be considered unskilled when you're doing it one of two ways that are established as acceptable. I've done it both ways.

From the standpoint that there isn't anything preventing the original attack by the criminal black-hats, self-defense might be the only option at least for the near future. Trying to execute a remote warrant (ie like Dotcom in NZ) doesn't eliminate the issue. Shutting down and destroying the command and control server can perhaps prevent future events but might not stop the current attack. With the Internet being everywhere, its entirely possible the perpetrator is in another national jurisdiction that doesn't see things like you do. The wild-west is back.

It seems as if the world is already at digital war with StuxNet/Flame/DuQu etc going after military and political targets. The national military organizations have that venue.

Could a country sanction a team of "gun-fighter/deputy sheriffs" (white-hat hackers) to "officially" do the penetration and server take down under a legal structure of some kind? The concern is that commercial and not-for-profits websites are already getting hammered by idiots justifying their lulz as "activism/free speech". Bank accounts, credit cards etc are much more worrisome targets and should take priority over sites like Wikileaks and the like. Even though the attack is on a website the victims are the customers of those sites and the financial structures behind the website's front page. A ddos attack if successfully shutdown each time it happens will eventually make the effort pointless. Even an idiot can learn a lesson that way. Other attacks going after credit information, medical records etc ought to be handled much more securely than currently.

Credit card, financial services and bank account attacks will require compliance with regulation and best practices, something that seems very unevenly applied today. Might be a carrot is necessary, "You want FDIC (and other insurance)? Do what we tell you to do to protect your customer's money."

I think we need some "self-defense" style laws for computing. Currently a counter-attack would be just as illegal as the initial attack.

Sometimes the best defense is offense and if you're shut down for any amount of time because of an attack, that is real money and real time lost to deal with the issue. If the fastest solution is to take down the attacking system, there should be a way to either expedite that process so that it can be legally done immediately or to vet any immediate action later in trial to declare the action necessary and legal.

Nice; he was coming right for my database server, I feared for my data and had no choice!

Although, I would like a little more leniency in the laws for that as well.

I think we need some "self-defense" style laws for computing. Currently a counter-attack would be just as illegal as the initial attack.

Sometimes the best defense is offense and if you're shut down for any amount of time because of an attack, that is real money and real time lost to deal with the issue. If the fastest solution is to take down the attacking system, there should be a way to either expedite that process so that it can be legally done immediately or to vet any immediate action later in trial to declare the action necessary and legal.

Nice; he was coming right for my database server, I feared for my data and had no choice!

Although, I would like a little more leniency in the laws for that as well.

Actually, all you have to do is yell "It's coming right for us!" before they can attack you so you can claim it was in self-defense.

<snip>And here we see the inconsistencies inherit in the language. The crap shoot that PHP is comes from this undisciplined, immature view of proper syntax and coding. It is true that "the violence inherit in the system" is the fault of the PHP developers themselves, encouraging this hackfest. it's like they wanted to be Perl programmers but can't grow a beard so the kiddos invented this to feel cool in their own right.

I've actually been able move my web coding to either Drupal (isolated from PHP, but still praying some kiddo coded the module right) or C++ via Wt ( http://www.webtoolkit.eu/wt ) when I can't trust the kiddos.

You do realize calling people "kiddos" makes you sound like a colossal asshole, right?

I think we need some "self-defense" style laws for computing. Currently a counter-attack would be just as illegal as the initial attack.

Nice; he was coming right for my database server, I feared for my data and had no choice!

Although, I would like a little more leniency in the laws for that as well.

While I absolutely agree with the original sentiment (although I'm not sure how true it really is, sinkholing was already mentioned in this very thread, which goes in a similar direction but is used by lots of whitehat researchers), from a practical point of view chances are probably low that the operator of a C&C server for DDOS attacks would go around complaining about being hacked

<snip>And here we see the inconsistencies inherit in the language. The crap shoot that PHP is comes from this undisciplined, immature view of proper syntax and coding. It is true that "the violence inherit in the system" is the fault of the PHP developers themselves, encouraging this hackfest. it's like they wanted to be Perl programmers but can't grow a beard so the kiddos invented this to feel cool in their own right.

I've actually been able move my web coding to either Drupal (isolated from PHP, but still praying some kiddo coded the module right) or C++ via Wt ( http://www.webtoolkit.eu/wt ) when I can't trust the kiddos.

You do realize calling people "kiddos" makes you sound like a colossal asshole, right?

Well.. in a way he had a point.. I mean I did feel the need to shave my beard so I moved from PERL to PHP as my primary web application language almost 12 years ago. Beards are itchy, but no self respecting PERL programmer would be caught without one, so I felt I had little choice.

You do realize calling people "kiddos" makes you sound like a colossal asshole, right?

Probably, but it takes one to know one - and I'm referring to the "kiddos" part. When I was 19 and coding in PHP 2.0, it was all the rage. I'd say I pretty regularly used PHP up until the late 4.x releases. having learned many more languages since then (C++, JavaScript, Java, Python, Assembly, etc) then looking back on it, PHP is really a language for amateurs. It was back then, and it still is now. The whole ?> issue highlights the point. The syntax for OOP is atrocious, and every time I look into the language to see what's new I just shake my head.

I'll give PHP the credit it deserves - that it powered the whole .com boom 10 years ago. But it hasn't matured as its users have. (Maybe they haven't). I always seem to be ahead of the curve, so maybe PHPers aren't ready to hear this. PHP remains a dangerous language to wield. Very easily you can make a hackable site as this article shows, but it takes someone to truly understand web development to make a safe site. And that is why PHP gets such a bad rap. If PHP made it harder to do the bad stuff it wouldn't be as bad, but the easiest stuff to do in PHP is the worst.

Any mature coder can code safely in PHP, but my hunch is they won't want to.

Very easily you can make a hackable site as this article shows, but it takes someone to truly understand web development to make a safe site. And that is why PHP gets such a bad rap. If PHP made it harder to do the bad stuff it wouldn't be as bad, but the easiest stuff to do in PHP is the worst.

So since the exploit in this case is based on a SQL injection, please name the languages that make SQL injections harder to make.

Java? Nope, allows string concat. Python? Same. Perl? Almost funny.

Blaming the language can make sense if there are working constructs in other languages that show how you can do it better (e.g. GC instead of manual memory management), but for things like XSS attacks or SQL injections the solution is the same in __every__ language I know: Use the right library and don't piece strings together. That's as language agnostic as you can get.

Not that I care much about PHP, never used it seriously, but the kind of security problems we're talking about, can at the moment only be remedied by better education.

Very easily you can make a hackable site as this article shows, but it takes someone to truly understand web development to make a safe site. And that is why PHP gets such a bad rap. If PHP made it harder to do the bad stuff it wouldn't be as bad, but the easiest stuff to do in PHP is the worst.

So since the exploit in this case is based on a SQL injection, please name the languages that make SQL injections harder to make.

Java? Nope, allows string concat. Python? Same. Perl? Almost funny.

Blaming the language can make sense if there are working constructs in other languages that show how you can do it better (e.g. GC instead of manual memory management), but for things like XSS attacks or SQL injections the solution is the same in __every__ language I know: Use the right library and don't piece strings together. That's as language agnostic as you can get.

Not that I care much about PHP, never used it seriously, but the kind of security problems we're talking about, can at the moment only be remedied by better education.

Every SQL example in PHP is a concatenation. There is very little push for education of the parameter binding interface. But constructing SQL statements is found everywhere,because it is easy to do and can be done using fundamental concepts. One of the constructs though that gets people away from doing that is a model-view architecture, where the model-view library is responsible for using a parameter binding interface as well as query construction. I do no know of one (or a standard one) in PHP. There very well might be one though. Java and .NET have [N]Hibernate.

Next up, this is an old one, but the view source feature. You had ot be sure you don't put your logon credentials in a PHP file because someone could view source, yet this file could contain PHP and be included() as needed.

But you're right that education solves all the issues. But that's like saying iOS and Android are functionally the same because given equivalent hardware, it's just software. There is something to be said for the mentality and the culture. And that is what I am criticizing. The culture of 'leave ?> off'