Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have been browsing the web looking for some help regarding the following issue. I am currently performing an web application penetration test, and I had come accross a beautiful blind SQL Injection.

Using sqlmap, I am able to retrieve the whole database. I would like to jump into the OS level, by using the xp_cmdshell functionality, which is currently disabled on the database. The application is running with the "sa" account, so it should be technically possible. However, when I get the following message when I try to enable it using sql map :

[12:14:22] [INFO] checking if xp_cmdshell extended procedure is available, please wait..
xp_cmdshell extended procedure does not seem to be available. Do you want sqlmap to try to re-enable it? [Y/n] 
[12:14:23] [WARNING] xp_cmdshell re-enabling failed
[12:14:23] [INFO] creating xp_cmdshell with sp_OACreate
[12:14:23] [WARNING] xp_cmdshell creation failed, probably because sp_OACreate is disabled
[12:14:23] [CRITICAL] unable to proceed without xp_cmdshell

Some system information:

web server operating system: Windows 2012 
web application technology: ASP.NET 4.0.30319, ASP.NET, Microsoft IIS 8.0
back-end DBMS: Microsoft SQL Server 2008

Does anyone know how I can solve this?

share|improve this question
    
Are you sure it should be possible to enable xp_cmdshell by sa? Maybe there is some configuration that prevents sa from doing so. –  Gumbo Jun 23 '13 at 13:35
    
I am pretty sure it is possible to enable it, or even to recreate it if it has been removed, since "sa" is the most privileged account on an MS SQL database... On previous pentests, I was able to enable it using Metasploit (but I had the password associated with the account). –  AnonZed Jun 23 '13 at 17:27
add comment

2 Answers

I don't know the tools you're using. But to enable xp_cmdshell, do this: With

EXEC sp_configure

you can list all currently configured values. First, run

EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

to see all values. Then run

EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO

to enable it. I just tried this with my SQL 2008 server. Not sure if there's any further limitation on newer versions, but I'm not aware of any.

Also note that, if configured correctly, you run CMD commands with the SQL account, which is usually a restricted account and does not have admin rights on the machine. Actually it should only have access to the database folders and nothing else.

share|improve this answer
    
Thanks for your answer ! I am able to enable 'xp_cmdshell', however, I can't fetch command results though.. –  AnonZed Jun 24 '13 at 9:37
    
@AnonZed did http answer your question, then? Is the request for command results a separate issue? –  schroeder Jun 25 '13 at 21:14
add comment

You could try passing --priv-esc to sqlmap, and this may raise your privileges, but this has never worked for me. sqlmap's file system access functions could lead to a greater compromise.

SQLNinja is better at privilege escalation. One attack that it supports is simply brute forcing the SA password using SQL injection and I have found this to be quite effective. SQLNinja also contains other known privilege escalation exploits such as CVE-2010-0232.

share|improve this answer
    
Thanks for your answer ! I don't understand why should I be trying to "raise my privileges" on the DB, since I already have an access with the most privileged account... I will try SQLNinja, but I don't think brute forcing the SA password will be really effective : indeed, I managed to grab the password hash, and I have been trying to crack it for a while now ! Must be a strong password... Anyway thank you for your suggestion !! –  AnonZed Jun 23 '13 at 17:39
    
@AnonZed the sa account could be renamed... –  Rook Jun 23 '13 at 18:42
    
It could have been renamed, but it is not ("sa" username retrieved with associated hash using sqlmap... And confirmed by client ;) ) –  AnonZed Jun 23 '13 at 19:38
    
@AnonZed cool so that is 1 out of 1,000 possible exploits. You still have full db access, come up with a better one. –  Rook Jun 23 '13 at 19:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.