Re: Relative Security Provided by Cached Domain Credentials?

From: Nicolas RUFF (lists) (ruff.lists_at_edelweb.fr)
Date: 05/12/04

  • Next message: Corinna: "RE: Virus is getting domain account listing" 
    Date: Wed, 12 May 2004 11:35:33 +0200
To: focus-ms@securityfocus.com

            Hi,

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

    When non-hardware storage is used, and if I remember well, the private key(s) can be found in the
    following directory :
    C:\Documents and Settings\<username>\Application Data\Microsoft\Crypto

    However the following directory is also somewhat involved in the process of private key retrieval :
    C:\Documents and Settings\<username>\Application Data\Microsoft\Protect
    See the CREDHIST file ? Looks like a CREDentials HISTory file : if an administrator resets your
    Windows password because you lost the old one, you do not want to lose all your private keys ...

    I will not go deep into details, because you will find all you need on this site :
    http://www.beginningtoseethelight.org/efsrecovery/index.php

    Public and/or private keys stored on a workstation can be accessed through various methods, even if
    the user does not *explicitly* export them :

    - Stolen laptop or other physical access to the workstation : you have direct access to the hard
    drive (EFS was mainly designed to address the risk of stolen laptops, but IMHO this is far from a
    perfect solution).

    - Administrative shares : if you can guess the login/password pair for a local administrative
    account, you can access all local drives from anywhere on the Internet using the default \\<IP>\C$
    share.
    * WinXP : blank passwords are not allowed to log on remotely.
    * Win2K : the password can be blank (see SANS Top 10 vulnerabilities, and the Chinese "Fluxay"
    remote hacking tool).

    - Remote Registry access : certificates are mapped into registry, and the Remote Registry service is
    started by default. You need admin rights on the target workstation, though.

    - Exploit : go get the latest DCOM/LSA/whatever exploit and copy the keys via FTP, or access the
    CryptoAPI as SYSTEM.

    - Virus/Malware : instead of targeting email adresses, credit card numbers, etc. you can target
    private keys and upload them to a "*.ru" website.

    Etc. etc.

    It is true that you cannot export private keys using the CryptoAPI, if they are marked as "non
    exportable". But remember that this flag is enforced by the API (nothing prevents the kernel from
    accessing your private keys). I am working on this for now :-)

    Conclusion : non-hardware key stores are *not* safe (but you knew this already ?).

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

    The only things an attacker need are :
    - The private key file.
    - The user password, if the above file has been stolen "offline" (encrypted with the user password).
    If you can hijack a user session, this is not required as the key remains decrypted in memory as
    long as the user is logged in.
    - An idea of the "semi-documented" file structures involved.

    * The "certificate" (=public key, signed by the trusted CA) is only used for encryption, not for
    decryption.
    * If the victim is logged in during the attack, you can access all EFS encrypted files transparently
    as the victim does, so you do not need to attack anything. But as we see this is not mandatory : you
    can still decrypt EFS files "offline".
    * If you *only* have an EFS encrypted file and a user password, you cannot decrypt the file.
    However, as shown before, getting access to the private key is not so hard on software stores.

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

    As long as users have strong, non-guessable Windows passwords ...

    This is the main problem with EFS : whole user security = robustness of a single Windows password
    (which also might be stored in weak forms, such as LM hash).

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

    Smartcards are far more secure, because even if a Trojan can sniff the PIN code, you still need
    physical access to the card to decrypt files.

    However, remember that as long as the card is in the card reader, and the user logged in, you can
    access all his EFS encrypted files transparently as he does. Don't even think of activating the
    "strong" key protection (ask for PIN code on each private key access), if you don't want to kill
    your left mouse button in one day :-)

    Regards,
    - Nicolas RUFF
    -----------------------------------
    Security Consultant
    EdelWeb (http://www.edelweb.fr/)
    Mail : nicolas.ruff@edelweb.fr
    -----------------------------------

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

  • Next message: Corinna: "RE: Virus is getting domain account listing"
    • Quantcast