EFS Certificate Configuration Updater tool is released!

After weeks of battling with Visual Studio over some pretty gnarly code issues, I’ve released the first version of a tool that will make IT admins happy the world over (well, okay, only those few sorry IT admins who’ve struggled to make EFS predictable and recoverable for the past seven years).

EFS Certificate Configuration Updater is a .NET 2.0 application that will examine the digital certificates a user has enrolled and will make sure that the user is using a certificate that was issued by a Certificate Authority (CA).

“Yippee,” I hear from the peanut gallery. “So what?”

While this sounds pretty freakin lame to most of the planet’s inhabitants, for those folks who’ve struggled to make EFS work in a large organization, this should come as a great relief.

Here’s the problem: EFS is supposed to make it easy to migrate from one certificate to the next, so that if you start using EFS today but decide later to take advantage of a Certificate Server, then the certs you issue later will replace the ones that were first enrolled. [CIPHER /K specifically tried to implement this.]

Unfortunately, there are some persistent but subtle bugs in EFS that prevent the automatic migration from self-signed EFS certificates to what are termed “version 2” certificates. Why are “version 2” certificates so special? Well, they’re the “holy grail” of easy recovery for encrypted files – they allow an administrator to automatically and centrally archive the private key that is paired with the “version 2” certificate.

So: the EFS Certificate Configuration Updater provides a solution to this problem, by finding a version 2 EFS certificate that the user has enrolled and forcing it to be the active certificate for use by EFS. [Sounds pretty simple eh? Well, there’s plenty of organizations out there that go to a lot of trouble to try to do it themselves.]

Even though this application fills a significant need, it doesn’t (at present, anyway) do everything that might be needed in all scenarios. The additional steps that you might need to cover include:

  • Enrolling a version 2 EFS certificate. [You can automate this with autoenrollment policy and the Windows Server 2003-based CA that is already in place for issuing v2 certificates and Key Archival.]
  • Updating EFS’d files to use the new certificate. [You can automate this by using CIPHER /U, but it’ll take a while if the user has a lot of encrypted files. The good news, however, is that the update only has to re-encrypt the FEK, not re-encrypt the entire file, so it’s much quicker than encrypting the same set of files from scratch.]
  • Ensuring that the user’s EFS certificate doesn’t expire before a new or renewed certificate is enrolled. [This is very easy to accomplish with Autoenrollment policy, but without the use of Autoenrollment, there is a significant risk that when the user’s preferred EFS certificate expires, the EFS component driver could enroll for a self-signed EFS certificate.]
  • Archiving unwanted EFS certificates. [This is different from deleting a digital certificate – which also invalidates the associated private key, which is NOT recommended. This would keep the certificates in the user’s certificate store, and preserve the private key — so that any files encrypted with that old certificate were still accessible. This is hard to do from UI or script, but is a feature I’m hoping to add to the EFS Certificate Configuration Updater in the near future. This is also optional – it just minimizes the chances of a pre-existing EFS certificate being used if the preferred certificate fails for some reason.]
  • Publishing the user’s current EFS certificate to Active Directory. [This is also optional. It is only necessary to make it possible — though still hardly scalable — to use EFS to encrypt files for access by multiple users (see MSDN for more information). This can be automated during Autoenrollment, but some organizations choose to disable publishing a 2nd or subsequent EFS certificate since the EFS component driver may get confused by multiple EFS certificates listed for a single user in Active Directory.]
  • Synchronizing the user’s EFS certificate and private key across all servers where encrypted files must be stored. [This is not needed if you’re merely ensuring that all sensitive data on the user’s notebook/laptop PC is encrypted, so that the loss or theft of that PC doesn’t lead to a data breach. However, if you must also enforce EFS encryption on one or more file servers, the EFS Certificate Configuration Updater will not help at all in this scenario.]

Try it out — Tell your friends (you have friends who’d actually *use* this beast? Man, your friends are almost as lame as mine – no offense) — Let me know what you think (but no flaming doo-doo on my front porch, please). And have a very crypto-friendly day. 😉

Advertisements

EFS + SYSKEY followup, NTBackup and EFS-TPM integration

A colleague recently asked me about a previous post of mine:

“Mike, in your blog you mentioned you must use Syskey for real protection of EFS protected data. You said if you didn’t use Syskey, it was relatively easy to get to EFS files. So 3 questions that I haven’t been able to find an answer:

  1. Are there any public attacks documented or tools to get to EFS protected data, other than cracking the user desktop login password? If yes, please link. I guess this would be cracking the DPAPI secure store.
  2. What NTBackup options are required to keep the data encrypted in the .bkf file? If there isn’t a way, how can data files in incremental backups be safely encrypted?
  3. Dell is now shipping TPMv1.1 chips in their Inspiron & Latitude laptops. Can EFS private keys be stored there? How can you know that the private key is actually stored in the TPM chip?”

First I should clear up the misunderstanding I may have created regarding SYSKEY and EFS. What I meant to assert is that EFS files are relatively easy to get at (for educated attackers) unless you use either:
(a) SYSKEY boot floppy or SYSKEY boot password, or
(b) domain logon accounts (and a relatively decent password/passphrase).

I don’t generally recommend SYSKEY in a domain environment; instead I recommend domain accounts and strong passwords or passphrases for reasonable security against brute force attacks.

As for the direct questions I *was* asked:

  1. There are no cryptographic “backdoors” to attack EFS data – the cryptography behind EFS, combined with the reliance on multiple layers of protection of the encryption keys, follows the usual best practices for software-based data encryption. I have faith in DPAPI to do what it sets out to do, and to be as secure as any software-based encryption implementation can be. However, there are a number of potential attacks on EFS’d data – none of them “magic”, but really just predictable consequences of both (a) the ways that keys must be stored on disk and (b) the integration of EFS with the Windows logon infrastructure.
  2. No parameters or configuration are necessary for NTBackup to be able to backup encrypted files – its default behaviour can natively backup EFS encrypted files. NTBackup is one of a class of applications that use the RAW APIs. Applications that call these APIs are requesting that NTFS give them the “raw” file along with the EFS alternate data streams, all in a single binary stream. This means that NTBackup gets a copy of the encrypted file and its keys, so that the backup files contain everything that’s needed to decrypt the files later. When NTBackup restores such files to an NTFS filesystem, you get back the encrypted file intact with its encryption keys. So you can backup any files you like with NTBackup – full, incremental, whatever – and rest assured that the backups are no more vulnerable than the original files. While some backup solutions end up with plaintext copies of the files, those backup apps that use the RAW APIs never expose the unencrypted file contents to later attack.
  3. All currently released versions of Windows are hard coded to ONLY use the native software CSPs for EFS (specifically, the Base or Enhanced CSPs) – they can’t use any other CSPs for EFS, even the oft-requested smart cards (nor the TPM-enabled CSPs). I have no idea whether there will be support for TPM storage of EFS private keys in Windows Vista, though they have announced plans to include EFS-private-key-on-smartcard support. They also mention support for a “full volume encryption” feature (AFAIK, unrelated to EFS) that would work on systems with TPM v1.2 chips. I assume the TPM software dictates how keys are managed, but until there’s any information on whether non-smartcard CSPs are supported, I can only speculate how “enforcing” TPM storage could possibly work. At this point, I believe the “enforce smartcard” option in Windows Vista EFS is a simple checkbox, so it’s probably hard-coded to look for smartcard CSPs only.

I had a quick look around the Internet for current details on leveraging a TPM (Trusted Platform Module) chip for encrypting files on disk – here’s what I learned on my first pass:

  • There’s very little mention of which version of the TPM spec is supported on most PCs in the market today – or at least, that information is not easy to uncover. So far the only mention I’ve found on Dell & Toshiba’s sites is “v1.2” for certain Optiplex models, and v1.1 Infineon chips in the Toshiba Tecra M4 & Latitude systems you mentioned.
  • So far I don’t know if there are any significant differences between v1.1 & v1.2 TPM chips in terms of support from the CSPs, and what application scenarios are/are not supported by each version. Maybe the differences are negligible, maybe there’s an order of magnitude more possibilities once you have v1.2. [Or maybe that just happens to be what the “full volume encryption” team was willing to test, even if v1.1 would have been just as good for this scenario.]
  • Seems like every PC vendor has some models shipping with TPM chips – IBM/Lenovo (Atmel), Toshiba (Infineon), HP, Dell. Good news for us.
  • Seems like there’s only a small number of application + CSP suites out there so far that enable TPM in XP:
  • Some suites leverage particular application APIs that require third party plug-ins (e.g. Dell/Wave)
  • Others (e.g. Toshiba’s suite) “support” EFS features – I don’t know what this means, as the documentation I’ve seen is too vague to be sure:
    • Does it merely leverage the DRA public key to provide a recovery path for the Personal Secure Drive (encrypted virtual drive)?
    • Does it encrypt the contents of the user’s profile with keys protected by the TPM?
    • Does it somehow provide a redirection layer so that the RSA files in the user’s profile are actually encrypted by TPM-protected keys before the Windows CSPs drop the files on disk?

This is fascinating, and a lot more than I expected to turn up. It seems that TPM has finally started to catch on with the PC vendors – I was shocked to see that pretty much all the major PC vendors had TPM-enabled PCs. It’s not that I didn’t expect this to happen, but that since I hadn’t heard any of my customers asking me about this so far, I assumed it was still “on the horizon” (like “the year of the PKI” is still just a year or two away, for the tenth year in a row).

I’m going to devote some serious research into the state of TPM-enabled data encryption, and over the next few posts I’ll be putting up my findings and opinions on where I think TPM-enabled encryption fits into the kinds of solutions I normally recommend.

Watch for it.

Encrypting files on the server – WTF???

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).