Bugtraq mailing list archives

Attacking EFS through cached domain logon credentials


From: Todd Sabin <tsabin () razor bindview com>
Date: 16 Jan 2003 11:35:07 -0500


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

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                                          <tsabin () optonline net>
BindView RAZOR Team                            <tsabin () razor bindview com>


Current thread: