The month of May seems to be a time for many SQL injection attacks around the world. Unfortunately one of the sites affected by these attacks happens to be one that is administrated by a friend of mine. As it so happens the site was also developed by a friend and I’m sure we can have a good time reminding him to give SQL injections the respect it deserves for a long time to come.
Anyway, getting back to the attack, I was able to get a few logs to see what was happening first had. Here is a (modified) extract of the IIS logs that show what had happened:
This particular attack carried out from within China (WHOIS – 58.215.76.181) is pretty interesting, most of the SQL is obfuscated behind a very long hex string (CAST(0x HEX string)). I’ve removed the original string and replaced it with something harmless and much shorter in the above log entries.
The attacker has tried 2 slight variations of a SQL injection attack in the form of
1) /page.asp?pageID=2;SQLStatement;–
2) /page.asp?pageID=2′;SQLStatement;–
the attacker keeps trying the above 2 combinations on different pages of the website till he gets status 200 result; then leaves.
So what has the attacker done in his SQL statement? To figure this out we can fire up SQL Server Management Studio and pretty much use the same code that the attacker used except that we substitute the EXEC with a PRINT to view the query.
DECLARE @S NVARCHAR(4000);
SET @S = CAST(0xuseTheActualHexString AS NVARCHAR(4000))
PRINT(@S)
The attacker had queried all the all the user tables, found column names in each of these tables that are used to store string values such as text, nvarchar, or varchar etc. then it adds a <script> tag with a URL pointing to a malicious .js file into each of the column values. The SQL had also been “nice” not to replace the original values and only append to it, and also even properly deallocate and close cursors they used in their attack query!
The result of all that meant that all the websites configured to use that database will start to display its pages as shown in the following Google search result. Innocent visitors of the site would in some cases be executing that .js file in their browser which could cause all kinds of havoc depending on what is in the specified .js file.
Recovering from the attack is straight forward; use a clean backup of the database, or if you really wanted you could just remove the appended <script .. > portion from all the column data using the same script that was used to insert it.
But do we prevent this from happening again? well that’s another post. Just remember to give SQL injections the respect it deserves.