RE: Relative Security Provided by Cached Domain Credentials?

From: Langston, Fred (flangston_at_verisign.com)
Date: 05/25/04

  • Next message: Vyacheslav Ponomarenko: "Re[2]: Relative Security Provided by Cached Domain Credentials?" 
    To: 'Kim Oppalfens' <Kim.Oppalfens@azlan.be>, Kevan Smith <Kevan.Smith@tideworks.com>, "Nicolas RUFF (lists)" <ruff.lists@edelweb.fr>, focus-ms@securityfocus.com
Date: Tue, 25 May 2004 17:51:00 -0400

    Here's a reference for EFS and smart cards:
    http://www.petri.co.il/how_does_efs_work.htm

    This is the relevant text:

    EFS's key-storage mechanism is based on W2K's CryptoAPI architecture, which
    stores users' public and private keys separately from the randomly generated
    FEK. This setup lets users store their private keys on secure devices (e.g.,
    NTFS volumes, smart cards). Smart cards, which require smart card readers on
    computers, are credit-card sized devices that let users log on to W2K with a
    PIN. Smart cards make personal information (e.g., account numbers,
    passwords, digital certificates) portable.

    Fred Langston, CISSP
    Principal Consultant
    VeriSign, Inc.
    W: 206.903.8147 x223 M: 425.765.3330
    FLangston@VeriSign.com

    -----Original Message-----
    From: Kim Oppalfens [mailto:Kim.Oppalfens@azlan.be]
    Sent: Tuesday, May 25, 2004 6:56 AM
    To: Kevan Smith; Nicolas RUFF (lists); focus-ms@securityfocus.com
    Subject: RE: Relative Security Provided by Cached Domain Credentials?

    I have seen mentioned the use of smartcards for efs certificates in this
    thread a couple of times.

    Although it would be nice in theory it was my understanding that this cannot
    be used at present because not thought about in the efs API, so during
    decreption or encryption for that matter only the personal certificate store
    is checked for a key, not any smartcard related stuff.

    At least that is what I understood about efs and smartcards.
    Has any of you actually tested the smartcard solution, or it this how you
    would theoratically handle it?

    Kim Oppalfens

    -----Original Message-----
    From: Kevan Smith [mailto:Kevan.Smith@tideworks.com]
    Sent: dinsdag 11 mei 2004 22:47
    To: Nicolas RUFF (lists); focus-ms@securityfocus.com
    Subject: RE: Relative Security Provided by Cached Domain Credentials?

    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: Vyacheslav Ponomarenko: "Re[2]: Relative Security Provided by Cached Domain Credentials?"

    Relevant Pages

    • Re: decrypting files from XP - tough question
      ... EFS uses a hybrid asymmetric/symmetric encryption scheme. ... It is to those keys which EFS encrypted the ... That session key can only be retrieved by those same certificates. ...
      (microsoft.public.security)
    • Re: file security
      ... When enabling EFS on a computer, ... Subject: Again with the Encryption! ... >Copying saved certificates will not work--you have to export and import ... >the usual enquirer might find by looking under a search on Encryption. ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Windows XP -- encrypt, decrypt -- I am in deep TROUBLE -- HELP
      ... Most of the time people post regarding EFS, it's a story without a happy ... MS did a great job of making strong encryption available, ... I'm just beginning to look into encrypted folders or entire drives and ... though it would be a good idea to re-export certificates. ...
      (microsoft.public.windowsxp.general)
    • Re: Cannot add accounts to EFS, cannot create a recovery agent
      ... You are working with EFS ... > encryption certificates not recovery certifciates. ...
      (microsoft.public.security)
    • RE: Protecting sensitive files on a Windows file server
      ... especially secure (using the file encryption is better though). ... Protecting sensitive files on a Windows file server ... recovery (which can also break EFS) and online password/data recovery ...
      (Security-Basics)
    • Quantcast