RE: Relative Security Provided by Cached Domain Credentials?

From: Kevan Smith (Kevan.Smith_at_tideworks.com)
Date: 05/11/04

  • Next message: Sergey V. Gordeychik: "RE: NT and 2000 account policies administrations" 
    Date: Tue, 11 May 2004 13:46:59 -0700
To: "Nicolas RUFF (lists)" <ruff.lists@edelweb.fr>, <focus-ms@securityfocus.com>

    We're testing the completeness of my understanding of Win2K3 PKIs, so
    feel free to correct me, but as I understand it the situation isn't
    quite as dire as Nicolas makes it sound.

    True, EFS certificates (indeed, all user certificates) are stored either
    in the users profile (locally on the client computer) or on a smartcard,
    depending your implementation. With certs stored in your user profile,
    the private key portion of the cert is stored locally on the client
    computer, and possibly archived on the issuing CA *. These certs are
    NOT available (to anyone) from other computers unless the user first
    exports/imports his/her certificate to all his/her workstations.

    So, even if an attacker cracks a user's password, he/she will still need
    the certificate to access the EFS encrypted files, which requires that
    they launch the attack while logged on locally to the victim's
    computer(s). Granted, it may be possible to drop a remote control
    backdoor on the box to log on undetected, or do any number of other
    nasty things to achieve the same effect, but it certainly raises the
    bar.

    While AEFSDR (or similar tools) looks like a handy addition to any
    administrators grab-bag, it doesn't lift any hurdles facing a hacker.

    If the EFS encrypted data is important enough (or the user hops
    workstations enough), you can remove the user's profile from the picture
    by requiring smart cards for EFS. The key pairs are stored on the card
    rather than the computer, allowing users to roam, and forcing the
    attacker to acquire both the username/password to logon to the computer,
    and the smart card/PIN to access the files.

    Cheers,

    Kevan S.

    * Private/Public key pairs may be archived to the CA under the
    following circumstances:
            - V2 certificate (V1 certificates cannot be archived)
            - Issued FROM a Windows 2003 Enterprise or DataCenter edition CA

                    (not Standard Ed)
            - Issued TO a user (as opposed to a computer)
            - Issued FOR encryption/authentication purposes (not signing/
                    non-repudiation).
            - Client certificate must be stored in the user profile. You
    cannot
                    archive certificates issued to a smart card.

    -----Original Message-----
    From: Nicolas RUFF (lists) [mailto:ruff.lists@edelweb.fr]
    Sent: Tuesday, May 11, 2004 11:02 AM
    To: focus-ms@securityfocus.com
    Subject: Re: Relative Security Provided by Cached Domain Credentials?

    > triple DES from memory
    >
    >>On a related note to part of the discussion in the 'Restricting change

    >>of local admin' thread, does anyone know of a non-brute force way to
    >>break the encryption on cached domain credentials? Local accounts are

    >>easily modified or reset, but I'm not aware of any similar exploits
    >>for cached domain credentials. Given that EFS' effectiveness to
    >>secure laptop-stored data in a domain environment lives and dies by
    >>the security of the cached credentials, I'm curious to know just *how
    >>much* more secure they are.

            Hi,

    About EFS :
    -----------

    - EFS encryption is 3DES (unless you have a restricted export version of
    Windows), with a random FEK (File Encryption Key) for each file.
    - FEK is encrypted with RSA, using the EFS User Certificate (Public
    Key).
    - Eventually, the user Private Key is encrypted with his Windows
    Password.

    So if you know the user password, you can decipher all EFS encrypted
    files. See "Advanced EFS Data Recovery" tool from ElcomSoft :
    http://www.elcomsoft.com/aefsdr.html

    About Cached Logons :
    ---------------------

    Cached logons are stored in LSA Secrets and NL$ hidden keys. Basically,
    it is a salted hash :
    NTLMHash( username + NTLMHash(password) ) so you have to bruteforce. The
    salt key is the username, so if you have N accounts to crack, it takes N
    times the time to crack one account.

    Since this attack is very time-consuming and has little chance to
    succeed if user password > 6 chars, there is no public exploit
    available. Hint : get an IDA Pro license if you want to know more :-)

    -nicolas-

    ------------------------------------------------------------------------ 

    ---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
  • Next message: Sergey V. Gordeychik: "RE: NT and 2000 account policies administrations"

    Relevant Pages

    • RE: Relative Security Provided by Cached Domain Credentials?
      ... Smart Card support for EFS does not exist in W2K, W2K3, or XP. ... Relative Security Provided by Cached Domain Credentials? ... during decreption or encryption for that matter only the personal ... certificate store is checked for a key, ...
      (Focus-Microsoft)
    • RE: Relative Security Provided by Cached Domain Credentials?
      ... So when a user logs on the w2k terminal using a smartcard + pin no (rather ... If it does then EFS ... profile currently logged on for the private certificate. ...
      (Focus-Microsoft)
    • RE: Relative Security Provided by Cached Domain Credentials?
      ... certificates assigned to them, with each certificate having a set number ... smart card management tools which provide private key archival for smart ... AND the cert is also valid for EFS, they likely would be able to do ... What you probably could get to work for local file encryption, ...
      (Focus-Microsoft)
    • Re: EFS Disabling
      ... >> I had to reinstall XP on a computer and so I copied my EFS ... They have the same account names ... > You must have exported your EFS security certificate (onto a floppy ... > claiming that if you included your profile in your backups that there ...
      (microsoft.public.security)
    • Re: EFS Errors
      ... Disabling DFS can disrupt your Group Policy propagation which may be causing ... your EFS errors if you have changed your Recovery Agent Certificate. ... I am able to encrypt on the server but noone is able to encrypt ...
      (microsoft.public.security)