Tech Update - Why protecting backups is important

Posted by Michael Merlino - 30 July, 2018

header-picture

In a recent penetration testing engagement, I stumbled upon Microsoft SQL backups, on an unauthenticated iSCSI target. It got me thinking “what can I do with these backups? How can I exploit these?” Yes, I had information to payroll and other databases, but where’s the fun in that?

So I started planning my attack path. For this to be successful I needed all my ducks to align. I needed:

① Users to be in the master database;

 The users to have weak passwords;

 That user account to have permission to execute the native "xp_dirtree" or "xp_fileexist" stored procedure.

a. (https://www.rapid7.com/db/modules/auxiliary/admin/mssql/mssql_ntlm_stealer)

Service account to be a domain user of some sort;

Service account to have a weak password.

In this case I failed at point . If I had been given more time it might have been possible to crack the passwords and continue with the attack.

Let’s pretend if this was all within our grasp and run through how the attack would have played out.

We need somewhere to restore the database to. We can download and install the latest SQL Express; in this case it was Express 2017. We don’t know what version of the database the backups come from, so this is a good place to start. You can get it from here

Once installed let’s start the restore. First, we need to put the server into single-user mode. This is done by adding the startup option -m. For more detail visit Microsoft.

 Image1_1-1

Now that we have the server in single-user mode, let’s try to restore the master database we found. The quickest way is to run ‘sqlcmd -E -S .\SQLEXPRESS’  then: 

1 > RESTORE DATABASE master FROM DISK = 'C:\Temp\master.bak' WITH REPLACE;

2 > GO

 

But wait we get an error. We are using a different version. Good news is that we now know what build they are running. We can look up the build here. SQL Server 2012 Service Pack 4 (SP4). Now let’s download and install that version.

Image2

Now that we have the right version of Microsoft SQL, we will put the server into single-user mode and try again. This time we only need to run ‘sqlcmd’.

We did it 👏. We now have the master DB running on a server we control, so let’s start SQL and see what happens.

Image3

The server started. During the engagement SQL server failed to start as it could not find some important database files. This is easily fixed by creating the location of the database and copying dummy file that match the file name.

Image4

 Now let start ‘sqlcmd’ again. We have errors.

Image5

 Try running ‘cmd‘ as an administrator and see what happens. Look, no errors!

Image6

 Now let’s try to get a copy of the hash

1 > select user, password_hash from sys.sql_logins

2 > go

Image7-1

Let's find out who owns this database. 

1 > SELECT @@servername

2 > go

Image8

We can check if which users have sysadmin permission by running:

1 > exec sp_helpsrvrolemember 'sysadmin';

2 > go

 Image9

We now have our target and users with the correct permission. Let’s start by cracking the passwords with hashcat.

Look we found 2 passwords.

SQL Server 10

Now let’s start up Metasploit and see if we can capture the LM/NTLM credentials of the account running on the SQL Server service. First, we need to start up Responder (with all poisoning disabled). Then we can force SQL server to connect to our SMB server.

SQL Server 11

SQL Server 12

Yes, we have a hash now let’s start cracking and find out what access have.

We have admin access. In this case it was a Domain Admin account.

SQL Server 13

This attack path demonstrates how we can abuse something that may look innocent (a database backup) to achieve our goal, if specific conditions are met.

What can we do to protect against similar attacks?

There are a few things we can do. Make sure that any target backup location is locked down as much as possible. In our example above, the iSCSI share should require authentication.

We can also encrypt our backups. Microsoft has implement Backup Encryption in SQL Server 2014 and above. Here is a link to Microsoft official documentation.

Implement a strict password policy for service accounts, ensure that a password length of at least 30 characters is used.

Service accounts should be configured to use the principle of least privilege. This is where the account is assigned the least privilege possible to perform its function. This may reduce the impact if a system is compromised.

 


Recent Posts

7 Ways To Get The Most Out Of Your Next Penetration Test

read more

Tech Update - Patting the Printer for Credentials

read more

CPS-234: The Strategic Approach

read more