In 2008, worms were used to compromise Web servers and install malware that infected users of the affected websites. The worms used automated SQL injection attacks to modify the data in the database that would be displayed to users as part of a webpage. The modified data would be loaded into webpages, redirecting the user to another site hosting malware. In this tip, we'll look at ways to prevent these automated hacks.
The way that a payload is executed in the user's browser makes the attack similar to persistent cross-site scripting, an exploit in which a hacker places malicious code into a link that appears trustworthy. The difference is that the malicious executable injected during automated SQL injection attacks may be found in many different portions of the site, and not just in locations where the response includes previously supplied user input, as is the case with cross-site scripting. When a user browses to a page that includes the contaminated data, he or she will be redirected to a page that will download malware onto the local computer.
Automated SQL injection, with the help of search engines
These automated SQL injection worms utilize search engines to discover candidates for attack. By searching for strings associated with parameters for Web applications, the worms capitalize on search engines to acquire targets. The worms may search for specific page names such as "form.asp" or form parameter names such as "username." These identify Web forms and are commonly vulnerable to SQL injection. Search engines like Google also provide advanced search options such as "inurl:", "allinurl:" and "site:", which enable the worms' programmers to specify how to search for these parameters, such as in a search for "inurl:username=". The worms then launch SQL injection attacks to compromise the identified sites. By attacking Web servers that appear to access a database, the worms do not waste time attacking Web servers that don't have dynamic content. This allows them to spend less time randomly scanning for targets to exploit, allowing them to spread faster.
Fortunately, search engines such as Google have taken notice and are working to prevent these worms from finding victims. Repeated searches similar to the queries made by these worms are denied, limiting the worms' ability to find victim servers. However, relying on search engines to slow these worms down does not mitigate their ability to exploit your system once it is located.
How to detect SQL injection vulnerabilities
Routine application database audits should be used to determine if your application has been compromised. Querying the database for common HTML tags used by worms can reveal signs that the application is spreading malware. These tags include "iframe", "http-equiv="refresh"" or the IP address of known malicious servers. An easier way to detect a compromise is by examining webpages created from dynamic content for unexpected behavior, including the addition of hidden iframes -- code elements used to embed an HTTP document in another HTTP document -- in the HTML. These routine audits help detect a compromised system, but this method only allows for fixes to be created after the fact. Recovering an application from an exploited state, especially when data may have been altered, can be an extremely costly process and does not prevent future attacks.
These automated SQL injection worms use existing vulnerabilities in the application to force malicious payloads into the database. Eliminating SQL injection vulnerabilities in a Web application is the best approach to fighting these worms. Performing full application security audits can determine the presence of vulnerabilities in your systems. These penetration tests mimic an attacker by utilizing many of the same tools and techniques to identify weaknesses.
Various commercial and free automated tools, such as SQL Inject-Me, are able to detect the presence of SQL injection vulnerabilities in Web applications. Using tools such as these, developers and QA teams can detect and fix these holes before they are exploited by an attacker or worm.
About the authors:
Jamie Gamble and Patrick Szeto are senior consultants with Toronto-based Security Compass Inc., an information security consulting and training company specializing in secure software development.
This was first published in May 2009