[NT] Windows File Protection Arbitrary Certificate Chain Vulnerability

From: support@securiteam.com
Date: 12/26/02

  • Next message: support@securiteam.com: "[UNIX] Multiple Vulnerabilities in KDE (command shell)" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 26 Dec 2002 23:46:56 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Beyond Security would like to welcome Tiscali World Online
    to our service provider team.
    For more info on their service offering IP-Secure,
    please visit http://www.worldonline.co.za/services/work_ip.asp
    - - - - - - - - -

      Windows File Protection Arbitrary Certificate Chain Vulnerability
    ------------------------------------------------------------------------

    SUMMARY

    Windows File Protection will trust any digital signature whose certificate
    chain is rooted at any one of the Trusted Root Certification Authorities.
    Versions of Windows (and Internet Explorer) ship with various
    preconfigured Trusted Root Certification Authorities that are
    automatically trusted not just as potential Root CA's for SSL certificate
    chains but also as valid Root CA's for code signing certificates.

    Many Root CA's issue SSL certificates that have improper Key Usage and
    Enhanced Key Usage Object Identifiers (OIDs), and missing or invalid Basic
    Constraints, making many SSL certificates identical in function to more
    privileged certificates.

    In the case of missing Basic Constraints, Windows is known to trust a
    certificate as though it were a legitimate Intermediate Certification
    Authority even with recent patch (Q329115) applied to resolve MS02-050
    "Certificate Validation Flaw Could Enable Identity Spoofing" where the
    Basic Constraints field, if present, was ignored completely.

    A related SECURITY ALERT issued today "Windows File Protection Old
    Security Catalog Vulnerability" explains that WFP is designed to trust
    equally every version of published code that it has ever trusted by way of
    its installed Security Catalogs (.CAT files), making it easy for an
    attacker to replace new code that contains bug fixes and patches for
    security vulnerabilities with old code that is known to be vulnerable to
    various exploits.

    DETAILS

    Windows File Protection (a.k.a. Windows Driver Signing) [1] verifies
    digital signatures applied to operating system binaries, device drivers,
    and other OS files, as well as files published by third-parties [2] that
    are certified by Windows Hardware Quality Labs (WHQL) (a.k.a. Microsoft
    Windows Hardware Compatibility). The vulnerability disclosed in this
    communication is simply that any digitally-signed replacement file of
    malicious origin will take priority over any authentic WFP/WHQL-signed
    file.

    Anyone can now obtain anonymous code signing and SSL certificates
    automatically and free of charge from the following CA:

    GeoTrust Inc. <http://www.freessl.com> http://www.freessl.com

    whose Root Certificate is:
    CN = UTN-USERFirst-Network Applications
    OU = http://www.usertrust.com
    O = The USERTRUST Network
    L = Salt Lake City
    S = UT
    C = US

    And use this anonymous freessl.com/usertrust.com/geotrust.com certificate
    to digitally sign malicious code (e.g. using SIGNCODE.EXE) that Windows
    File Protection (WFP) will automatically trust by virtue of the fact that
    the certificate's Root CA (usertrust.com) is one of the Root Certificates
    trusted by default in standard Windows/IE installations. It should be
    noted, however, that every Root CA that issues certificates that can be
    used for code signing (all CA's of which this author is aware do sell code
    signing certificates in addition to SSL certificates) enables any attacker
    in possession of a valid code signing certificate signed by any Root CA to
    apply a digital signature to malicious code and deploy it without
    detection to any Windows box that relies on WFP for malicious code/Trojan
    detection.

    A related SECURITY ALERT issued today [3] "Windows File Protection Old
    Security Catalog Vulnerability" explains that WFP is designed to trust
    equally every version of published code that it has ever trusted by way of
    its installed Security Catalogs (.CAT files), making it easy for an
    attacker to replace new code that contains bug fixes and patches for
    security vulnerabilities with old code that is known to be vulnerable to
    various exploits.

    Therefore, only manual forensic verification of full-file hashes with
    comparison against a list of known good hashes (i.e. authentic hashes)
    will properly reveal the malicious replacement when an attacker applies a
    verifiable digital signature to an old Windows binary whose hash code can
    still be found in an old Security Catalog file, or when an attacker is
    able to place malicious code that contains a digital signature embedded in
    the PE file format "Certificates Table" data directory entry [4]. The
    following "Action Required" is thus inadequate to defend against misplaced
    trust when the attack uses digitally-signed malicious code or
    digitally-signed old, but authentic, vulnerable code published (and
    digitally-signed) in the past by a legitimate software vendor.

    Action Required:
    Current Best Practice (Jason's)
    Delete your default Root CA Certificates. All of them.

    Ignore Windows File Protection. If you must use it, run SIGVERIF.EXE and
    manually examine the log file (Click the Advanced button to configure scan
    parameters and logging) to determine who the publisher is of each trusted
    file that appears to have a valid digital signature. Be aware that it's
    possible for an attacker to acquire a certificate from a trusted Root CA
    or Intermediate CA that has the same common name (CN) as an authentic
    Microsoft certificate, such as "Microsoft Windows 2000 Publisher" in which
    case your analysis of the log file created by SIGVERIF.EXE will be useless
    unless you also know the filename of the Security Catalog file inside
    which each file's hash code should be found. The only way to get this
    information easily is to compare SIGVERIF.EXE log files between Windows
    boxes, because the Security Catalog files themselves do not contain
    filenames of the files they are meant to authenticate, .CAT files contain
    only hashes.

    Script the verification of trust for your executable code files using
    CHKTRUST.EXE instead of WFP, since CHKTRUST.EXE relies on the WinTrust API
    instead of WFP. WinTrust will only trust software publisher certificates
    (SPCs) that are selected explicitly and configured for automatic trust by
    way of the following Registry keys:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
    Providers\Software Publishing\Trust Database

    HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
    Providers\Software Publishing\Trust Database

    Produce your own digital signatures instead using a code signing
    certificate that you issued to yourself from your own Trusted Root
    Certification Authority certificate store. Details for producing your own
    Security Catalogs and managing your own Public Key Infrastructure (PKI)
    for the purpose of preventing unwanted code execution will be available at
    the following URL which is controlled by this author:
    <http://www.countermand.org> http://www.countermand.org

    Adequate Protection (Jason's)
    First, upgrade to Windows XP or Windows .NET Server 2003 from whatever
    prehistoric version of Windows you're using now so that you can enable
    Software Restriction Policies per the following instructions. Add a new
    hash code rule for every system binary and other executable file you wish
    to allow to run on your box; this establishes a fixed trust policy based
    on the authentic hashes of code that you choose to trust rather than a
    variable trust policy based on anything that Windows thinks is legitimate
    based on the appearance that it has a valid digital signature. This
    fixed/static trust policy is superior to the dynamic one provided through
    the use of digital signatures, because whether or not something is
    digitally-signed or meant to be trusted (today, as opposed to in the past)
    is determined automatically by Windows, inclusive of its known flaws in
    analyzing certificate chains, when signatures (and PKI) are used -- these
    fancy cryptographic schemes are not necessary in order to countermand
    execution of unwanted code, and they actually interfere with your ability
    to prevent unwanted code when there are problems with the implementation
    or design of these variable trust-based PKI systems:

    Q324036 HOW TO: Use Software Restriction Policies in the Windows .NET
    Server Family
     <http://support.microsoft.com/support/kb/articles/324/0/36.ASP>
    http://support.microsoft.com/support/kb/articles/324/0/36.ASP

    Q310791 Description of the Software Restriction Policies in Windows XP
    <http://support.microsoft.com/default.aspx?scid=KB;en-us;310791>
    http://support.microsoft.com/default.aspx?scid=KB;en-us;310791

    And then... (it will take you a long time to explicitly authorize each
    executable module and DLL, which is why deploying your own Security
    Catalogs with your own PKI-based Root CA and code signing certificate is
    the Best Practice today.)

    Disable Windows File Protection completely by deleting all Root CA
    certificates from every trusted certificate store per the following
    instructions, which you must apply in reverse (that is, the following
    Knowledge Base Article shows you how to recover from a failed Windows File
    Protection condition due to missing Root Certificates -- if WFP is already
    working, kill it by following these instructions in reverse):

    Q296241 Windows File Protection May Not Start
    <http://support.microsoft.com/default.aspx?scid=kb;EN-US;296241>
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;296241

    Note that you should NOT follow the instructions found in Q293819, as they
    remove only the current user's Root CA certificates rather than every
    certificate deployed to your box:

    Q293819 How to Remove a Root Certificate from the Trusted Root Store
    <http://support.microsoft.com/default.aspx?scid=kb;EN-US;293819>
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;293819

    Common Sense (Jason's)
    Remember to make a record of the authentic hashes of the files you've
    chosen to trust explicitly so that you can audit your system later and
    compare your hashes against those of a peer or another Windows box that
    you also control. Command-line utilities to compute full-file hashes are
    available on every OS platform, and you can build your own easily with
    Microsoft .NET per the following article written by this author and
    published in MSDN Magazine:

    Tamper-Resistant Apps - Cryptographic Hash Algorithms Let You Detect
    Malicious Code in ASP.NET by Jason Coombs
    <http://www.msdn.microsoft.com/msdnmag/issues/02/09/ASPNETHashAlgorithms/default.aspx> http://www.msdn.microsoft.com/msdnmag/issues/02/09/ASPNETHashAlgorithms/default.aspx

    Preventive per Contra Response to Vendor Response:
    The following Bellum Omnium Contra Omnes per Contra response is offered in
    advance to the anticipated vendor response to this SECURITY ALERT as a
    preventive measure in the interest of diminishing the Mean Time Before Fix
    (MTBF). Yes, this behavior is by design; placing documentation to this
    effect in the manual and crying RTFM is foul. There is no reason to
    automatically trust any Root CA when it comes to code signing. Windows
    File Protection should never have been designed to trust digital
    signatures on software based on certificate chains, WFP should trust only
    specific certificates the way that WinTrust operates.

    When the vendor redesigns this feature, it would be sensible to also
    deploy a better system for managing certificates and trust relationships
    with End Entities, Root CA's, and any site that needs SSL for the purpose
    of encryption but doesn't care about the authentication features that it
    never provided properly in the first place for users of Windows. There is
    a large demand, and a legitimate demand, for anonymous SSL certificates
    like those distributed by <http://freessl.com/geotrust.com/usertrust.com>
    http://freessl.com/geotrust.com/usertrust.com -- however, bad code
    deployed in the wild today like Windows File Protection, and flawed
    security policies that rely on such bad code, make the availability of
    free, anonymous SSL certificates/code signing certificates an urgent and
    immediate information security threat. Rather than shut down Certification
    Authorities with bad security practices, this author suggests that vendors
    who produce bad code should issue patches immediately to remediate the
    vulnerability from the source rather than attempt to prune competition for
    security-related products and services from the digital marketplace.

    Certificates should be managed by each node/end-user in a manner similar
    to the way that cookies are now managed in Internet Explorer. Each
    end-user/administrator of each node on the network should be able to
    easily define a security policy and the default setting should be to block
    and deny all. Each capability possible with respect to each certificate
    (SSL/code signing/e-mail signatures, etc.) should be a separate security
    policy setting that the end-user or an authorized administrator must
    explicitly allow on a per-certificate basis.

    This author will gladly code these revisions for vendor if vendor will
    release the relevant source code under the terms of an open source
    license.

    ADDITIONAL INFORMATION

    References:

    [1] Driver Signing for Windows
    <http://www.microsoft.com/hwdev/driver/digitsign.asp>
    http://www.microsoft.com/hwdev/driver/digitsign.asp

    [2] Driver Signing / File Protection
    <http://www.microsoft.com/hwdev/driver/drvsign.asp>
    http://www.microsoft.com/hwdev/driver/drvsign.asp

    [3] Windows File Protection Old Security Catalog Vulnerability
    <http://www.forensics.org/secalert/WFP_Old_Security_Catalog_Vulnerability.txt> http://www.forensics.org/secalert/WFP_Old_Security_Catalog_Vulnerability.txt

    [4] Microsoft Portable Executable and Common Object File Format
    Specification v6.0 - Appendix: Calculating Image Message Digests
    <http://www.microsoft.com/hwdev/hardware/PECOFF.asp>
    http://www.microsoft.com/hwdev/hardware/PECOFF.asp

    The information has been provided by <mailto:jasonc@science.org> Jason
    Coombs.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.