32

Scenario: You're handed a database backup and told to restore it to a server (that's already hosting other databases), but are given no useful information about what the backup contains or whether the source should be trusted.

Question 1: What are the potential implications of restoring a backup that could well be malicious?

Question 2: What can you do to protect your server/the data in other databases from the impact of restoring a potentially-malicious backup? RESTORE VERIFYONLY would seem to be a good first step. The ultimate answer is probably 'restore the database in a sandbox VM with no access to the outside world', but let's assume that option is off the table. What else should be done in this situation?

Thomas Stringer
  • 42,434
  • 9
  • 120
  • 155
Simon Righarts
  • 4,753
  • 1
  • 28
  • 31

8 Answers8

22

A database may contain malicious code, possibly a procedure that is going to change a password for the "sa" login or drop every database. However the only way that I can see that causing an issue is for an individual to restore the database, and then manually execute any code within that database. It would not execute in any automated manner.

There is no setting that can be applied within a database to have SQL Server automatically execute some bit of code within the database upon restoring it to a server. If it did I would expect Microsoft would loose the Common Criteria certification for the product. That is to great of a bug to have allowed in a DBMS to me.

11

There are some prevention steps that you could do.

  1. Make sure no one but one sysadmin has access to the restored database.
  2. Put the db in single user mode after the restore is completed.
  3. Check the code inside all stored procedures and functions and triggers inside this database.
  4. Perform a dbcc checkdb to make sure there are no integrity issues.
  5. Check the users which used to have access to the database and remove all of them.
  6. Start allowing access, very restricted to specific objects checked by you.

Like Shawn said, the code will not execute by itself unless some stored procedure which seems vbalid has an exec of another malicious code. This is the reason of checking the code inside each one of them before putting it multi user mode.

yrushka
  • 1,994
  • 1
  • 16
  • 22
10

I'm reaching here, but I can think of at least one dangerous scenario: if you restore a database that has a filetable, those files are now on your network by default (and specifically, on your SQL Server). You could restore a virus.

That by itself won't do anything, of course - the virus doesn't suddenly become sentient - but if your users then try to access the file, they could be infected. (Hey, I said I was reaching.) I'm envisioning a scenario where an outside hacker wants to get malware in the door, and he then sends an email to Bob in accounting saying, "Here's the file: \sqlserver\filetableshare\myvirus.exe" - at that point it's gone past your firewalls without detection, and we're now down to your internal antivirus and anti-malware tools.

Brent Ozar
  • 43,325
  • 51
  • 233
  • 390
7

RESTORE VERIFYONLY would seem to be a good first step. The ultimate answer is probably 'restore the database in a sandbox VM with no access to the outside world', but let's assume that option is off the table. What else should be done in this situation?

Restore verifyonly verifies integrity of database it WILL NOT tell you whether backup includesa malicious code or not RESTORE VERIFYONLY does not attempt to verify the structure of the data contained in the backup volumes. Its highly unlikey that if backup comes from inside the firm where you work could be malicious but if it comes from some third party you need to be careful as Shawn pointed.

Microsoft Online documentation says that

•For security purposes, we recommend that you do not attach or restore databases from unknown or untrusted sources. Such databases could contain malicious code that might execute unintended Transact-SQL code or cause errors by modifying the schema or the physical database structure. Before you use a database from an unknown or untrusted source, run DBCC CHECKDB on the database on a nonproduction server and also examine the code, such as stored procedures or other user-defined code, in the database.

Shanky
  • 19,148
  • 4
  • 37
  • 58
7

The question focuses mostly on a backup containing malware, but it's also possible to get unwanted and potentially malicious behaviour from the restore operation itself.

I've accidentally found in the past that it's possible to crash SQL Server by trying to restore a corrupt backup file that causes SQL Server to try to read past the end of the backup file and crash. I'm not sure which versions are susceptible or exactly what is required to reproduce the problem. I documented some limited details here when I encountered this problem a few years ago.

Community
  • 1
James Lupolt
  • 4,278
  • 5
  • 31
  • 46
5

What risk is there is restoring an unknown database from an unknown source? None.

What risk is there in letting an unknown application connect using a sysadmin account to connect to that database and start running code? LOTS! If the application account only has rights within the database and no server level access then there's nothing it can really do outside of the database. This basically comes down to having a proper security framework setup on the server to begin with.

mrdenny
  • 27,106
  • 2
  • 44
  • 81
2

You're handed a database backup and told to restore it to a server (that's already hosting other databases), but are given no useful information about what the backup contains or whether the source should be trusted.

Nice. You demand a signed written statement from whoever is telling you to do this that they accept full responsibility for the consequences. If they're unwilling to do that, you should test install in a sandbox after examining the backup file (if possible), and thoroughly examine all tables, procedures, etc. If anything smells funny at any point, don't put it on the production system. Even then, you should make it clear (to your boss and his superiors) that you never trusted the backup and are doing this only under direct orders.

If they won't sign such a statement, alert their superior(s) before doing anything. As a professional, it's your duty to protect your system as much as possible, no matter what some dim-witted superior may order you to do. You might get fired, but you can hold your head high and know you did the right thing.

Phil Perry
  • 21
  • 1
2

There are not alot of dangers per say, other than some far-reaching ones suggested here. As was mentionned, it is hard to have auto-executing stuff in a database backup itself. It needs some kind of exterior triggerring mechanism.

Get an old laptop/desktop and an evaluation version of your Database software (SQLExpress) if licensing is an issue. Copy the backup file on the machine, unplug the network/wireless, and do the restoration. Then start digging. Take all the time you need, because there are many places stuff can hide, most of them already covered by other posts in this thread.

Your DBA integrity and the well-beiing of your Production environment is more important than any order given by a superior.

Philippe
  • 517
  • 6
  • 15