--- key: "icdp-case-flame-2012" title: "Flame: MD5 certificate forgery" url: "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/flame-md5-certificate-forgery/" api: "https://softwaresecurity.com/api/v1/articles/icdp-case-flame-2012.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Case study" identifiers: ["CWE-328","CWE-295","A04:2025","A08:2025","V11.4.1","V11.4.3"] tags: ["PKI and certificates","Historical cryptographic attacks","Signing and software updates"] stages: ["release","operate"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # Flame: MD5 certificate forgery Follow how a weak digest and an overpowered certificate trust path enabled forged code-signing authority, without equating the event with RSA key theft. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/key-management-pki/flame-md5-certificate-forgery/ ## In short Flame (2012) used an MD5 chosen-prefix collision to turn a Terminal Server licensing certificate into one that Windows accepted for code signing; no private key was stolen. Today, reject MD5 and SHA-1 certificate signatures in every verifier, give each CA and intermediate only the purposes it needs, check extended key usage when verifying code, and know how a distrust decision reaches every verifier. Unpredictable certificate serial numbers also make this kind of substitution impractical. - A collision lets one CA signature cover two different certificates; no CA key is needed. - The licensing chain should never have been able to grant code-signing authority. - Public CAs must put at least 64 random bits in each serial number, which makes chosen-prefix substitution impractical. - Since 15 September 2026, publicly trusted CAs may not use SHA-1 anywhere in certificates or CRLs. - Responding means distrusting the path in every verifier, not only fixing future issuance. ## Incident at a glance - Date: 2012-05-28 to 2012-06-03 - Category: Cryptographic weakness - Organization: Microsoft - Impact: The Flame espionage malware was signed with a certificate that chained to a Microsoft root, obtained through an MD5 chosen-prefix collision against the Terminal Server Licensing Service, so its components appeared to be signed by Microsoft. - How it was found: Kaspersky Lab, CrySyS Lab and Iran’s national CERT announced Flame on 28 May 2012; Microsoft then traced the signing certificates to its licensing CA. ### Timeline 1. 2008-12-30: Researchers show a rogue CA certificate built with an MD5 chosen-prefix collision at the 25th Chaos Communication Congress. 2. 2010-02: According to CWI’s June 2012 analysis, the Flame collision attack on the licensing CA was carried out around this time. 3. 2012-05-28: Kaspersky Lab, CrySyS Lab and Iran’s national CERT announce the Flame malware. 4. 2012-06-03: Microsoft releases Security Advisory 2718704 and an update that blocks the unauthorized certificates. 5. 2012-06-06: Microsoft explains the MD5 collision attack and the licensing certificate path. 6. 2012-06-07: CWI reports that Flame used a previously unknown variant of the chosen-prefix collision attack. ## Verify it 1. Run `openssl x509 -in cert.pem -noout -text` on each certificate in your code-signing and internal chains and confirm no MD5 or SHA-1 signature. 2. Run `openssl x509 -in cert.pem -noout -ext extendedKeyUsage` and confirm each intermediate carries only the purposes it needs. 3. Present a valid certificate with the wrong purpose to your update verifier and confirm it is rejected. 4. Distrust a test intermediate and measure how long every verifier takes to reject it. ## What you will learn - Explain certificate substitution without private-key recovery. - Separate the incident’s algorithm and trust-purpose failures. - Design verifier tests for distrust and certificate purpose. Audience: Engineers who run internal CAs or code-signing pipelines, and reviewers who assess certificate trust and purpose. Before you start: - Explain what a certificate signature authenticates and why its hash construction matters. Time: About 19 minutes: 5 to read and 14 for the exercise ## The forged artifact crossed a trust-purpose boundary In June 2012 Microsoft reported that Flame components carried signatures that could appear to originate from Microsoft. Its investigation identified a path through the Terminal Server licensing certificate infrastructure and an MD5 collision attack. The critical question was not merely whether a signature calculation returned true; it was why a licensing-related chain could confer authority over executable code. In a collision-based certificate substitution, two different to-be-signed certificate byte strings share a digest. A CA signature associated with the digest of an acceptable request can then validate a different certificate carrying attacker-useful meaning, if the complete certificate construction and verifier rules permit it. This does not require factoring the CA’s RSA modulus or stealing its signing key. Microsoft’s June 6 technical explanation makes a useful distinction: for Windows Vista and later, the attackers needed the collision to produce a certificate accepted for code signing; on older systems a path existed without that collision. Removing this distinction would incorrectly credit all trust failure to one mathematical weakness. The trust-purpose behavior and the digest weakness were interacting parts of the incident. ## Predictable issuance and certificate interpretation mattered A chosen-prefix collision is not a general ability to edit any signed certificate afterward. The attacker needs control sufficient to construct two meaningful colliding inputs and arrange for the useful signature. Certificate fields, exact encoding, extensions, and issuance behavior constrain what can be substituted. The public research and vendor analysis support the incident mechanism; a short case study cannot infer every undisclosed operational step. MD5 was already known to be unsuitable for collision-resistant signatures before Flame’s disclosure. The 2008 rogue-CA demonstration and the 2012 incident are separate events. A prior successful laboratory demonstration gives reason to retire an algorithm, but it is not evidence that the same artifact or identical collision technique was reused in every later attack. The hash-collision guide at /domains/identity-crypto/key-management-pki/hash-collisions-and-signatures/ explains what a chosen-prefix collision can and cannot do. A chain ending at a familiar root is only one validation input. Verifiers must also enforce certificate purpose, constraints, algorithm policy, and the actual signed object. If a root or intermediate is accepted for more purposes than intended, a weakness in a low-value issuance service can inherit the authority of a higher-value signing workflow. ## Contain the authority and invalidate the vulnerable path Microsoft invalidated certificates from the involved authorities through Security Advisory 2718704. This addressed trust in the affected path rather than merely changing a leaf certificate on a web server. For an analogous system, find every verifier that accepts the intermediate, including offline or embedded consumers, and determine how distrust updates reach them. Replacing MD5 for future issuance closes only the new-issuance path. Existing forged or overpowered credentials may remain accepted until verifiers receive a trust-policy change. Similarly, adding an application warning without changing acceptance leaves automated update consumers exposed. A complete response couples algorithm policy, constrained purposes, revocation or distrust distribution, and validation of the delivered update. Overly broad emergency distrust can break legitimate services that depended on the same hierarchy. Map those dependencies and provide replacement credentials through a separately trusted channel. The tradeoff is availability during remediation, not a reason to leave an attacker-controlled signing authority accepted indefinitely. ## What should you do today? - Configure internal CAs and verifiers to reject MD5 and SHA-1 signatures, and inventory any internal PKI that still issues them. - Restrict each CA and intermediate by extended key usage and name constraints, so a licensing or device CA cannot issue code-signing certificates. - When verifying code or updates, require the code-signing extended key usage and a chain to the specific root you expect; /domains/supply-chain/provenance/artifact-signature-policy/ applies this to release verification. - Generate certificate serial numbers with at least 64 bits from a CSPRNG, as the CA/Browser Forum requires of public CAs. - Rehearse distrust: how fast can you remove an intermediate from every verifier, including offline and embedded ones? ## Separate observed artifacts from reconstructed explanations The toy exercise supplies a digest collision as an assumption; it does not generate MD5 collisions or reproduce Flame. Its purpose is to show how a valid mathematical signature can accompany the wrong authority. Historical claims here are limited to the vendor’s June 2012 accounts and the collision researchers’ published analysis. For a verifier change, use an allowed signature chain as the positive case, a chain through the distrusted licensing authority as the negative case, and an otherwise valid chain with the wrong purpose as a separate boundary case. Record algorithm rejection separately from purpose or chain rejection. A generic invalid-signature error can conceal which boundary is still missing. ## Guided practice A toy update verifier trusts a root for two certificate purposes. Review the supplied issuance and verification record. ### Supplied material ```text Certificate A: purpose=licensing, publicKey=L, digest=d7. Certificate B: purpose=code-signing, publicKey=ATTACKER, digest=d7. CA signature S verifies for digest d7. Digest equality is SUPPLIED. Old policy: any chain to Root R may sign updates. Proposed policy: modern digest required; licensing intermediate distrusted for updates; code-signing purpose required. ``` ### 1. Trace the substitution State why S can verify B under this simplified digest-only signature abstraction. Worked answer: Both supplied byte strings map to d7, so digest verification alone cannot distinguish them. This does not imply the CA private key was recovered. ### 2. Evaluate each repair Assess only changing future CA issuance to a modern hash. Worked answer: It prevents this weak-hash route for newly issued objects but leaves existing B acceptable if old digest and chain policies remain enabled. ### 3. Write acceptance decisions Evaluate a modern legitimate code-signing chain, B through the old intermediate, and a modern licensing certificate. Worked answer: The legitimate code-signing chain passes; B fails algorithm and trust-path policy; the modern licensing certificate fails purpose policy even with a valid signature. Deliverable: A trust-path decision table separating mathematical signature validity, algorithm permission, and signing purpose. Scope: Certificate fields and digest d7 are invented teaching data. No MD5 collision generation or actual certificate validation is performed. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [Microsoft: Flame malware collision attack explained (June 6, 2012)](https://www.microsoft.com/en-us/msrc/blog/2012/06/flame-malware-collision-attack-explained/) - [Microsoft: Security Advisory 2718704 announcement](https://www.microsoft.com/en-us/msrc/blog/2012/06/microsoft-releases-security-advisory-2718704). 3 June 2012. - [CWI: Analysis of the Flame collision variant](https://www.cwi.nl/en/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware/). 7 June 2012. - [CA/Browser Forum Baseline Requirements (serial number entropy and SHA-1 sunset)](https://github.com/cabforum/servercert/blob/main/docs/BR.md). Version 2.3.1 (4 October 2026). - [Stevens, Sotirov et al.: MD5 considered harmful today, creating a rogue CA certificate](https://marc-stevens.nl/research/hashclash/rogue-ca/). 30 December 2008.