Malicious SQL injection

We have blogged a few times recently about a fairly widespread and aggressive attack used to compromise web pages by inserting a malicious script tag (which loads a malicious script from a remote site) [1,2,3]. Aside from the usual plethora of “small site” victims, the attack has had notable success against several quite well known targets.

Last week, some interesting information was posted to the SANS Handlers Diary [4]. Whilst investigating some malicious files, the tool used by the attackers to identify and attack vulnerable web servers was found. The tool provides a simple interface in order to perform SQL injection attacks against sites identified via a Google query.

This morning, I was investigating another attack that is most likely related. The target of the malicious script tag has changed, but the underlying malicious SQL is very similar. The malicious injection can be seen below:

[Dump of the malicious SQL injection]

As you can see, the main guts of the malicious SQL (within @S) are obfuscated within the CAST(0x…) block (which is trimmed for clarity). Decryption is trivial, enabling us to identify how the attack works.

[Decrypted SQL]

In brief, the SQL will concatenate a malicious script tag into all (n)text and (n)varchar fields of all user tables in the MS SQL database. Nasty. Particularly for webmasters who have been hit, leaving them with a cumbersome cleanup process, and the challenge of preventing the same attack hitting them again.

And the purpose of the attack? Feeding the 1.js file into our automation system, we see a whole mass of pages that will get loaded as a result of browsing a compromised page. This is represented in the flowchart below (click to enlarge):

  • yellow blob: malicious 1.js file loaded from compromised pages
  • green arrows: page loads via an iframe (or similar)
  • red arrows: exploit payload, in this case resulting in the download of some Win32 malware

[Overview of attack]

Fortunately, we have proactive detection of several of the malicious scripts involved (Mal/Iframe-F, Mal/JSShell-B, Mal/Psyme-A), and the final payloads (Troj/Cabat-Gen and Mal/Packer). Additionally, the relevant URLs are now blacklisted strengthening the protection offered to WS1000 users. Detection for compromised pages has been added as Troj/Badsrc-B.

The bulk compromising of pages will continue to be a problem since it is such an effective way of exposing large numbers of users to malicious code. Whilst the attackers use tools to automate the attack process, victim webmasters are not only faced with the problem of clean up, but also identification and closure of the underlying vulnerability in order to prevent being re-compromised. Perhaps we can investigate some of the “SQL security best practices” in a future blog posting? Let us know if that would be of interest at