Stealing the Keys to the Kingdom through SQL injection

Stealing the Keys to the Kingdom through SQL injection

Recently I was conducting a penetration test for a very large high profile client. The last thing I was expecting to find was SQL Injection . The network itself had over 5500+ nodes and nearly 400 subnets.  I started out using one of my new tactics by utilizing Nmap’s new http-screenshot.nse script. If you haven’t had a chance to check it out; I highly suggest you do, its the new hotness. The NSE script essentially allows you to scan a network with nmap and take a screenshot of every webpage at the same time. Tutorials on how to use the script can be found on Pentest Geek here, or on Trustwave’s site here.

SQL Injection – Initial Identification

Normally when looking over all of the webpage screenshots I’m typically conscious of items like Apache tomcat servers with default creds, Jboss servers that expose the jmx-console, printers that have internal document servers holding confidential data, etc, etc…

When scrolling through these specific screenshots, this is the webpage that really caught my attention:

I had never seen it before, and all it offered was a login form for a username and password. This application definitely appeared to be custom made, and we all know custom made applications are put on a budget to complete. Projects on a budget often times are focused on functionality and not security. I wondered if the page was vulnerable to SQL Injection.

First thing I tried was a single quote (‘) in the username field, the typical SQL Injection test. I left the password field NULL to see what type of result would return.

Please enter a valid username and password to continue

Then I tried a single quote (‘) in the username field again and put some random text in the password field to get a 500 – Internal Server Error by IIS7. I was very excited at this point, because I had a hunch that SQL Injection was possible and that the single quote was breaking the backend SQL query.

SQL Injection – Troubleshooting Error Message

After the 500 response from the IIS, I attempted to use the following username and password combination:

Username:  ‘ or 1=1 –%20
Password:   password

This request responded with an error message from the application that stated:

Your account is not active. Please contact the Administrator

This error message helped assure me that the web application was vulnerable to an SQL injection authentication bypass vulnerability. In the back of my mind I was thinking either one of two things was happening. The request above was causing every single record in the table to return and the application only wanted a single record, or the first record had a disabled account. Often times when targeting SQL Injection the error messages don’t always tell us exactly what we need to know right away.

SQL Injection – Authentication Bypass

I pondered with a colleague and  discussed what would happen if we were able to manipulate how the database results were returned. What if we were able to sort the query by the 2nd, 3rd, or 4th column in the table? After some trial and error I tried the following SQL Injection request.

Username:  a’ or 1=1 ORDER BY 2 –%20

Password:   password

Low and behold this request was able exploit the SQL injection vulnerability and logged me into a password reset function. Sure I could reset a users password, and then log in as that user, but I wanted to be stealth and see what other cool stuff I could do with this vulnerability. The next request I sent was very similar to above, only I had the SQL Injection query sort the response by the 3rd column in the table.

Username:  a’ or 1=1 ORDER BY 3 –%20

Password:   password

Boom! This logged me into the web application and allowed me to query all sorts of confidential PII data. Now I could have sat back and been happy with my SQL Injection authentication bypass, but I wanted to see what else I could do with this vulnerability. That’s when I brought out sqlmap to see if it could provide me any additional assistance.

SQL Injection – Enter

./ -u –forms

At this point I was able to determine the Username and Password parameter was injectable according to sqlmap. This wasn’t really anything new since I already injected through the Username parameter for the authentication bypass to work. Now I wondered, what can I do with these injectable parameters? I fired off sqlmap again to see if it was possible to enumerate all of the databases:

./ -u –forms –dbs

sqlmap was able to enumerate that there were 11 databases running on this 2008 Microsoft SQL server via SQL Injection. Depending on permissions, I’m sure I could dump the entire contents of this database and find some more confidential PII data, but I wanted something cool like an shell on the OS where I could attempt to elevate privileges.

Since this was a Microsoft SQL server it might be possible to take advantage of the stored procedure xp_cmdshell which allows us to execute Windows native commands just like we were sitting at cmd.exe. The problem is that this feature is disabled in SQL 2008. I figured, you don’t know if it’s disabled unless you try.

 ./ -u –forms –os-pwn

SQL Injection – Conclusion

Not only was I able to determine that the web application was configured to run under the DBA account, but xp_cmdshell was already enabled for us, Great! Now sqlmap takes care of all the SQL Injection work and we’re able to get our handy dandy meterpreter that we all know and love.

From here it was too easy to take over the domain. Using incognito I was able to snarf a token of a Domain Admin that was recently logged in:

From here the network was mine through a simple SQL injection authentication bypass.

Share this article



  1. m0th3r August 31, 2012 5:08 pm 

    Nice…It is uncommon, but in reality you see the same thing on older 2003 boxes, not to mention other backends. Also, just running as service offers a ton of other possibilities. MS-SQL servers are notoriously(developers suck) not patched. I run into ms09-004 all the time, and with user level access you can escalate. Nice run dude…take’m were u can get’m! ;)

  2. m0th_man August 22, 2012 7:45 am 

    I have found that the harder I work, the luckier I get.
    Yes, Win2008 server should not have xp_cmdshell enabled, but login fields should be sanitizing input as well…

    I am no longer suprised to find such vulnerabilies or mis-configurations. People take short cuts all the time…


  3. Week 33 in Review – 2012 | Infosec Events August 20, 2012 2:01 am 

    [...] Ultimate Hacking Courses usually find these Windows tips useful, so we figured we would share them.Stealing the Keys to the Kingdom through SQL injection – Recently I was conducting a penetration test for a very large high profile [...]

  4. zeknox August 17, 2012 7:40 am 

    You are correct sir, very lucky. Just working with the hand that I was dealt.

  5. CG August 17, 2012 7:02 am 

    you got pretty damn lucky to have a 2008 server with the xp_cmdshell enabled and the app running as DBA

  6. BOB MCCANN August 16, 2012 9:23 pm 


Leave a comment

Your email address will not be published. Required fields are marked *