How might someone crack the SQL Server 2005 encryption stack?

Question

This is one for all you security gurus out there.

I have a SQL Server 2005 database with a database master key, which is encrypted with a very strong password using the server key, which in turn is encrypted using the service account credentials in the Windows Data Protection layer.

I have a certificate which is encrypted using the database master key.

I have a symmetric key using AES256 which is encrypted using the certificate, and I am using the symmetric key to encrypt and decrypt confidential fields in the database.

What does someone need to crack the encrypted fields in the database? My only assumption is that brute force can't be employed due to the strength of the symmetric encryption algorithm, and the symmetric key itself is protected by 4 additional layers of encryption:

Windows DPAPI -> Server -> Database -> Certificate -> Symmetric Key

which seems pretty tight to me.

Let's not include the obvious answer of "get the system administrator's username and password by drugging and sleeping with him", which is definitely relevant but not what I'm after.

Answer 1

Where are the server and database master keys backed up to? Is it a secure location?

Answer 2

Somewhere in memory this un-encrypted key is stored to be able to encrypt against it, is there a way for an attacker to gain access to SYSTEM level to then be able to basically scan memory, or attach an extra thread to MSSQL.

Also, these encrypted fields, are they used in any front-end applications? Are they visible when you SELECT * FROM table? For example, you can have as much security on your database and fields as you want but if someone is able to use an SQL injection to write their own SQL queries and thus view the value of the fields you are still back at square one.

Answer 3

Assuming no human-engineering attacks are possible I would try to attach a debugger to the program reading it, obtain a snapshot of it's memory and try every set of bytes in a brute-force attack.

Even if I couldn't obtain the memory image I would try the same thing with the source file in case the key is in there.

Realistically, you have to ensure the key never appears intact anywhere to defeat such attacks.

Answer 4

Here is a potential attack. It assumes you already have a way to run arbitrary code as the service account. For example, you might exercise a remote code execution bug to get. Having done so, it is relatively trivial to use DPAPI to get the server key. Having done that, you can get the master database key, although you'd need some brute force method to break the password.

It sounds like it would be pretty difficult to do, depending on the strength of the password maybe impossible. Is the service account low or high privileged? If it is an admin account, you could maybe use that (assuming it was broken) to install a keylogger to get the password.

Answer 5

K. Brian Kelley specializes in SQL Server security, and he's written several good articles about how encryption gets bypassed in SQL Server environments, like these:

• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-someone.aspx
• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/27/a-security-control-inconsistently-applied-is-not-a-control.aspx
• http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-your-dbas.aspx

If you're really into security, I'd highly recommend subscribing to his blog. He's also available on Twitter at http://twitter.com/kbriankelley.

Answer 6

how can someone encrypted fields in the sqldatabase?