This post is a complete switch over from my previous post on phishing modus operandi. A little background on the hack. I was doing an assessment of a financial application; the objective was to evaluate the security of the complete infrastructure on which the application will be hosted once it goes live. As oppose to the routine list of findings this particular hack took the limelight. It was system compromise with Administrator access to the system. Yeah!
It was last day of our assessment; I had little time on hand before I could wind up for the day. So I thought why not bash the ‘sa’ account. I open the Microsoft SQL Server 2005 Management Studio and try some brute forcing for ‘sa’ account with common passwords, I get errors and disappointments. But this was short lived, it dint take me more than 7 tries to get the combination right. And that opens my way into the system.
Once I was inside, the next step was to use the stored procedure xp_cmdshell. The “xp_cmdshell” extended stored procedure runs operating system commands from within the database engine. You can use the query analyzer or T-SQL code to run the command. Back to the hack, I than open the query analyzer and type the following command
exec xp_cmdshell ‘dir C:’
Though I was logged in ‘sa’ account (the highest privilege account in SQL server), as expected I get this long error message.
Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1
SQL Server blocked access to procedure ‘sys.xp_cmdshell’ of component ‘xp_cmdshell’ because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of ‘xp_cmdshell’ by using sp_configure. For more information about enabling ‘xp_cmdshell’, see “Surface Area Configuration” in SQL Server Books Online
In short the error means, I cannot use the xp_cmdshell stored procedure to do my hack. Microsoft (MS) has turned this stored procedure OFF in the version above SQL 2000 as a part of the security configuration. The previous versions of SQL Server 2005 had full access to xp_cmdshell turned ON in the default setup. And hence it was easy to do the system compromise. One obvious advantage of disabling the xp_cmdshell is, once a hacker gets access to the SQL server, the system compromise would not become a cake walk. But let’s check out how you can still do cake walk on version above Microsoft SQL Server 2000. Just a little tricky but easy 😉
If you read the error carefully it gives out a lot more than it should. Check the last line of the error message. It says xp_cmdshell can be enabled using the “Surface Area Configuration”. I further Google and get plenty of articles that tell me how to use Surface Area Configuration wizard to enable the stored procedure. They would ideally work but it dint work for me for whatever reason. If you want to enable xp_cmdshell with Surface Area Configuration method on your own system, try the following
Goto Microsoft SQL Server 2005
Configuration Tools > SQL Server Surface Area Configuration > Surface Area Configuration for Feature > Expand the SQL server Instance name > Under Database engine goto xp_cmdshell > Check “Enable xp_cmdshell” and Apply
That’s it, you can have now enabled xp_cmdshell for your own box. You can again run the command mentioned above. You should not get any error now. The image below summarizes this
Fig: Enabling xp_cmdshell using the Surface Area Configuration Wizard
I had to enable xp_cmdshell on the remote system. I open my SQL Server Surface Area Configuration wizard and click on “Change computer” and specify the remote system SQL server instance name (or IP). It popped me with some error. I tried a few time but phew! It does not work for me. It was time, I try something else. I go back and start to find if there was some a command line to do the same thing. Again a few searches and I get my results. You can enable the xp_cmdshell in 4 simple steps.
1) EXEC master.dbo.sp_configure ‘show advanced options’, 1 (ONE means ON, ZERO means OFF)
2) RECONFIGURE
3) EXEC master.dbo.sp_configure ‘xp_cmdshell’, 1
4) RECONFIGURE
sp_configure displays or changes global configuration settings for the current server. And the ‘sa’ account has privileges on this stored procedure. Eh! sp_configure is my key inside the system. So I first enable all the advance options than enable the xp_cmdshell. The image below shows my ‘xp_cmdshell’ in action on the remote system.
Fig: xp_cmdshell in action on victim system
Once I enabled xp_cmdshell, it was time for me to add user. So I type the following commands at the query analyzer console,
1) EXEC xp_cmdshell ‘net user pwnsauc3 h3ll0w0rld$ /ADD’
2) EXEC xp_cmdshell ‘net group Administrators pwnsauc3 /ADD’
In case the remote terminal service is not ON, goto to Start > Run and type service.msc. Right click on the parent node and connect to remote services and use the above username and password. Start the Terminal Services. You can now sit and relax; you are a step away from administrator access to the system. Fire up your remote terminal client and type in the IP and login with the user name and password we created. The images below conclude my hack.
Fig: Verify the user addition from command line
Fig: Remote terminal to the victim system
Fig: Verifying the user added to Administrators group
Adios!
Taufiq Ali
