Within Microsoft SQL Server databases, some fixed server-level roles are defined, providing a certain level of access and functionality. The role with the highest access and functionality is the SYSADMIN role. Only privileged users or administrators within the company are granted this role.
Eddy Van Heghe, one of our experienced Microsoft SQL DBA’s, discovered a small exploit however. Via this exploit every user can grant the SYSADMIN role (or other roles) to themselves when several specific criteria are met:
- The TRUSTWORTHY database option should be ON. This option indicates whether the Microsoft SQL instances trusts the database and its content or not.
- The database owner has server role SYSADMIN or SERVERADMIN or SECURITYADMIN granted.
- The user who wants to make use of this “exploit”, has database_owner rights inside the database or ddl_admin right with impersonate rights granted.
When all criteria are met, the user can get the SYSADMIN role granted after creating and executing following stored procedure (myHackingUser is the user account to which the SYSADMIN role should be granted off-course):
USE myDBWithTrustworthySetOn GO CREATE PROCEDURE sp_MakeMeSysadmin WITH EXECUTE AS OWNER AS EXEC sp_addsrvrolemember 'myHackingUser','sysadmin' GO --execute the new procedure with any user who has execute rights inside the database EXEC sp_ sp_MakeMeSysadmin
How to avoid possible exploits?
To detect if one of your Microsoft SQL databases is vulnerable for this exploit, following statement can be executed:
IF EXISTS(select 1 FROM sys.server_principals r INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id INNER JOIN sys.server_principals p ON p.principal_id = m.member_principal_id INNER JOIN sys.databases d ON SUSER_SNAME(d.owner_sid) = p.name WHERE is_trustworthy_on = 1 AND d.name NOT IN ( 'msdb' ) AND r.type = 'R' AND (r.name = N'sysadmin' or r.name = N'serveradmin' or r.name = N'securityadmin') ) BEGIN SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME FROM sys.server_principals r INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id INNER JOIN sys.server_principals p ON p.principal_id = m.member_principal_id INNER JOIN sys.databases d ON SUSER_SNAME(d.owner_sid) = p.name WHERE is_trustworthy_on = 1 AND d.name NOT IN ( 'msdb' ) AND r.type = 'R' AND (r.name = N'sysadmin' or r.name = N'serveradmin' or r.name = N'securityadmin') END
Now to solve:
- In case one or more databases are vulnerable, you should ask yourself if those databases really need to have the TRUSTWURTHY option ON or not? If not needed, just disable this option (OFF).
- If the TRUSTWORTHY option should be ON, does the database owner really needs to have the SYSADMIN/SERVERADMIN/SECURITYADMIN role granted? This should not be the case, so you should revoke those server-level roles from the database owner.
With special thanks to Eddy Van Heghe for discovery and investigation of this exploit!
Having troubles finding vulnerable Microsoft SQL databases after reading this article? Don’t know if you can just revoke the server-level role from the database owner? Or just need some help for your Microsoft SQL Server instances? Just ask us for more information or help about this exploit and the solutions. Contact us by phone: +32 3 450 67 89, via e-mail: email@example.com or by filling in the form on this page.