Pass Summit 2017: how to bypass SQL Server security

Last Friday I saw a very interesting session in Pass Summit 2017 about how to Bypass, or Ensure, SQL Server security by Matt Martin.
Matt explained us how to bypass SQL Server security with the complicity of your SQL Server DBA.
Msdb is the most powerful database to get stuff done: mail, jobs… so let’s have a look how to take the power within a SQL Server instance.

Start a job under SQLAgentOperator role

SQLAgentOperator give you the right to execute all job even if it runs under sysadmin.
If your SQL Server DBA grant your login as a member of this role and if a job runs a Stored Procedure what you are able to modify you are the master of the box as you can grant your login as sysadmin.

Start a job from MSDB with parameter

The goal here is to ask you DBA to create a Stored Procedure with as parameter a job name in order to simplify process because you need to run several different jobs

Procedure like that:

USE msdb
GO
CREATE PROC dbo.sp_run_job
  @name varchar(500)
  WITH EXECUTE AS OWNER
AS
  exec sp_start_job @job_name = @name

With this kind of Stored Procedure you can do whatever you want on the server.

Linked Server Elevated privilege

If you have a linked server that logins into a foreign server with a sysadmin account, ask you DBA to enable RPC out for the linked server for a good reason like decrease the stress on both servers.
If you DBA does the job you can execute this kind of script:

EXEC(‘Alter server role sysadmin add member [adsts]’) at linked_Server1

Nice not?

I need a sandbox database that I’m DBO on

The goal for this one is to convince your DBA to create for you a sandbox database on a production server for a good reason like working with production data (a good reason?)…
Once done ask him to schedule a Stored Procedure you wrote on a daily basis.
If he does is just alter you Stored Procedure with the following code:

ALTER SERVER ROLE SYSADMIN ADD MEMBER [adsts]

Another way to become quickly sysadmin!

Xp_cmdshell to take over the box

Xp_cmdshell is running under SQL Server service account which often is Local admin of the box.
Ask your DBA to grant you permissions to xp_cmdshell and argue that you need to delete some files after importing them on the server.
If the account that runs SQL Server is a local Administrator, you can add your account as an Administrator of the server and whatever you want…

EXEC xp_cmdshell ‘net localgroup administrators adsts /add’

Oups…

How to close Loopholes

Never enable a business user for SQLServerOperator role.
Never use SA or another sysadmin account for linked server but set it to a reader login with minimum permission.
Never schedule a job that calls a SP where business user has alter access to.
Never allow a parameterized job call in MSDB, always hardcode the job name to avoid modification of this job name.

Just give the necessary permission!
Create a server trigger which send an Email to DBA when somebody becomes sysadmin on the instance. Like that DBA can look at this new account immediately and see if somebody tries to squeeze the system.