Inside the swarm

Hacking was once the pursuit of isolated hobbyists who handcrafted viruses to cause the most destruction and gain the most recognition from their maladjusted peers. More recently, though, the dark side of computing has commercialised, spawning a lucrative black market where money is the sole objective.

Today, malware is packaged with end-user licence agreements and warranties, and hacking tools come with support contracts. Cybercriminals trade credit card numbers on eBay-like forums and spammer affiliate programmes hold conventions. Botnets – vast networks of compromised devices controlled from afar, often without their owners noticing – can be rented by the hour at a scale that dwarfs cloud-computing services such as Amazon Web Services.

In short, cybercrime is thriving. And like any successful business, it is beginning to industrialise.

In July 2008, the controllers of a botnet named Asprox switched its payload from sending out phishing emails to conducting millions of SQL injection attacks, a fairly simple method of controlling a database through a website.

The botnet began scanning Google’s search engine for websites with SQL vulnerabilities and automatically launched attacks against those sites. The aim of the attacks was to insert an iFrame redirect – an automatic instruction to the user’s browser to visit a particular site – that would infect the site’s visitors with a Trojan. Once installed, the Trojan would advertise fake antivirus software to the victim and recruit their computer to the botnet.

The potent combination of an automated attack and its delivery on a mass scale proved spectacularly successful: in the first two weeks of July 2008 alone, Asprox compromised more than 1,000 sites, including those belonging to the Queensland government in Australia, soft drink maker Snapple, BMW Mexico and the City of San Francisco.

But Asprox’s reign of terror has not been an isolated event. Research published in September 2009 by security firm Websense found that 61 of the Internet’s top 100 most visited sites were either hosting malicious content or contained a masked redirect to a malicious website. This represented a 700% growth in malicious sites compared with the statistics of the previous year.

Most of these breaches were the result of three large-scale SQL injection campaigns, named ‘Gumblar’, ‘Beladen’ and ‘Nine Ball’, coordinated by botnets.

“It’s really the industrialisation of hacking,” says Amichai Shulman, CTO of security firm Imperva, which specialises in web application firewalls and database monitoring tools.

“What they are doing is automating the entire hacking process by gathering candidates for SQL injections, by launching [a standardised] attack and waiting to see where it succeeds,” he explains. “Once they go through the first wave, they change it and then resend it to everybody, trying to get even more victims. There are multiple waves of attacks.”

What this means is that attacks are no longer the preserve of sites or companies that happen to have attracted the attention of a hacker: smaller sites are just as vulnerable as larger sites, and experiencing an attack is only a matter of time.

“I think the most important lesson for web application owners is that you don’t need to be a high-profile application in order to be on the target list of hackers,” says Shulman. “As long as you are on Google and [the botnet’s] search matches you, you’ll be attacked.”

Old attack, new rules

The goal of a SQL injection attack is to send commands to a database sitting behind a web application, usually through some kind of data entry field. A vulnerable database can be made to send its contents or even lists of user passwords to email addresses designated by cybercriminals, potentially giving them a lever into the rest of the organisation.

The recent malicious attack on The Guardian’s job site, in which the CVs of 500,000 people were stolen from a database server run by a third-party provider, had all the hallmarks of an SQL injection attack, according to Shulman, despite the company describing it as “a sophisticated and deliberate hack”.

In fact, by cross-referencing an archive of news items about security breaches with technical details of incidents, Shulman claims that whenever an organisation describes an attack against it as ‘sophisticated’, “it is not an advanced network hack or something, but most often a SQL injection”.

SQL injection attacks were also used by hacker Albert Gonzalez and his Russian accomplices to steal a staggering 130 million credit card numbers from Heartland, Hannaford Brothers, 7-Eleven and several other US retailers – the largest such fraud in history.

“SQL injection attacks are regarded as sophisticated because in theory you have to understand about web applications, database servers and connection between them to be able to launch a SQL injection attack,” says Shulman. “But in reality all you have to be able to do is download software from the Internet.”

The principal reason for the popularity of SQL injections is that few hackers need to resort to more complex attacks, as SQL vulnerabilities are so widespread. Chris Wysopal, CTO of application security firm Veracode, estimates that “half the web applications we analyse have a SQL vulnerability. It’s definitely the number one way to modify the content of a website, and you can do it on a mass scale by really automating it.”

As in the case of the Asprox botnet, that modification extends to including malicious code designed to infect users who visit the site, usually a pixel-sized iFrame that drags in malicious content from a site controlled by the attacker.

“This gives an attacker the flexibility to change the attack over time, and take advantage of a different vulnerability,” Wysopal explains. “The downside is that it’s kind of suspicious that the iFrame is pointing to another website, and it can be stopped by browser plug-ins like NoScript. So sometimes [the attacker] will just embed malicious content in the iFrame instead of pulling it from another site.”

Simple defences

Defending against SQL injections can be as simple as restricting web fields from accepting characters inappropriate to the context: a ‘name’ field should not accept quotation marks or brackets, for instance. Unfortunately, many web applications are programmed from the perspective that such fields will only ever receive trusted information.

“I don’t characterise it as laziness as much as ignorance,” says Wysopal. “I don’t think a lot of developers know how serious a vulnerability it is, and there will always be a more junior developer on the team. This is why there needs to be some sort of security testing before the code is shipped, because once it is released automated botnets can find it quickly.”

Conventional safeguards offer little protection: Heartland still managed to lose 100 million credit card details despite having firewalls in place and being PCI compliant (this was later stripped by Visa).

Instead, companies seeking to mitigate the problem must resort to trawling through their code manually, much of which may be old or written by developers since departed from the firm.

“I could say that mitigation within the code is very simple,” says Shulman.

“There is an API for database access called ‘prepared statements’. If you correctly use prepared statements then your application will not be vulnerable. But in practice a lot of things go wrong.

“You could have a junior programmer not familiar with the API,” he explains. “You could have a bad programmer who is familiar with the API but is using it in the wrong way. And some of your code was probably written before you became aware of prepared statements.

“You can’t rely on your code being secure. Even if you get to the point where you know where the vulnerability is and the fix is simple, it still has to go through quality assessment and be deployed during a specific downtime window. The entire fixing cycle takes time.”

Shulman, naturally, advocates web application firewalls. Ordinary firewalls are ill-suited to the purpose because SQL injection attacks appear as legitimate traffic. However, more specialist appliances or software can fend them off by inspecting traffic and ensuring the database is accessed according to the natural flow of the website.

It’s a compelling quick fix, and the increasing complexity of web applications and the rising number of attacks against them is probably partially responsible for Imperva’s 88% revenue growth in the European market in its last quarter. But this kind of protection can be beyond the reach of smaller companies, who are just as at risk as large corporates.

“The places that have not done well with this are small businesses,” says Wysopal. “Maybe the data is low-risk, maybe it’s just a blog, but the fact is that if the site can be compromised, that risk is not seen by the business that owns the website, but the customers using it. That’s the area where we really see no care being taken.”

Botnet results

So while SQL injections are at heart a simple threat to address, in practice they can be more troubling than first thought. And now the threat posed by SQL injections is being amplified exponentially by their use in conjunction with botnets.

Botnets are a cybercriminal tool with a power that is unparalleled in the world of legitimate computing. In 2007, researchers estimated that the processing power of the botnet created by the Storm worm, a Trojan delivered as a simple email attachment, “blew the combined compute power of the world’s top 500 supercomputers out of the water”.

“Everybody is talking about cloud computing at the moment,” says Yuval Ben-Itzhak, CTO of Finjan Software, a security firm with particular expertise in monitoring botnets. “Botnets are the largest cloud computing resource in the world – the number of compromised computers is unbelievable.”

The number and size of these rogue networks are growing. Earlier this year, Finjan reported that it had discovered a single botnet controller with 1.9 million compromised computers under its command.

“At any given moment, we’re tracking 500 to 800 botnets, with an average size of 100,000 machines. You can multiply that to get a general idea of the computing resources available to these people,” says Ben-Itzhak.

The relationship between SQL injections and botnets is a symbiotic one. Increasingly, botnets are being used to trigger SQL injections that in turn spread the malware that recruits more devices into the botnet.

This is the process by which botnets grow to their impressive size, but typically it is not an end unto itself. More lucrative uses for a botnet – once it has reached a critical mass – include distributing spam or phishing emails. Botnets can also be used to execute distributed denial of service (DDoS) attacks, the threat of which can be used to extort money from businesses.

Thanks to the size of many botnets currently in operation, the threat of a DDoS attack is now a grave one. “No company could stand a DDoS attack from 100,000 users,” says Ben-Itzhak.

And the stakes are perilously high, he adds. “My concern is that one day they’ll decide to interfere with the stock exchange website or servers providing data to the stock exchange, which would cause severe damage to the entire world,” says Ben-Itzhak. “You don’t need to fly a Boeing into a building in New York when you can run a DDoS attack against key servers and get a similar effect.”

The reason this hasn’t happened, he suggests, is that “what motivates these people is mostly financial gain. [Cybercriminals] are not doing it for fun or as a proof-of-concept; they want to get something out of it.”

How SQL injections work

Joxean Koret, Malware researcher at Panda Security, explains how attackers conduct a SQL injection

“The first thing you look for is the domain of the company you want to target, which is not hard to find. Then you take a look at the scripts [the site] is using and the parameters the scripts are accepting, by sending some special characters [to the field or web application].

Usually the site expects to receive only A-Z characters (a name, for instance), and in most cases assumes only normal data will be entered. When you enter special characters (such as brackets), you wait to get some kind of error, and check to see if it is from the web itself or from the database [behind the app]. If the error is from the database, then you have a door open to make an SQL injection.

The error will let you know which database the site is using, which version, and even what operating system it’s running. You can then use that data to send an SQL command internally.

The most basic goal is to gain access to the data. But you can take control of the whole database and the computers that belong to it. You can do whatever you want, and you don’t need to have advanced hacking skills. It’s a very typical flaw, and if you don’t filter that incoming data you will meet this problem.”

In this case, the vulnerability comes not from a product but from a process – and from lazy programmers.

Related Topics