Share this story

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.

46 Reader Comments

remember the "globals" issue in php? That wasn't even a language problem, that was a default configuration problem that created a pretty nasty hole IIRC.

I kind of have to agree with @voo42 here. Syntax dialects aside, its really not the language that's the problem. Its how its used. Prepared statements can resolve a lot of problems, and a lot more can be resolved by taking a good look at the input before using it and making sure your configuration is solid. PHP has a lot of good to offer and can be safely used as long as you are aware of its flaws.

I think what's missing in a lot of cases is a good understanding of the underlying and companion systems, such as how the web server works, how the database works, and how permissions affect things, etc. No language can save you if you plop GET/POST vars directly in your statements and connect to your database as a very privileged user.

personally i prefer not to use OO code in php if I can help it, it really is kind of strange compared to other languages.

this thread is making me want to learn a compiled language for some reason.

remember the "globals" issue in php? That wasn't even a language problem, that was a default configuration problem that created a pretty nasty hole IIRC.

I kind of have to agree with @voo42 here. Syntax dialects aside, its really not the language that's the problem. Its how its used. Prepared statements can resolve a lot of problems, and a lot more can be resolved by taking a good look at the input before using it and making sure your configuration is solid. PHP has a lot of good to offer and can be safely used as long as you are aware of its flaws.

I think what's missing in a lot of cases is a good understanding of the underlying and companion systems, such as how the web server works, how the database works, and how permissions affect things, etc. No language can save you if you plop GET/POST vars directly in your statements and connect to your database as a very privileged user.

personally i prefer not to use OO code in php if I can help it, it really is kind of strange compared to other languages.

this thread is making me want to learn a compiled language for some reason.

Well the whole globals thing (I don't think anyone still remembered that) just goes to show how not security minded the language developers are. It's a problem to the core of the the PHP community. Yes, they are learning to get better, but the track record is far from stunning.

If you want to learn to do websites in a compiled language that is quite awesome, I'd suggest C++ because for local apps you can use Qt and for web apps you can use Wt. They are even similar in mentality. It is often difficult to think about a website in a OOP way, but Wt pulls it off. Wt's feature set out of the box is impressive. The only downside is it takes a bit of coding to get a site started, but they are working on a project template generator that will create an empty site skeleton that you just fill out. The really nice thing about Qt is it abstracts all that HTML/JS from you. If you want an input text box, rather than have your code include <input type=text...> in it, you just say WLineEdit(). The underlying library will then express it as needed. Then for handling interactions on the client, it generates Javascript for you... and the best part is it is all native code on the server.

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.

Yeah but that's the point: Those are 3rd party ORM frameworks (which I absolutely agree is a much more sensible approach than using low level JDBC driver and co anyhow) which don't really have much to do with the language. PHP does have libraries for prepared statements (also escaping HTML for XSS attacks) and a quick google search brings up an ORM for it too.

Scorp1us wrote:

There is something to be said for the mentality and the culture. And that is what I am criticizing. The culture of 'leave ?> off'

Since I really don't program in PHP, I can't say anything about the culture, but good frameworks can make a world of a difference, since those can guide users in the right direction to let them avoid the pitfalls. But that doesn't mean that the language is bad or anything, only that - maybe - a larger fraction of beginners are using the language. And if you look around, PHP is still almost everywhere on cheap hosts, etc. so that's no big surprise (on the other hand try to find something for django)

Also Java has by all means a gigantic ecosystem with several different frameworks, had one of the first major known ORMs, etc., etc. but I'd take any bet that you'll still find lots of software that is vulnerable to SQL injections.

One can only hope that the ongoing publicity about SQL injections will get users to educate themselves at least a bit. Next up on the list then: XSS attacks. Both of these errors are so easily fixed in any language with the right frameworks (and I'm sure they exist!), it's just a question of getting people to actually use them.

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.

...

Ending PHP files in ?> is a sign of an "unskilled PHP developer"? Hahaha OK.

Because PHP is a horrible language, created by people who are not aware of what they are doing. Making \ the namespace separator? Please.

Its array of standard functions, and their lack of standardised syntax and whatnot is a clear sign of this.

The whole <?php ... ?> was created initially, because it was the intent that PHP should be included amongst HTML. But eventually, PHP grew into a huge system, that usually meant people stopped including PHP in raw HTML, and rather built strings to output it.

But some editors would leave newlines at the end of files (because this is a standard mechanism in some languages), which resulted in problems when including, for instance, a configuration file, that suddenly added unneeded whitespace to the website. The solution was realising that they had made a mistake of their strict <?php ... ?> requirement, and decided to allow people not to use ?> at the end.

Using the argument that PHP itself suggests you do <?php ... ?> is not really a good argument for it, because most of the arguments that PHP makes for itself are dumb.

Leaving the ?> at the end of files introduces so many more problems than removing it does (which, as far as I know, introduces no problems).

Doesn't this just have one or both of two possible outcomes:1) Dirt Jumper gets an update after public popularization of its vulnerabilities (rendering this info useless)2) Dirt Jumper's market price declines as a stronger, more secure competitor's price rises.

I'm curious if this information provides a means to turn the DoS back on it's originator--that is, get infected machines to think the originator is the *target*, causing our little script kiddie to DoS *themselves*.