Manage Learn to apply best practices and optimize your operations.

New defenses for automated SQL injection attacks

By automating SQL injection attacks, hackers have found a way to expedite the process of finding and exploiting vulnerable websites. The old defense of testing and patching Web app code may not be enough to stop the threat. Michael Cobb explains how website owners have to step up --- and even change -- their game to prepare for the latest SQL injection exploits.

Recently, analysts at the SANS Institute's Internet Storm Center discovered a tool that automates the process of finding and exploiting websites vulnerable to SQL injections. The automation illustrates the increasingly popular technique of using parts of legitimate sites to host and deliver malware.

 What is new about this latest round of SQL injection attacks ... is both the degree to which the attacks are automated and the sheer scale at which they are carried out.
Michael Cobb

In this tip, let's take a look at SQL injection attacks and examine how to find, isolate and address the malicious pages of an otherwise safe website.

SQL injection attacks of the past
SQL injection attacks are nothing new. In a high-profile 2003 case, for example, apparel company Guess Inc. suffered a SQL injection attack on its website, which resulted in a security breach and a government-led legal settlement. At the time, court documents described SQL injection as occurring "when an attacker enters certain characters in the address (or URL) bar of a standard Web browser to direct the application to obtain information from the databases that support or connect to the website." In court, it had been found that attackers manipulated an application to gain access, in cleartext, to every table in the databases, including those that supplied purchasers' credit card information.

The liability that companies face if they expose sensitive data hasn't changed. What is new about this latest round of SQL injection attacks, however, is both the degree to which the attacks are automated and the sheer scale at which they are carried out.

The new SQL injection attack
From a technical perspective, today's SQL injection attackers are more thorough in how they seek out vulnerable websites. Various toolkits are being used to speed up the exploitation process. Consider the Asprox Trojan, which has been distributed far and wide by a spam botnet. Here is how the whole process works, according to Joe Stewart, senior security researcher with Atlanta-based SecureWorks Inc.:

  1. A Trojan is installed by spam (that is itself sent via compromised hosts).
  2. A PC infected by the Trojan downloads a binary that, when launched, uses Google to search for potentially vulnerable websites that use forms built with Microsoft Active Server Pages. The search results become a target list for SQL injection attacks.
  3. The Trojan launches a SQL injection attack against those sites, compromising a percentage of them.
  4. Visitors to compromised sites are fooled into downloading a piece of malicious JavaScript code from another site.
  5. That code directs the user to a third site, where more malware is hosted, such as copies of Asprox or Danmec (a password-stealing Trojan).

These steps indicate just how much has changed in five years. Previously, Web application developers were advised to test and patch their code on the slim chance that an SQL injection vulnerability might be uncovered and exploited maliciously. Recent attacks, however, have shown that vulnerabilities are now much more likely to be uncovered and exploited maliciously. Developers, therefore, should vigorously test their code prior to deployment and promptly patch it as soon as new flaws are reported.

Knowing when a website has been attacked
Certainly no enterprise wants to unknowingly spread malware. So how do you know if your site is compromised? Oddly enough, the answer might come in a notice from Google. In an excellent example of how hacking tools work both ways, Google, a major player in the project, monitors sites for "badware," defined as spyware, malware and deceptive adware. Indeed, Google automatically sends badware alerts to the following email addresses at domains where its Web crawlers locate a problem:

* abuse@
* admin@
* administrator@
* contact@
* info@
* postmaster@
* support@
* webmaster@

Of course, an enterprise must be prepared to receive these messages, something that sounds deceptively simple. There may be spam filters on these addresses, or worse, no designated recipient, meaning the messages may go unread. Cataloging and verifying contact details for all of corporate domains is a good first step in responding to this new wave of attacks. Savvy security pros might want to leverage news of these attacks to procure additional resources for a thorough site review.

The explosive growth in Web activity during the last five years has resulted in many "lost" sites, projects that were launched then later abandoned without proper termination. Unfortunately, the relentlessly thorough Google Web crawlers will find them, and if they are potential targets, they will eventually be attacked. Fortunately, though, an enterprise can proactively determine if it has a "badware" problem: any site can be checked for free using Google Webmaster Tools.

For more information 
Learn about a new SQL injection attack that threatens Oracle databases.

A reader asks our expert panel how to stop input validation attacks.

Those organizations that are uncomfortable relying on Google should embark on a detailed review of their websites. There are some tools that can help, starting with Xenu's Link Sleuth, a free program that can check all the links on a given site and report a variety of errors. Remember to test the production site and to run checks from a machine that is outside the company network; otherwise some problems may be missed.

How to prepare for the new attacks
Moving forward, a proactive strategy would be to invest in a Web vulnerability scanner such as those from Acunetix Ltd. and SPI Dynamics (now owned by Hewlett-Packard Co.). A good Web vulnerability scanner -- not to be confused with a network scanner -- will spot all currently known SQL-injection vulnerabilities on your site. An up-to-date scanner will spot new vulnerabilities as they become known.

Bear in mind that defending against SQL injection attacks may not be enough. Attackers are conducting concerted and automated searches for targets and executing of attacks on them. These techniques could well be applied to other Web infrastructure weaknesses besides SQL.

Finally, secure code review at all stages of the Web application development process and pre-production security testing are now more important than ever. They should be augmented by post-deployment testing that includes vulnerability scanning tools and site monitoring.

About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several Security Schools and, as a site expert, answers user questions on application security and platform security.

This was last published in June 2008

Dig Deeper on Application attacks (buffer overflows, cross-site scripting)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.