Attacking EFS through cached domain logon credentials

From: Todd Sabin (tsabin@razor.bindview.com)
Date: 01/16/03

  • Next message: Kim, Anthony: "RE: AD replication over WAN" 
    To: bugtraq@securityfocus.com, focus-ms@securityfocus.com
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>

    Relevant Pages

    • Attacking EFS through cached domain logon credentials
      ... against a domain-member's EFS encrypted files can work. ... Some corporate user has a laptop, and logs into it as a member of a ... Logs on as Administrator, ... attacker just has another password to crack. ...
      (Bugtraq)
    • Re: encrypted files (NTFS EFS) on external USB drive
      ... The second machine is also running XP Pro SP2 (the machines in question ... are my desktop and my laptop, both running XP Pro SP2, in my residence, ... successfully) and it still won't let me open the encrypted files. ...
      (microsoft.public.windowsxp.security_admin)
    • RE: Password "security" - was"Passwords with Lan Manager (LM) und er Windows" an
      ... I also agree that BIOS are usually trivial to get rid of. ... With SYSKEY, the method would be standard across all our models ... you will give the attacker a much harder time. ... Google is sure to reveal the right method for any model of laptop. ...
      (Pen-Test)
    • Re: Remote administration of a machine behind NAT
      ... What's the likelihood an attacker will even care that the ... system can access your laptop? ... the upstream ISP would block it), enable ssh on the remote system, ...
      (Debian-User)
    • Re: Laptop Security - harddisk encryption necessary?
      ... There are few cases that a corp lost their laptop with customer ... when the attacker has complete access to everything in the box. ... trivially retrieve every bit of data on it. ... If all else fails, the attacker can simply remove the hard drive ...
      (comp.security.misc)