Attacking EFS through cached domain logon credentials

[This isn't exactly new, but it does come up now and then, so I thought it might be useful to summarize it here.]

Recently, I stumbled upon a page on Microsoft's website,
<URL:http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/efs.asp>
which talks about possible attack(s) against EFS, by changing the Administrator's password. The conclusion of the article is that this is only possible if the user whose account is being attacked is not a member of a domain.

This is not completely correct, and I wanted to clarify how an attack against a domain-member's EFS encrypted files can work. The threat model is this:

Some corporate user has a laptop, and logs into it as a member of a domain, say CORP\bigshot. He has sensitive files on the laptop, and keeps them encrypted with EFS. The CORP network administrators are very diligent, and have removed any EFS recovery agent keys from the laptop. Nevertheless, while on the road, the user can still log in to the laptop as CORP\bigshot and use the encrypted files.

Now, some bad guy steals the laptop. Can the bad guy read the encrypted files?

The answer is that it depends (at least) on the strength of the user's password. Depending on your users and your password policy, this might vary from, "Trivial", to "Quite difficult".

Bad Guy attacks as follows:

1. Steals the laptop
2. Uses chntpw to change the Administrator's password.
3. Logs on as Administrator, using the password just set.
4. Dumps the CORP\bigshot's cached logon credentials. I wrote a tool, hashpipe, which dumps these. (Hashpipe has not been publicly released, and I have no plans to release it. But if I can do this, plenty of other people can, too.) These cached credentials are what allow the user to logon without a domain controller being reachable. They are not the same thing as the user's password hash, but a function of it and the username. Nevertheless, it is enough information to use in cracking the user's password.
5. Runs a dictionary attack against this "cachehash". If that doesn't yield the user's password, go to brute force. If the user's password is not particularly strong, he'll end up with the users's plaintext password in a few days.
6. Logs in as CORP\bigshot, and reads all the encrypted files.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

I did a demo of this exact attack, except for step 1, at BlackHat 2001.

Can other SYSKEY modes help? Given this threat model, probably not much. If the laptop has SYSKEY set to require a boot floppy, the floppy is probably going to be in the laptop bag, if not right in the floppy drive itself, and be stolen right along with the laptop. If the laptop has SYSKEY set to require a boot password, then the attacker just has another password to crack. (Cracking a SYSKEY boot password is different from cracking a cached domain logon credential, but just as feasible.)

In summary, if all your users have to do to access their encrypted files is type their password, that's all an attacker is going to have to do. If your users have easily crackable passwords, it doesn't matter if the files are encrypted with 128 bit DESX. One thing which may help is smart cards, but I haven't looked at that scenario, so can't really say one way or the other.

Also, bear in mind that the above is just one possible attack against EFS. Maybe you've don't actually have 128 bit encryption?
<URL:http://www.newscientist.com/news/news.jsp?id=ns99991804>

Maybe the attacker was sitting next to the user on an airplane, and watched him type his password. The attacker wouldn't even have to crack the password.

Maybe the user just closes his laptop when he's done working, doesn't log out or shutdown, and has set his Windows 2000 not to require a password when waking up. The attacker wouldn't need the password at all.

-- 
Todd Sabin                                          
BindView RAZOR Team