Full Disclosure: Windows File Protection Old Security Catalog Vulnerability

From: FORENSICS.ORG Security Coordinator (secalert@FORENSICS.ORG)
Date: 12/26/02

  • Next message: FORENSICS.ORG Security Coordinator: "Full Disclosure: Windows File Protection Arbitrary Certificate Chain Vulnerability"
    Date:         Thu, 26 Dec 2002 01:11:14 -1000
    From: "FORENSICS.ORG Security Coordinator" <secalert@FORENSICS.ORG>
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    ============================================================================
    ==
    ____________________________________________________________________________
    __
    SECURITY ALERT

    Windows File Protection Old Security Catalog Vulnerability

    December 26, 2002 [Full Disclosure, secure@microsoft.com and others]
    August 26, 2002 [Private Disclosure, Microsoft Press and others]

    Jason Coombs <jasonc@science.org>
    http://www.science.org/jasonc

    FORENSICS.ORG Security Coordinator <secalert@forensics.org>
    http://www.forensics.org/secalert
    ____________________________________________________________________________
    __
    Abstract

    Old Security Catalogs (.CAT files) containing valid digital signatures are
    left in place under %WinDir%\System32\CatRoot when new files and their
    associated Security Catalogs aredeployed. Windows uses its
    CryptCATAdminCalcHashFromFileHandle API function (found in mscat32.dll under
    Windows 2000 and in wintrust.dll under Windows XP/.NET Server) to compute a
    file's SIP hash code (see below) and then its
    CryptCATAdminEnumCatalogFromHash API function to automatically locate the
    digitally-signed .CAT files, if any, that contain the file's SIP hash code.
    If a file's SIP hash code cannot be found inside any digitally-signed .CAT
    file and the file itself contains no digital signature (see below) then the
    file is considered to be "unsigned". Windows File Protection gives the same
    priority and preference to authentic hash codes of old binaries (and other
    protected files) as it does to authentic hash codes of newer, updated
    binaries. An attacker can therefore place old authentic files containing
    known security vulnerabilities in place of newer files from hotfixes and
    service packs and WFP will automatically trust and certify the authenticity
    of the older files. Only manual verification of full-file hashes against
    known good hashes (i.e. authentic hashes) of newer OS files will properly
    reveal the malicious replacement. A related SECURITY ALERT issued today
    "Windows File Protection Arbitrary Certificate Chain Vulnerability" explains
    that WFP is designed to trust any certificate chain rooted at any one of
    Windows' Trusted Root Certification Authorities, making it easy for an
    attacker to replace authentic OS binaries with digitally-signed malicious
    code that WFP will, by design, automatically authenticate and trust.
    ____________________________________________________________________________
    __
    Discussion

    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). To enable multiple trust authorities to certify the same
    files independently without altering the hash code computed by WHQL for its
    Windows Hardware Compatibility signature, WFP relies on a proprietary
    Subject Interface Package (SIP) [3] object file hashing mechanism that
    applies hash algorithms such as FEDERAL INFORMATION PROCESSING STANDARDS
    PUBLICATION 180-1 (SHA-1) [4] to a subset of the bits contained in any
    Portable Executable (PE) file rather than to the entire file (full-file
    hashing). In particular the "Certificates Table" data directory entry [5] in
    the executable’s IMAGE_DATA_DIRECTORY table located at the end of its PE
    header IMAGE_OPTIONAL_HEADER structure is excluded from the hashed bits by
    the SIP object file hash preprocessor module which is visible during
    debugging sessions as "WINTRUST!SIPObjectPE_". Every PE file can thus have
    digital signature(s) attached at-will in a production system without
    invalidating the file's SIP hash code, which would impact the perception of
    any code that computes a full-file hash for the purpose of identifying the
    executable portion of the PE file as authentic, trustworthy, and/or trusted
    code. WFP uses SIP hashes to avoid this impact, the variable full-file hash,
    caused by the potential to apply digital signatures directly to PE files.

    To simplify the process of code signing, so that every file need not be
    signed individually and updated signatures can be deployed at run-time (e.g.
    when certificates expire or private keys become compromised) without
    replacing files that might be in use (and thus locked for writing) Windows
    File Protection uses Security Catalogs (.CAT files) [6] that are
    digitally-signed. Each .CAT file contains a list of authentic SIP hashes of
    trusted files that Windows File Protection (via SFC.EXE and SIGVERIF.EXE as
    well as automatic protection feature) considers to be valid SIP hashes.
    Every file that, when hashed with the help of "WINTRUST!SIPObjectPE_",
    results in a SIP hash code that is contained in any .CAT file is considered
    trustworthy by Windows File Protection, even if updates to the file (based
    on filename and version) have been deployed and the newest version of the
    authentic code in fact contains a different SIP hash from the one that
    Windows File Protection encounters.

    Windows uses its CryptCATAdminCalcHashFromFileHandle API function [7] (found
    in mscat32.dll under Windows 2000 and in wintrust.dll under Windows XP/.NET
    Server) to compute a file's SIP hash code and then its
    CryptCATAdminEnumCatalogFromHash API function to automatically locate the
    digitally-signed .CAT files, if any, that contain the file's SIP hash. If a
    file's SIP hash code cannot be found inside any digitally-signed .CAT file
    and the file itself contains no digital signature then the file is
    considered to be "unsigned". Windows File Protection gives the same priority
    and preference to authentic hash codes of old binaries (and other protected
    files) as it does to authentic hash codes of newer, updated binaries.

    An attacker can therefore place old authentic files containing known
    security vulnerabilities in place of newer files from hotfixes and service
    packs and WFP will automatically trust and certify the authenticity of the
    older files.

    A related SECURITY ALERT issued today [8] "Windows File Protection Arbitrary
    Certificate Chain Vulnerability" explains that WFP is designed to trust any
    certificate chain rooted at any one of Windows' Trusted Root Certification
    Authorities, making it easy for an attacker to replace authentic OS binaries
    with digitally-signed malicious code that WFP will, by design, automatically
    authenticate and trust.

    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 SIP hash can
    still be found in an old Security Catalog file. 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)
    Delete the Security Catalogs (.CAT files) provided by your vendors. Produce
    your own instead, and sign them with 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

    Note the following instructions provided by Microsoft for producing Security
    Catalogs using the MakeCat utility:

    http://msdn.microsoft.com/library/en-us/security/Security/makecat.asp
    http://msdn.microsoft.com/library/en-us/security/Security/using_makecat.asp

    Note the following caveat that requires certain Root CA certificates to
    remain trusted in order to avoid breaking WFP entirely.

    Q293781 Trusted Root Certificates That Are Required By Windows 2000
    http://support.microsoft.com/support/kb/articles/293/7/81.ASP

    (Adequate Protection)
    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

    Q310791 Description of the Software Restriction Policies in Windows XP
    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

    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

    (Common Sense)
    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/defa
    ult.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 let
    mutually-exclusive Security Catalog files exist in production systems simply
    because it works, somewhat, today, when nobody tampers with a Windows box on
    purpose.

    Shipping a hotfix or service pack with a new Security Catalog file without a
    mechanism to remove the out-of-date .CAT file(s) when the new ones are
    installed defeats a core purpose of Windows File Protection entirely:
    simplifying the process of distributing authentic hashes. Even Windows File
    Protection is unable to determine which of the SIP hashes is the
    most-current "authentic hash" of a given file. A redesign of this whole
    process is necessary, with enhancements to the Security Catalog file format.
    This author recommends inclusion of full-file hashes and filenames, file
    sizes, and file version numbers accompanying each and every authentic SIP
    hash so that end-users can, if they wish, utilize standard full-file hashing
    tools on a platform of their choice to verify the authenticity of the code
    they plan to deploy (and trust) to a production Windows box.

    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.
    ____________________________________________________________________________
    __
    Responsible Disclosure

    The Internet Draft known as draft-christey-wysopal-vuln-disclosure-00.txt
    formerly located at the following URL has expired and has been removed from
    publication:

    http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0
    0.txt

    Neither its authors nor any other party chose to advance a responsible
    disclosure standard through any IETF working group due to lack of interest.
    Therefore the following observations take priority as de facto "best
    practices" for information security and encryption research and responsible
    communication of security- and cryptography-related vulnerability findings:

    A. Full disclosure made directly to those who care enough about security to
    read security alert and advisory documents like this one is an effective way
    to communicate vulnerability details to those who most urgently need them
    and who are most likely to act upon them.

    B. There are always mitigating factors; and there may be imperfections in
    this author's forensic analysis of the information security vulnerability
    described in this communication due to time constraints and the need to
    disseminate the information that resulted from the author's information
    security and encryption research in a timely manner so that it can be
    peer-reviewed, confirmed widely through experiments conducted independently
    by other researchers, and custom-tailored to the needs and circumstances of
    those who are affected by the discovery. This author relies on the
    information security community at large to identify and document every
    permutation of legitimate mitigating factors.

    C. THE MOST IMPORTANT MITIGATING FACTOR IS ALWAYS AN INFORMED POPULATION
    THAT IS READY, WILLING, AND ABLE TO ACT WHEN ACTION IS REQUIRED TO ENSURE
    THE SECURITY AND INTEGRITY OF INFORMATION SYSTEMS AND PROTECT STAKE-HOLDERS
    WHO WOULD OTHERWISE BE BOTH AT-RISK AND UNINFORMED; IT IS IRRESPONSIBLE FOR
    A SECURITY RESEARCHER TO TRUST SOMEBODY ELSE TO DISSEMINATE IMPORTANT
    INFORMATION ABOUT NEW VULNERABILITIES AND IT IS FURTHER IRRESPONSIBLE FOR A
    PERSON WHO KNOWS OF A SECURITY VULNERABILITY TO KEEP IT SECRET FOR A
    PROLONGED PERIOD OF TIME IN THE IRRATIONAL AND NARCISSISTIC HOPE THAT NOBODY
    ELSE IS SMART ENOUGH TO FIND THE SAME VULNERABILITY.

    D. A small, highly-skilled and diligent distributed group of
    self-coordinating, self-organizing infosec experts who know each other and
    communicate freely is far more capable of responding to security incidents
    and moving forward any and all preventative measures necessary to minimize
    the security risk and imminent dangers of any infosec threat than are dozens
    of people and organizations compromised by politics and fear. To ensure
    continued high-quality, timely, and accurate vulnerability disclosure
    requires peer-reviewed communication free from restrictive and oppressive
    forces. Those who pose a threat to information security have this freedom to
    communicate because they take it or they make it even though it requires
    them to take personal risk. For information security professionals and the
    United States Government to deny themselves, their employees, and citizens
    this same freedom as a defense against attack is not only counter-productive
    it is also insane.

    E. The Digital Millennium Copyright Act (DMCA) makes it a crime in the
    United States (including Hawaii, Alaska, the U.S. Virgin Islands, Guam, and
    so forth) to circumvent computer security devices and algorithms that have
    the effect of protecting copyrighted works from unauthorized access,
    copying, modification, tampering, or reverse engineering unless there is a
    legitimate information security research purpose and the researcher's
    methodology meets certain requirements. If this author was, or henceforth
    is, physically present in a jurisdiction regulated by the DMCA when any copy
    of this communication was/is authored, or any portion of its communicated
    information security and/or encryption research was/is physically conducted
    by this author, this author hereby invokes the information security
    exemptions contained in the DMCA section 1201 and other sections,
    subsections, and paragraphs. The information security analysis performed by
    the author of this communication was conducted on equipment owned by the
    author or to which the author was granted authorized access. Each
    copyrighted work relied upon by the author while performing information
    security testing in connection with this communication was duly licensed to
    the author, the author's employer, and/or the entity who authorized the
    author to conduct information security and/or encryption research using
    same, to the best of the author's knowledge. The author hereby disclaims any
    and all liability, both civil and criminal, for benefits the author received
    from copyright violations potentially committed by others and the author
    further asserts freedom from criminal prosecution as an individual by virtue
    of the fact that author may have been acting in the capacity of employee,
    board member, or other representative of (an) employer(s) rather than acting
    in the capacity of individual when the author prepared this communication
    for distribution and conducted the aforementioned information security
    analysis, penetration, circumvention, reverse engineering, and/or encryption
    research.

    F. The DMCA section 1201 "Circumvention of copyright protection systems"
    also includes provisions for "PERMISSIBLE ACTS OF ENCRYPTION RESEARCH".
    There should be no concern on the part of any security researcher or
    cryptographer that communicating the results of an ethical information
    security analysis might result in arrest and prosecution for violation of
    the DMCA or other laws. THE DMCA DOES NOT TRUMP THE FIRST AMENDMENT. The
    author of this document hereby declares this communication to be protected
    speech as defined by prevailing Constitutional law interpretation of
    Amendment I of the United States Constitution; this speech is protected
    because of its political nature, because the author was/is forced by the
    existence of laws and the existence of irrational legal- and/or
    peer-pressure to fear prosecution or hardship resulting from this
    communication, because it represents the author's exercise of a freedom to
    assemble insofar as this communication is a call for an assembly of the
    author's peers for the purpose of analysis of the aforementioned security
    vulnerability, an assembly that may in fact occur in meatspace as well as
    cyberspace, and because it petitions the U.S. Government to relieve the
    present atmosphere of uncertainty it has created and/or allowed to be
    created with respect to the freedom of information security researchers to
    carry out unauthorized penetrations and circumventions of information
    security, copyright, and/or digital access control systems whenever the
    circumventions or access control penetrations occur without explicit
    permission from every copyright-holder, patent-holder, or other interested
    party whose rights and reasonable expectations of law enforcement protection
    might have been violated or infringed. The U.S. Government portends in the
    language of its legislation that a person must not be criminally liable for
    penetration testing her own door lock, but fails to distinguish between the
    act as a protected exemption that violates no law and subjects the owner of
    the door (and of the lock) to no possible civil or criminal liability, and
    the subsequent detailed communication of the act inclusive of instructions
    that are executable by a digital machine that enable other owners of doors
    (and locks) of a similar design to benefit from this security and/or
    cryptography research. Therefore, while this author is certain of impunity
    in all U.S. civil and criminal courts for information security research and
    encryption research actions taken by this author prior to this
    communication, this author has reason to fear that the content of this
    communication, should it be deemed to be sufficiently-detailed so as to be
    usable as a tool of digital system penetration and/or circumvention, could
    create devastating legal problems for this author sufficient to destroy the
    rest of this author's life and significantly damage the lives of this
    author's dependents. This author participates in the action of authorship
    and takes credit for this communication openly in spite of the extreme risk
    it may represent, confident that unjust abusive prosecution, violations of
    this author's various Constitutional rights, and abusive civil lawsuits that
    are criminal acts on behalf of the plaintiff in many jurisdictions, and
    which may in fact be criminal acts in the jurisdiction local to this author,
    will not be tolerated by a just society.

    G. With respect to registered Trademarks and copyrighted materials
    referenced or contained wholly in this communication the author claims fair
    use under Title 17 of United States Code with respect to alleged copyright
    infringement; and the author claims the privilege of media communication
    made in the public interest (freedom of the press) with respect to alleged
    violations of United States Federal law, State and municipal laws, and/or
    international Treaties that seek to regulate this communication or control
    subsequent access to it.

    H. Like an IETF Working Group or an open source or free software/GNU
    development effort, anyone who wishes to do so and who has something of
    value to contribute can contact infosec peers and solicit the forensic
    analysis help of any other security coordinator, infosec, or forensics
    expert without fear of prosecution for criminal conspiracy. In practice,
    contacting a vendor expecting forensic analysis assistance is futile;
    vendors will take a new vulnerability report and conduct their own forensic
    analysis but won't reveal additional aspects of a vulnerability to you
    because you are untrustworthy. The vendor has no incentive to spread
    vulnerability information and you have no "need to know" more than the
    vendor chooses to tell you about the scope of the vulnerability you
    discovered. Entrusting vendors with exclusive possession of vulnerability
    details is counterproductive to the desired end-result of secure information
    systems and properly hardened security policies; the analysis capabilities
    of security researchers who are not restricted by employment contracts,
    confidentiality agreements, and other impairments are superior in every
    respect and in every instance thus far examined by this author.

    I. This entire communication is Copyright (C) 2002-9999 by its author and/or
    the author's employer(s), renewed annually through the creation of derived
    works and potential copyright registration with the Library of Congress, and
    all rights are reserved. You are hereby granted a limited right to access
    this communication and distribute copies of this communication for the
    limited purposes of information security, encryption research, or fair use
    reproduction/citation. All other reproduction and access rights are reserved
    by the Copyright holder.

    J. Notice is hereby served that patent rights may exist benefiting the
    author and/or the author's employer(s) in any or all work, methods, and
    discoveries communicated herein. Should such patent rights ever be claimed
    by a third-party in any jurisdiction covered by U.S. Federal law or
    international treaty to which the United States is a party, author and/or
    author's employer hereby claim right of priority. Failure to file an
    application for patent within the statutory window of opportunity for
    exercising a right of priority shall in no way diminish the author's right
    to file, or cause to be filed, a Statutory Invention Registration (SIR)
    patent with the United States Patent and Trademark Office (USPTO); the
    potential prosecution of which can be inferred by public distribution of
    this communication and this notice. Any patentable matter, method, process,
    algorithm, or other intellectual property deserving of patent protection
    expressed in this communication is now prior art, subject to the
    aforementioned right of priority and right to prosecute application for SIR.
    ____________________________________________________________________________
    __
    References

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

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

    [3] Subject Interface Package (SIP) Functions and documentation
        CryptSIPAddProvider, CryptSIPRemoveProvider, SIP_ADD_NEWPROVIDER

    http://msdn.microsoft.com/library/en-us/security/security/cryptography_funct
    ions.asp

    [4] Secure Hash Standard (SHA-1)
        http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt

    [5] Microsoft Portable Executable and Common Object File Format
    Specification v6.0
        Appendix: Calculating Image Message Digests
        Fields Not To Include In Digests
        http://www.microsoft.com/hwdev/hardware/PECOFF.asp

    [6] Security Catalog (.CAT File) MakeCat Utility
        http://msdn.microsoft.com/library/en-us/security/Security/makecat.asp

    http://msdn.microsoft.com/library/en-us/security/Security/using_makecat.asp

    [7] CryptCATAdminCalcHashFromFileHandle API Function

    http://msdn.microsoft.com/library/en-us/security/Security/cryptcatadmincalch
    ashfromfilehandle.asp

    [8] Windows File Protection Arbitrary Certificate Chain Vulnerability

    http://www.forensics.org/secalert/WFP_Arbitrary_Certificate_Chain_Vulnerabil
    ity.txt
    ____________________________________________________________________________
    __

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

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    Delivery co-sponsored by Prometric - More than testing, learning.
    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    http://www.prometric.com

    Prometric, part of The Thomson Corporation, is the leader in
    technology-enabled testing and assessment services for information
    technology certification, academic admissions, professional licensure and
    certifications, computer-based driver's licensing, and corporate testing.

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo



    Relevant Pages