How Mass SQL Injection Attacks Became an Epidemic

In the first few months of 2009, security researchers began seeing signs of a new piece of malware that was somewhat baffling to them. It didn’t act like other Trojans or rootkits and try to bury itself on an infected machine and try to do nasty stuff like deleting registry keys or copying the contents of the hard drive. Instead, this malware, which came to be called Gumblar, was about the business of stealing Web site credentials and compromising as many legitimate sites as possible, creating something entirely new: a botnet of infected Web servers that has highlighted the horrific state of Web application security and become the new model for Web-based malware.

In the first few months of 2009, security researchers began seeing signs of a new piece of malware that was somewhat baffling to them. It didn’t act like other Trojans or rootkits and try to bury itself on an infected machine and try to do nasty stuff like deleting registry keys or copying the contents of the hard drive. Instead, this malware, which came to be called Gumblar, was about the business of stealing Web site credentials and compromising as many legitimate sites as possible, creating something entirely new: a botnet of infected Web servers that has highlighted the horrific state of Web application security and become the new model for Web-based malware.

In the year and a half since Gumblar’s emergence, a slew of similar attacks have surfaced, using various techniques to compromise the weak Internet-facing applications that are running on tens of millions of sites around the world. Many of the attacks–which have compromised millions of legitimate sites, by some estimates–rely on simple, well-known techniques such as SQL injection to own a given site. That attack is just the beginning of a chain of events that includes attacking the PCs of visitors to the infected sites, stealing login credentials, online banking passwords and other valuable data and the using those pilfered goods to infect other sites and drain money from victims’ bank and credit card accounts.

This is a problem that goes well beyond the normal phishing attacks–although those are part and parcel of these campaigns as well–which are somewhat easy for most users to identify. The exploits involved in Gumblar and related mass attacks typically are drive-by downloads that happen in the background, with little or no indication to the user that anything is wrong. Add in the fact that these attacks are emanating from legitimate, trusted Web sites and you have a serious problem.

Mass compromises of legitimate sites really began in earnest in 2007, and the volume and severity of the attacks has increased significantly since then, developing into one of the more vexing and complex problems in security.

The Gumblar attack and other similar mass infections have helped kick over a big rock and revealed the squirming mass of nasty bugs that is crawling through many of the Web applications deployed today. And the problem of mass Web site compromises is likely to get much, much worse before it gets better, experts say, thanks to a number of factors that have combined to make owning the Web a simple, straightforward exercise.

“It’s a huge problem. Web app developers really don’t care about security unless it’s tied to their bottom line, and it’s not,” said Jeremiah Grossman, CTO of application security firm WhiteHat Security. “Developers who know how to write code securely don’t get new jobs because of that skill. They do what they know how to do. They’re taking libraries from all kinds of different places, code is outsourced, it’s written in-house, it’s revamped. It really does sound like the desktop world 15 years ago.”

As the number and variety of Web applications has exploded over the last few years, more and more developers find themselves needing to add functionality to an older application to make it accessible from the Web. And, as Grossman points out, very few Web developers have had any kind of training on writing secure code or deploying Web applications safely, so they end up worrying mainly about functionality and performance, with security an afterthought at best.

So the end result is millions of Web applications with simple, easy-to-exploit vulnerabilities that have become a virtual shooting gallery for attackers.

As researchers began to look more deeply at the Gumblar attack in April and May of 2009, they found that the malware was a multi-stage exploit kit that was succeeding in large part due to an old technology: FTP. Gumblar’s initial infection method involved using stolen credentials to access an FTP server on a given site. Once the attacker has access to the site, he then places a script in as many JavaScript and PHP files as possible, ensuring the largest potential minefield for visitors to the now-compromised site.

As visitors arrive at the infect site, the Gumblar malware starts throwing a series of exploits at their browsers, including exploits targeted at Adobe PDF and Flash vulnerabilities. If one of them is successful, the Gumblar Trojan then installs itself on the victim’s PC and begins monitoring Web traffic, looking for FTP credentials and other valuable data and the infection cycle begins again.

To get an idea of the scope of the problem of mass Web site compromises, consider that Gumblar first was identified in March 2009, and in May 2010 it was still the second most-prevalent piece of Web malware, according to Cisco’s ScanSafe unit. And Gumblar is just one of perhaps dozens of similar attacks ongoing at the moment, many of which never make headlines or attract widespread attention from researchers. At any given time, there are likely millions of individual legitimate Web pages that are compromised and serving exploit to their visitors.

A more recent attack has shown that the attackers are not standing still, and are continuing to modify their techniques to infect the maximum number of sites and PCs. In early June, researchers identified thousands of Web pages that had been infected, seemingly within a handful of days, with a piece of malware that was coming from a domain at Robint.us. The attack involved a malicious iFrame that was injected on to sites that were running vulnerable versions of Microsoft IIS and ASP.net applications. The campaign used a SQL injection attack to inject the malicious code onto the sites, a distressingly common vulnerability in Web applications that has become the go-to vector for these kinds of attacks.

SQL injection is an incredibly common and very well-known attack technique, and yet it continues to work. That fact is down to the difficulty of eradicating every SQL injection flaw in Web applications, assuming that site owners actually are testing those apps, which is not a given.

“Testing is great if you’re hiring the top-level talent. People that are testing apps don’t know enough about those apps to test it. You have to know what it does, what the business processes are, where it goes and why,” said Rafal Los, a senior Web security specialist at HP. “Apps, once they go live, are forgotten. People write junk and that junk gets recycled, and it’s all going to the Web.”

[block:block=47]

A big part of the problem is its scale. The sheer volume of vulnerable Web applications makes the attackers’ job far too simple. If an attack doesn’t work on one page, the attacker can simply move on to another page on that site or a sub-domain or an entirely different site. It just doesn’t matter. Also, many organizations don’t have a good handle on the size and topography of their Web presence, so there is an unknowable number of forgotten sites online just waiting to be owned, experts say.

“A lot of times the sites that are getting owned are sites that the companies don’t even know they have,” Grossman said. “But those second and third-tier sites are just as valuable. I don’t know what the answer is. Let’s say people are doing software security the right way. Even if we’re doing it the right way, it would take a significant amount of time to fix. It took us 15 years to build the Web crappy the first time around, so it could take us another 15 years to fix this.”

Suggested articles

Adobe Accelerates Patch Schedule for Critical Flash Bug

Adobe has moved up the release date for the patch for the critical bug in Adobe Flash Player revealed last week, and now plans to have a fix ready on Thursday. The company still plans to patch Reader two weeks from now.

EU Agency Says Stuxnet Portends Future Sophisticated Attacks

The European agency responsible for protecting the critical infrastructure of EU countries is warning its member states that the Stuxnet attack represents a major change in the malware landscape and that they should be prepared for further attacks with the same level of sophistication and professionalism.