Several website owners this past week, including the United Nations and the UK Government, were left with a compromised database after being hit with the notorious SQL injection bug. This is a flaw in which a basic ASP webpage can run malicious script on a SQL server.
The mass attack hit a number of website that were ASP driven and supported querystring paramters for database lookup. Webpages can allow for dynamic retrieval of information based upon querystring parameters; however if programmed in a basic manner, it might allow for a malicious script to be run.
Here is a basic example of a page that is vulnerable:
Given our BadPage.asp example, consider what the following HTTP request would do:
In the mass attacks we've seen from China (IP=222.91.65.191) in the past week, the actual querystring script was encoded into hexadecimal so that it was interpreted by SQL, but not munged by ASP.
Here is the script as interpreted by SQL:
The outcome of this executing the SQL command would result in modifying all the text content in the entire database. The text content would direct your website users to download malware to their desktops.
Identifying Websites Vulnerable To SQL/ASP Bug
A basic query for ASP pages to Google can be performed to identify potential sites with the flaw.
Combine this script with a mass crawler to identify the querystring parameters, then hit the pages in mass coordination worldwide; pretty cleaver stuff indeed... The actual purpose of this latest infection from China was even more impressive as it ran a javascript to end-user coming to the website. That javascript contained several other fun forms of malware; which fortunately my browser decided to pass on...
There is no patch that prevents this flaw. A fully patched, secure and locked down server can be susceptible to this problem. It is only eliminated with good coding practices. I recommend exclusively using stored procedures to gain access to the database; in that way you tightly control all access levels and can avoid the pitfalls of rouge or poor programmers and basic exploits.
In short, don't allow uncontrolled, dynamic SQL statements to be run from the web application.
The mass attack hit a number of website that were ASP driven and supported querystring paramters for database lookup. Webpages can allow for dynamic retrieval of information based upon querystring parameters; however if programmed in a basic manner, it might allow for a malicious script to be run.
Here is a basic example of a page that is vulnerable:
Page: BadCode.asp
Dim myVar
myVar = Request("input")
...
objComm.CommandText = "Select * from myTable where ID=" & myVar
objRS.Open objComm.Execute
...
input is passed in as a malicious script, it could be run by the SQL server and run amok! Lets have a look...Example SQL ASP Malicious Script
Given our BadPage.asp example, consider what the following HTTP request would do:
http://samplesite/BadCode.asp?input=555;EXECUTE("MALICIOUS SCRIPT")In the mass attacks we've seen from China (IP=222.91.65.191) in the past week, the actual querystring script was encoded into hexadecimal so that it was interpreted by SQL, but not munged by ASP.
***REMOVED PER GOOGLE EDITORIAL GUIDELINES***Here is the script as interpreted by SQL:
***REMOVED PER GOOGLE EDITORIAL GUIDELINES***
The outcome of this executing the SQL command would result in modifying all the text content in the entire database. The text content would direct your website users to download malware to their desktops.
Identifying Websites Vulnerable To SQL/ASP Bug
A basic query for ASP pages to Google can be performed to identify potential sites with the flaw.Combine this script with a mass crawler to identify the querystring parameters, then hit the pages in mass coordination worldwide; pretty cleaver stuff indeed... The actual purpose of this latest infection from China was even more impressive as it ran a javascript to end-user coming to the website. That javascript contained several other fun forms of malware; which fortunately my browser decided to pass on...
SQL Injection Fix
There is no patch that prevents this flaw. A fully patched, secure and locked down server can be susceptible to this problem. It is only eliminated with good coding practices. I recommend exclusively using stored procedures to gain access to the database; in that way you tightly control all access levels and can avoid the pitfalls of rouge or poor programmers and basic exploits.
In short, don't allow uncontrolled, dynamic SQL statements to be run from the web application.
Comments
See the two sections in the article that now instead show: REMOVED PER GOOGLE EDITORIAL GUIDELINES
I suspect that the malacious SQL code is fingerprinted by Googlebot and thereby tagged the article, or that Editorial wanted to block the expose so as to prevent would-be hackers from learning a new trick.
My Blog was apparently marked for being in violation of TOS. I believe that this was a false-positive identification. I suspect that my recent publication "Dissection of the ASP SQL Injection Outbreak" triggered this.
Specifically, the article displayed some tracking code of what we experienced is displayed. I suspect that Google automatically associated the content with the known malware. My article was benign, text-only, and did not place any client-script or malware of any sort.
Nevertheless, to avoid the continued disruption, I am now modifying that article and removing traces that might associate it to an actual suspicious script.
I ask that you release the TOS suspension from my blog.
Google search screenshot
I'm sure that this is a basic finger-print identification since the article merely had text and not anything that would actually run on a users computer.
221.237.189.44; CN [China]
92.12.55.184; GB [United Kingdom]