SQL sorcery

Since I last blogged about a recent spate of aggressive SQL injection attacks [1], we have seen continued activity, with sites across the globe being hit. Amongst the casualties are numerous well known brands. This lunchtime I decided to pull together some data on the sites we have seen hit in these attacks since late April.

Almost 75% of the affected sites are hosted in either the United States or United Kingdom. Australia, Spain and France come in next, with the remainder hosted fairly evenly across other countries.

[Distribution of countries hosting compromised sites]

As might be expected since the injection attack targets MS SQL, all the sites affected are hosted on IIS web servers, predominantly IIS 6.0. (Actually, according to the server response, one of the sites was running Apache, but this was likely spoofed.)

[Distribution of countries hosting compromised sites]

As discussed previously, when this SQL injection attack is successful a malicious <SCRIPT SRC=http://... tag is appended to various fields within the database. This has the effect of peppering the site with the tags (according to how the page content is built up from db data). In many cases, the tags are malformed:

[Malformed tags]

Of course, so long as at least one of the ‘implanted’ tags is parsed successfully by the browser, the malicious code will run.

We have seen an increase in the use of embedded <SCRIPT SRC=http://... tags recently (i.e. loading a script from a remote site). Of course, we still see lots of attacks using embedded iframes and complete scripts (where the entire script is added to the compromised page). There are subtle differences between how each can be handled in terms of detection, and the effect of each upon the potential victim.

1. Embedded iframe

The iframe tags normally contain attributes to make them less visible to the user. These suspicious characteristics can be used to assist detection.

2. Embedded script (page contains entire malicious script)

The presence of the entire malicious script makes it more likely the compromised page will be detected. If the page is not detected however, the attacker successfully exploits any trust relationship the user may have with the site. As an example, consider the use of a tool such as NoScript, to restrict script execution to just trusted domains. If a domain the user trusts is compromised, the embedded malicious script will also run.

3. Embedded <SCRIPT SRC tag (load script from remote site)

The implanted script tag will not contain any attributes to mark it as suspicious. In fact, most sites use very similar tags to load remote legitimate scripts (advertising, menu systems etc). Detection of the malicious tag requires inspection of the target URL (the remote server from where the script is loaded).

Unlike scenario 2 above, tools such as NoScript will protect the user even if they trust the compromised site. As you can see in the image below, NoScript requires separate authorization for the script loaded from the remote site, irrespective of whether the compromised site is already trusted.

[NoScript popup for compromised page]

There are two groups of victims in these attacks. Users who browse compromised pages and potentially get infected with malware, and also the site owners and administrators who can suffer severe downtime whilst they attempt to cleanup their databases and prevent being hit again. Sadly, given the success the attackers are enjoying, I think we can expect to see many more similar attacks in the near future.