Anatomy of a SQL Injection Incident

A number of people are reporting that 10K+ websites have been hacked via a SQL injection attack that injected a link to a malicious .js file into text fields in their database.  For example, here’s Avert Labs report.

The reports that I’ve seen talk about how the .js file tries to compromise clients that connect to the defaced web servers; however, they don’t discuss the really interesting part.  How did the servers get hacked in the first place? 

Whenever I see a large number of hosts compromised in the same way, my initial assumption is that they all share a piece of vulnerable code.  If this was the case, I thought that it would be in everybody’s interest to figure out what that shared code was and take appropriate action.

Since the CSS Security team here at Microsoft worked with several of these incidents, I was able to look at multiple sets of data and the work that my colleagues had already done.  The first thing I noticed was that the attacks looked, with a few exceptions, identical.  They shared several things in common:

  • Two initial query strings that do some basic injection, apparently as a test.
  • One or more additional queries, specifically to do IS_SRVROLEMEMBER() happen in some cases.
  • Two final queries that DECLARE a variable that CASTs a large hex value into NVARCHAR and then EXEC()’s that string.  The string contains a script to append the link to the .js file onto every string-type column in every table in the database.
  • All of these happen within a very short period of time.  The only lag seems to be the time it takes the final two queries to execute.  (In the case with the largest database, the last query actually failed with a timeout.  I guess that’s not surprising since it’s essentially doing a find-and-replace on the entire database table.)

The last item makes me think that this is an automated process of some sort, particularly since the user-agent string for the last two queries is different from the user-agent string for the preceding ones.

This is where it gets interesting, though.  In comparing the pages that were compromised in different incidents, I realized that, while they’re all vulnerable to SQL injection, they don’t appear to share any common code. 

My next question, then, was how did the attacker select these sites?  Given that the whole attack took a very short period of time and the attacker only touched a single ASP page on the server, it was pretty clear that they had some reason to believe that page was vulnerable prior to connecting to the site.  It’s possible that they had previously scanned the site but I didn’t find any indication that this was true.

The other possibility that occurred to me was that the attacker was using a generalized approach to search Google for vulnerable sites.  As I was thinking this through, I found that I wasn’t the first person to have thought about it:

How Prevalent Are SQL Injection Vulnerabilities 

Guard Against SQL Injection Attacks 

SQL Injection Is Surprisingly Easy

So, there you have it — automated SQL injection attacks in a nutshell.  Next week, I’ll try to find some time to go into some of the details and brainstorm on how incident responders can get to the root of SQL injection attacks.

(I should note that many brilliant people on my team provided information and analysis into how the incidents happened.)

(Part 2 is here.)

Comments (15)

  1. Anonymous says:

    <p>This year SQL injection attacks are being stepped up and even automated against SQL Server. While SQL injection attacks can occur against any DBMS, my blog will only address SQL Server.</p …

  2. Anonymous says:

    It looks like another wave of the mass SQL injection I talked about last month is going on.  The

  3. Anonymous says:

    You’re quite right — this looks like another wave of the same attack.  I was aware of the earlier incidents but I hadn’t seen any data from them.

  4. Anonymous says:

    Blog Posting from Neil Carpenter: "A number of people are reporting that 10K+ Web sites have been hacked

  5. Anonymous says:

    There s a lot of noise arround currently ongoig SQL injection attacks and even if that is quite an "old"

  6. Anonymous says:

    Well, there was quite some chatter over the last few weeks with regards to the massive defacements we

  7. Anonymous says:

    Log Parser es una herramienta que permite analizar gran cantidad de datos de forma muy eficiente utilizando

  8. Anonymous says:

    My friend Neil has a pretty good post on the mass SQL injection stuff that was reported in the press

  9. Anonymous says:

    Pour mieux comprendre les risques auxquels sont exposées vos bases de données, il est intéressant

  10. Anonymous says:

    Hay muchos sitios y blogs que hablan sobre el tema de inyección SQL. Puede encontrar toda la información

  11. Anonymous says:

    Vielen von Ihnen ist es beretis bekannt, dass es seit einigen Monaten SQL injection Attacken gegen angreifbare

  12. Anonymous says:

    My colleague Greg , who has forgotten more about command line scripting than I will ever know, put together

  13. anonymous says:

    This seems to repeat what the Internet Storm Center wrote on Januari 9th, and they linked it back to November 2007.

  14. eponymous says:

    isn’t this the same or similar attack vector to the RIAA hack a few months ago

  15. Michael Doe says:

    Hi Neil,

    I work as System Engineer in a large ISP company and we are hosting a large number of legacy ASP applications which contain SQL Injection flaws. I have been using this tool when clients agree:

    So far the results have been very good and I have not had problems (except that I cannot install in 64 bit). Do you know something about this tool? Is there a way to make it work in 64 bit?


    P.S.: I am not using my real name to avoid problem with my clients.