SQL injection reinvented in 2008
In 2008 a very clever type of SQL injection attack defaced many thousands of websites with malware that potentially had the capability to infect the computers of those who visited infected websites. It was christened ASProx.
SQL injection is an old and known threat, it involves inputting SQL into a form field, or passing it as part of a querystring, with the aim of modifying the SQL statement itself. Whereas normally the input would form part of the criteria in the executed statement, an SQL injection attack changes the nature of the SQL statement itself which is executed in the website script. Not a good thing!
Historically such attacks have been relatively easy to prevent. Good validation of input on the client and server allows the syntax required to create such an attack to be intercepted, thereby rendering it harmless. Any web designer worth their salt would have in place one or more routines that checked submitted input, before allowing it to become part of the SQL executed in their application, so it was a manageable threat.
Then came ASProx, a new form on injection attack to which ASP scripts and MS SQL Server where particularly vulnerable; it could bypass established validation routines and “appear” to be valid input, but once executed as part of your SQL script, could do pretty much what it wanted with your database, and usually your web pages built from data in your database.
A couple of things set this apart from traditional injection attacks.
- It was automated. The attack was delivered by a Bot, it searched for potentially vulnerable ASP pages, and would run until the payload (malicious code) was detected on the webpages. The Bot would then move on to the next website. The big deal here is that the Bot would come back, day after day, so even if you cleaned your database up, without implementing some further protection in your script your database would be compromised again and again and again.
- The attacks used Fast Fluxing, which basically means the source of the attack is difficult to identify as the Bot uses the infected PCs as proxies.
- The syntax of of the injection attack was unusual. It was encoded, so that quite a long SQL script could be passed in the querystring, but the usual injection checks could miss it.
I wrote a basic function that will test for the existence of a couple of ASProx signature traits - it’s ideal to wrap around your database connection code/include as if ASProx can’t connect it cannot do any damage!
I’ve provided the syntax below as I noticed some people are charging for similar help!!!!!!!!!!!!!!!!!
Function noASProx(thequerystring)
” Querystring injection check for ASPROX
strquery=thequerystring
strquery = Replace(URLDecode(strquery), ” “, “”)
If Not InStr(UCase(strquery),”EXEC(”) > 0 OR Len(strquery) > 500 Then
noASProx=1 ” clean string
Else
noASProx=0 ” infected string
End If
End Function
The full querystring needs to be passed to this function using the request.servervariables (”querystring”) code. If True/1 is returned allow access to your database connection code/include, if it’s not don’t!
If you’ve already been hit by ASProx, put the above in place. Then I’d recommend connecting to your SQL Server Database using an MS Access Project. In doing so, you can, without needing to write a complicated stored procedure, perform a “find and replace” on each table in your database. Obviously you find the malicious payload code which (normally) starts with <script> and ends with </script>, and you replace with nothing - thereby deleting it.
The people behind ASProx are clever - they found a weakness, they exploited it. I don’t condone it, but I often marvel at why people with intellect like these guys obviously have, choose to use it in this way. I wish I had their talent. Legitimately applied to what I do - I’d be a millionaire!
