I can’t tell you how irritated I get when I read yet another recommendation from some well-meaning security expert that says you should use EFS to encrypt files on a Windows SERVER. I have little or no problem with EFS on a Windows CLIENT (though if you’re not using domain accounts, or you don’t use SYSKEY [shudder], you’re only keeping your files safe from grandma, not your kids), but I have to wonder how many people understand how decryption keys are protected (and by what) when they recommend using EFS on a server.
SQL Database (mdf) encryption example
Let’s take a simple case: you want to protect your SQL database files from remote attackers, so naturally you think “I’ll encrypt the data using EFS – cheap, free and easy – and then remote attackers won’t be able to access the data.” Yes, in one sense that is quite true – if a remote attacker were to try to copy the files on disk – e.g. from a buffer overflow exploit that gave them remote LocalSystem access – then NTFS would return an Access Denied error.
- when you encrypt a file that is to be accessible to a Service (such as the “MS SQL Server” service that mounts the SQL database files), you are in reality required to encrypt the file in the context of the Service account in which the service runs.
- In this example, you’d have to encrypt in the MSSQLServer service’s account context – and if you’ve been reading your SQL Server security guidance, you’ll already have created a service account and downgraded MSSQLServer from the default LocalSystem service account context.
- This means that only the service account (e.g. you’ve created a local account named SERVER\SQLServiceAcct) can decrypt the files.
- What happens when the service starts? The service “logs on” with the SQLServiceAcct (actually the Service Control Manager calls CreateProcessAsUser() or similar API and runs the new process in the context of the user account specified as the Service Account in the service’s configuration).
- How does the Service Control Manager “authenticate” the service? The service account name is stored in cleartext in the Registry, and the service account password is stored as an LSA Secret elsewhere in the Registry.
- LSA Secrets are ACL’d so they are not readable by any user except the LocalSystem, and they are further encrypted with the System Key (aka SYSKEY), so that only the LSA process (which has the ability to use the SYSKEY decryption key) could access the LSA Secrets.
- [AFAIK] The Service Control Manager requests that the LSA decrypt the service account password and pass it to the Service Control Manager for use in the CreateProcessAsUser() API call.
- Once the MSSQLServer service is running in the correct user context, then the EFS driver in NTFS will decrypt the encrypted database files for the MSSQLServer process, and SQL Server will be able to mount the now-decrypted database files.
- Any process running in any other user context will not be able to supply the correct RSA private key for EFS to be able to decrypt the files. In our example, if the attacker could remotely run a script in the LocalSystem context that tried to copy the database files,NTFS will return an Access Denied message to the script process that tried to access the encrypted database files.
However, if that same remote attacker were really interested in getting access to that encrypted file, they could quite easily grant themselves access:
- Anyone with LocalSystem access (or local Administrators membership as well) could grant themselves the SeDebugPrivilege, and then run any number of “hacker” tools that could dump the LSA Secrets from memory into cleartext form.
- e.g. the family of lsadump*.exe tools attach to the LSASS.EXE process (via the Debug privilege) and dump out all the decrypted LSA Secrets.
- Once you have the decrypted LSA Secrets, you can quickly find the SQLServiceAcct password, which then gives you the ability to logon as that user account.
- Once you can authenticate as the SQLServiceAcct user account, you’ll have access to all the RSA decryption keys stored in that user’s profile. Then any attempts to read/copy files encrypted by that user will be automatically decrypted by EFS.
This is an unavoidable consequence of the scenario. Services must be able to start automatically (at least, on all Windows servers for which I’ve had to recommend security measures), which means that the Service Control Manager must be able to read the password from LSA Secrets without user intervention.
[This also usually means that SYSKEY boot passphrases or boot floppies won’t be used, since the use of an “off-system SYSKEY” means the server will never boot without an administrator intervening, which makes remote management a heckuva lot harder. Unless you have some of those fancy Remote Insight boards AND a sysadmin who doesn’t mind getting paged every time the server has to reboot.]
My conclusion: EFS-encrypting files for processes that start without user intervention provides very little protection against remote attackers who can gain LocalSystem or Administrators access to your server. This means *any* Service, whether on a server or a client (e.g. the ol’ ArcServ backup agent that runs on every Windows server and client, and [at least used to] “require” a Domain Admin account as the service account. That’s another hairy security implementation for another day’s rant, lemme tell you…).
[Note: Netscape web server had this same “problem” back in the days when I still administered Netscape-on-Windows. If you had an SSL certificate configured for the site, and you didn’t want to have to stand at the keyboard every time you wanted to start the web server, you’d have to store the private key’s decryption password in a plaintext file on the server. Kinda ruled out any *real* security that you could claim for that private key, but whatever – SSL was just there to encrypt the session key anyway, and very few SSL sessions lasted long enough for the fabled “sniff the SSL session on the wire” attacks anyway.]
SQL Database dump file example
“But wait Mike – what if the MSSQLServer service was always running? Doesn’t SQL have an exclusive lock on all its database files while the service is running?” Yes, absolutely. This brings to mind a couple of different thoughts:
- how do you make sure the service is always running – prevent it being shut down, or ensure that the server reboots as soon as the service is no longer running?
- if the files are already exclusively locked, doesn’t that mean the remote attacker won’t be able to read or copy the files off the filesystem? Why bother encrypting if the service *never* doesn’t run?
Also note: the “exclusive lock” principle obviously won’t apply to scheduled database dump files – the files are written once, then unlocked by the scheduled dump process/thread. This should make you think twice/thrice about encrypting the database dump files on disk – the files will be unlocked, waiting on the filesystem for that same LocalSystem/Admin attacker to logon as the dump user context and copy the files at their leisure. [It would also mean that any remote process to read or copy the dump files – e.g. an enterprise backup system running on a central server – would have to be able to decrypt the files remotely. This requires “Trusted for Delegation” configuration for the server where the dump files are held, which is a security headache that warrants careful thought before implementing.]
My best advice for protecting the database dumps from remote attackers?
- Don’t ever dump to the local filesystem of the server – stream your database backups over the network, either to a remote file share that wouldn’t be accessible to the remote attackers, or directly to a backup device that writes the files to backup media; OR,
- Minimize the amount of time that the database dumps are stored on a locally-accessible filesystem. Have the files copied off-device as soon as possible, and if possible wipe the free space after you’ve deleted the files (if you’re concerned about the remote attackers undeleting the files).