Home > Uncategorized > EFS encryption, the messy side of file encryption, or how to use a file to store a password for a service

EFS encryption, the messy side of file encryption, or how to use a file to store a password for a service

EFS is generally not great to use. It’s largest problem is that your domain admin might have forced a “recovery agent” certificate onto your system, which means that they can see your encrypted files.

Generally, it’s pretty unfriendly, and, due to the cache, sort of stupid to use in an interactive user session.

Nonetheless, I will discuss it briefly here so that we can use it in an non-interactive user session, say so a service can read a file where a password is stored.

Our scenario will be that we want to create a file to store passwords, and encrypt that file with EFS, in turn encrypting it against a certificate that lives in a specific user’s certificate store; the user who’s running the service.

Create the local user:

net user sshsyslogsvc test1234 /add

Create the file I want encrypted using a public-private key pair used by EFS:

echo > c:\syslogpassword.txt
subinacl /file c:\syslogpassword.txt /setowner=sshsyslogsvc
#this tool is available in the support tools, sorry it seems to be the only way (http://ss64.com/nt/subinacl.html)
cacls c:\syslogpassword.txt /g sshsyslogsvc:F
runas /user:sshsyslogsvc "cmd.exe /c echo syslogger_PASSWORD> c:\syslogpassword.txt"

Create the key for use with EFS:

runas /user:sshsyslogsvc "cipher /k /q"

Encrypt the file using EFS:

runas /user:sshsyslogsvc "cipher /a /e c:\syslogpassword.txt"

Testing access and EFS:
Since we’re logged on to our system as a local administrator, we can take ownership of any files on the system, so let’s do that then try to read the file:

subinacl /file c:\syslogpassword.txt /setowner=mbrown
cacls c:\syslogpassword.txt /e /g mbrown:F
more c:\syslogpassword.txt
#returns: 'Cannot access file C:\syslogpassword.txt'
runas /user:sshsyslogsvc "cmd.exe /c more c:\syslogpassword.txt && pause"

The user sshsyslogsvc is the only user that has it’s EFS certificate in it’s accessible certificate store, therefore it is the only user who has access to the file.

Deny the user interactive rights

ntrights +r SeDenyInteractiveLogonRight -u sshsyslogsvc

Conclusion
Since the file can now be read by the sshsyslogsvc user, you can put some logic in there and you’ve made yourself a sort of secure password store. Combine this with xargs, and you should be all set to -I it into a command line.

Caveats of EFS:
If in the same user session, a key is deleted from the local key store (using certmgr.exe for instance), then attempt to access the file again, guess what? The public key is still found in the EFS cache. This is not good. This old thread, with some valid input from MSFT, explains that this is truly the case. The only way to clear your cache will be to log out and back in, or you can always flood the cache.

How do you flood the cache, is the question?

If I log on as another user then loop through trying to read the efs protected file 1000 time, it doesn’t clear the cache:

runas /user:dummylocal cmd.exe
for /l %G in (1,1,1000) do more c:\syslogpassword.txt 2>1> NUL

So, what is an “EFS operation” and how do I do one? No one knows.

A great write up of how EFS functions explains many more technical aspects of EFS.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: