============================================================================ == ____________________________________________________________________________ __ SECURITY ALERT Windows File Protection Arbitrary Certificate Chain Vulnerability December 26, 2002 [Full Disclosure, secureat_private and others] December 24, 2002 [Private Disclosure] Jason Coombs <jasoncat_private> http://www.science.org/jasonc FORENSICS.ORG Security Coordinator <secalertat_private> http://www.forensics.org/secalert ____________________________________________________________________________ __ Abstract 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. ____________________________________________________________________________ __ 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). 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 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) 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 (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 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 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. ____________________________________________________________________________ __ 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] Windows File Protection Old Security Catalog Vulnerability 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 ____________________________________________________________________________ __ ============================================================================ ==
This archive was generated by hypermail 2b30 : Thu Dec 26 2002 - 16:46:13 PST