Skip navigation

Category Archives: SQL Server 2008 R2

There is no question that one of a corporation’s most valued assets is its data. As such, there are some people that would love to exploit an RDBMS by any means necessary to gain access to this asset.

Martin Rakhmanov (LinkedIn) of TeamShatter, the research division of Application Security, Inc. (AppSec) discovered a SQL Injection vulnerability in the RESTORE DATABASE command. According to the TeamShatter advisory, the vulnerability exists in SQL Server 2005, 2008, and 2008 R2. (It is worth a note that the discovery and Microsoft’s reply were prior to the release of SQL Server 2012) In 2008, SP3 was supposed to have addressed the issue, however, a look into the release notes mention nothing of it. Mr. Rakhmanov claims to have been able to elevate his rights from to sysadmin, but admittedly, it takes some setup to be able to leverage:

  • First, a user must have CREATE DATABASE permissions on the SQL Server. Now, if you think about it, that really isn’t much of a stretch if you don’t take your SQL Server security very seriously. Say a vendor needs to install a database for a new app that your company just purchased. You’re an extremely busy production DBA, so you allow the vendor temporary access to install their database. It doesn’t have to be a vendor; I am sure there are plenty of us who have worked with “that one person” that may be a bit disgruntled, and would like to do harm to the business. One favor later, and you are susceptible.
  • Next, a database is created. Not just any database… No, this database is special. This database has a very specific name that I won’t mention here. I will leave that name up to you, dear reader, to find out for yourself. Suffice it to say, you have likely never seen a database with a name quite like this one.
  • Once the database is created, it is backed up to a local file.
  • Then, this backup file is manipulated in a hex editor. One digit is all that needs to be altered.
  • Finally, the backup file is “restored” which is where the exploit does its work. The user with only CREATE DATABASE permissions now is a member of the sysadmin fixed server role.

There are a plethora of measures to take to mitigate this exploit, one of which being a good, sound security policy that does not grant anyone outside of your company ANY access to your SQL Servers unsupervised. Ever. I tested a few other methods, and these have been the most effective:

  • Server Trigger: Create a server trigger that fires on the CREATE DATABASE command. My SQL servers will not have vendor databases installed on a regular basis. This trigger will ensure that no databases can be created while it is enabled. It will also log a record into an administrative database with pertinent information about the attempt, including the username of the person attempting to create the database, the time/date, and the actual code that was used. Finally, an email is fired off to alert administrators of the attempt.
  • SQL Server Agent Alerts: Create Agent Alerts that will fire on a number of restore events – a list of which can be obtained from querying the sys.messages table. While creating a database might not be all that common, restoring a database might be something that could be more feasible. There are quite a few event IDs to alert on, so you’ll have to be choosy as to which ones you will want to define. We chose five successful and five unsuccessful restore alerts.

While no mitigation plan could be 100% fool-proof, we have a duty as DBAs to make a hacker’s life as difficult as possible when it comes to our data. The measures above have proven to go a long way in preventing an exploit of ever getting off of the ground. In addition to the mitigation measures, logging provides accountability and allows the DBA to prove where the attempt came from. Using the EVENTDATA() function to shred XML, the DBA has a great many number of elements to include in a log. Hopefully, if you run into this issue, you can use some of these same measures to secure your server, and stop the bad guys! As always, leave a comment if you have any ideas to add. I am a perpetual student of technology, and I am always up for learning something new.