Webapp Asssessments Rule or 'why running as 'dbo' is bad!

I just finished up a web application assessment for a client as part of an audit. All I can say is that I've not had that much fun on a web app pentest in ages!

All I was provided with was an ip address. Total blackbox testing. This usually sucks because if you can't get by the login screen, telling the client that, well, the design sucks does not go down well. I like to bring at least a little value.

I had a quick look at the login page and bamn! Full admin access. Yep, 'or 1=1-- lives on. No encoding or filters to bypass at all. As usual the first user in the database was Admin too. After adding another admin user and browsing through the site it was time to see what the database contained. Turns out all the error pages were generic pages as detailed error messages had been disabled. Blind SQLi on .aspx pages sucks. I though this was going to go from quick pwnage to a long ordeal to get the data. Enter Pragmatk. Prag is a friend of mine that just rocks at webapp stuff. We sat down and after visting all the pages and forms that accepted user input we actually found one that returned database error messages. W00t! Let the games begin!

In short order we had everything from the database. Users, passwords, clients, contracts and more. I was able to use the email addresses and passwords we found to log into the user's email account via Outlook Web Access. Perfect. Being greedy we wanted to get access to the server itself. We could create temporary tables and write data to them from any file on the server but this was not enough though. Local admin or fail! Turns out that RDP over 3389 was enabled! Don't ask because I have no idea why. So after trying some of the users and passwords and not getting anywhere I decided to see who the database was running as.

'; if user ='dbo' waitfor delay '0:0:5 '--

Hell yes! Running as Admin. I should have expected it after what we had already found. So next step was to see what I could leverage with this knowledge. In SQL2005 xp_cmdshell is disabled by default but if you have admin access it's really trivial to reenable this stored proceedure. [insert evil grin here]. Using sp_configure it took a few SQL queries to enable xp_cmdshell. A quick test to see if it succeeded.

exec master..xp_cmdshell 'ipconfig > test.txt';CREATE TABLE zeroday (txt varchar(8000)); BULK INSERT zeroday FROM 'C:\\windows\\system32\\test.txt'--

A quick read of the table and w00t!, our ipconfig data was there. Sweet. At this point I'd had too much coffee and started to overthink the next steps. I started going all old skool and writing to a ftp.txt file to pull down my backdoor.exe and execute it. Well at least I did not decide to go the debug.exe route. :) Halfway through I'm talking to Eric over the phone when he 'politely' reminds me that I have RDP access. Just add a user to local admin group and you're golden.

exec master..xp_cmdshell 'NET USER zeroday xxxxxxxx /add'--
exec master..xp_cmdshell 'NET LOCALGROUP "Administrators""zeroday"/add'--

Let's try RDP. It's such a good feeling to see that server's desktop appear! At this point I grabbed the password hashes from the server (not that I'm going to bother cracking them), uploaded my scanner, scanned the two subnets I had access to, got some screenshots and...wtf! DO NOT! I repeat DO NOT run your exchange server on the same server as your webserver!

To finish up Pragmatk took a few minutes to find a persistant XSS in the site (there's more than one). He modified the username field to contain the XSS. If we really wanted we could have modifed each users profile to contain the XSS instead of only our test user. An invisible iframe and I'd have my backdoor dropped to their system in a heartbeat.

All in all a lot of fun was had all round. Cheers to Eric and Pragmatk who rocked as always.

Cheers,
/dean