This is part of a series of tips on how bad/rogue admins can get access to the data in your SQL Servers.

The service account for SQL Server is a member of the sysadmin role. This is required. And one would think that if you follow all the best practices for protecting the password, you'd be okay. But the truth of the matter is you're not. There are two well known attack vectors a bad admin can use to get the service account for SQL Server and therefore get access to SQL Server itself. Both are nearly impossible to audit for via normal means.

Attacking LSA Secrets:

The operating system needs to know the password for every account used to start a service. That means it has to store the password in a format it can decrypt and use. And that means at some point that password becomes visible if you can interrupt the process. Without going into a lot of detail, you can. You have to have debug rights, and if you have those rights you can get access to those usernames and passwords. Administrators have those rights, meaning they can, with the help of a tool, get the password for SQL Server. Once they have said password, they can log in as a member of the sysadmin role, with complete control of the system.

Typically I've seen Antivirus be able to catch use of the tool. but admins usually have the ability to temporarily make an exception for the tool. This can be done locally with most products, so unless you're auditing for that sort of thing, you won't see that the tool is being used. If you don't have antivirus on your SQL Servers, you don't even have this layer of protection.

Another option may be limiting where a user account can run, but obviously an admin could run the service account on the same server as where the SQL Server is. Given that, this is a hard one to protect against.

Attacking the AD SAM:

If I have domain admin rights, I can get access to the SAM for Active Directory. Because Windows doesn't salt its passwords, they are susceptible to cracking using rainbow tables. So if I can grab the SAM, I can take it offline, use a tool that can hit the rainbow tables, and eventually get the passwords. BTW, I don't have to get the service account for SQL Server, either. I just have to get someone with the rights to the data I want. And here's the kicker: because it's a legitimate username/password, the compromised user never knows. Once I have the credentials, I have the data. And I have the data running as the other user, not myself.

Again, the tools typically used to dump the SAM are most often identified by antivirus, but some folks don't run AV on their domain controllers. There are legitimate accesses to the SAM by domain admins, so it's hard to audit for this attack. Basically, the best policy is to limit the number of domain admins and try your best to make sure they are trustworthy.

 EDIT: SQL Server 2008 Running on Windows Vista or Above

Windows Vista introduced service isolation, where services have SIDs, like users and groups do. This prevents the situation where I have a user account being shared by two services but the resources for those two services should be kept separate. For instance, System may drive my backup agent and System may be the account that drives some other agent on my server. With service isolation, if I assign rights based on the service SID, that means they don't cross.

If you've installed SQL Server 2008 or higher on a Vista or higher operating system, you can take advantage of this. That means it's not the user account that gets access to SQL Server, but rather the service itself. This prevents this attack. However, if you must still run SQL Server 2000 or 2005 or you're still on Windows Server 2003, you're susceptible. Yet another reason to push the upgrade on both SQL Server and the operating system.