Zusammenfassung

  • Das gefälschte Flame-Zertifikat führte bis zu einer Microsoft-Root, ohne dass deren privater Schlüssel entwendet worden war. Vorhersagbare Felder der Lizenzzertifikatsausgabe und eine MD5-Kollision mit gewählten Präfixen machten eine Signatur über ein legitimes Zertifikat auch für ein zweites Zertifikat gültig, dem die auf neueren Windows-Systemen abweisende kritische Erweiterung fehlte.
  • Die Bereinigung musste eine ganze Fähigkeit beenden. Microsoft stufte die frühere Lizenzierungs-Hierarchie vollständig als nicht vertrauenswürdig ein, trennte den Ersatz von gewöhnlich akzeptierten Windows-Roots, entfernte Code-Signierung, begrenzte den neuen Pfad auf Lizenzierung und beschleunigte die Verteilung von Sperrentscheidungen.

Eine gültige Kette beantwortete die falsche Frage

Im Juni 2012 stieß Microsoft auf eine Datei, deren digitale Signatur bis zu einer Microsoft-Root-Autorität verkettet werden konnte. Das wirkte wie eine Antwort auf die Frage, ob die Datei von Microsoft stamme. Tatsächlich hatte die Prüfung mehrere verschiedene Fragen zu einer einzigen zusammengezogen.

Eine Signatur besagt, dass ein Schlüssel einen bestimmten Digest signiert hat. Ein Zertifikatspfad besagt, dass ein Client eine Folge von Delegationen akzeptiert. Ob eine für Remote-Desktop-Lizenzen eingerichtete Infrastruktur damit auch Software oder ein Betriebssystem-Update autorisieren darf, ist eine weitere Frage. Diese Befugnis entsteht erst aus Ausgabeprozess, Key Usage, Extended Key Usage, kritischen Erweiterungen, Anwendungsregeln und lokalem Vertrauenszustand.

Das Security Advisory 2718704 meldete aktive Angriffe mit unautorisierten, von einer Microsoft-CA abgeleiteten Zertifikaten. Die Untersuchung führte zum Terminal Server Licensing Service. Ein Dienst für einen begrenzten Geschäftszweck verwendete einen älteren kryptografischen Algorithmus und lag in einer Hierarchie, die Zertifikate mit Code-Signaturfähigkeit ausgeben konnte.

Der Fehler war deshalb größer als „MD5 war noch aktiv“. Ein von außen erreichbarer Lizenzierungsprozess konnte eine Root erreichen, deren Name und Stellung in wesentlich folgenreicheren Prüfungen Gewicht hatten. Organisatorische Gemeinsamkeit war in technische Austauschbarkeit von Autorität übersetzt worden.

Eine Root sollte nicht lediglich als vertrauenswürdig erfasst werden. Ein brauchbares Inventar benennt jede Entscheidung, die ihre Unterketten auslösen können: Code ausführen, Server identifizieren, Geräte registrieren, Produkte aktivieren oder Updates akzeptieren. Kann ein vermeintlich niedrigriskanter Aussteller eine hochriskante Entscheidung bewirken, enthält der Vertrauensgraph eine Privilegienerweiterung.

Vorhersagbare Ausgabe als Signatur-Orakel

Die Registrierung für das Lizenzzertifikat verlangte keinen Zugang zur internen Microsoft-PKI. Der Pfad signierte mit md5RSA; Gültigkeitszeiträume waren bekannt; Seriennummern ließen sich mit hoher Wahrscheinlichkeit vorhersagen. Damit konnte ein Angreifer die erforderliche Struktur vor der legitimen Signatur berechnen.

Bei einer Kollision mit gewählten Präfixen werden zwei unterschiedliche Anfänge vorbereitet. Der erste beschreibt das scheinbar ordnungsgemäße Objekt, das der Aussteller signieren soll. Der zweite beschreibt das vom Angreifer gewünschte Zertifikat. Berechnete Fortsetzungen führen dazu, dass beide vollständigen Objekte denselben MD5-Digest besitzen. Die CA signiert den Digest der legitimen Fassung; dieselbe Signatur verifiziert auch über der anderen.

Das ist weder ein nachträgliches beliebiges Umschreiben eines vorhandenen Zertifikats noch eine Rückgewinnung des privaten Schlüssels. Der Angreifer muss vor der Ausgabe Teile der Nachricht beeinflussen, genug Felder vorhersagen und einen echten Aussteller zur Signatur bewegen. Der Lizenzierungsdienst stellte genau diese privilegierte Operation bereit.

Ein herkömmliches Bestandsverzeichnis würde Algorithmus, Registrierungsportal, Zertifikatsvorlage und Root getrennt behandeln. Flame zeigte, dass ihr Produkt geprüft werden muss. Der schwache Digest wird gefährlich, wenn der Antragsteller Struktur kontrolliert; Vorhersagbarkeit ermöglicht die Vorberechnung; die breite Root verleiht dem Ergebnis praktischen Wert.

Schon eine wirksame Trennung hätte den Pfad verändert: kollisionsresistenter Hash, unvorhersagbare Ausgabefelder, eine von normalen Clients nicht akzeptierte Root oder eine tatsächlich erzwungene Zweckbegrenzung. PKI-Sicherheit ist nicht die Anzahl vorhandener Kontrollen, sondern die verbleibende Fähigkeit ihrer Zusammenschaltung.

Die Kollision war kein Schlüsseldiebstahl

Der CWI-Kryptanalytiker Marc Stevens stellte fest, dass Flame eine damals unbekannte Variante einer Chosen-Prefix-Kollision nutzte. Es handelte sich nicht nur um die zunächst vermutete Anwendung der öffentlich bekannten Konstruktion von 2009. Frühere Forschung hatte jedoch bereits demonstriert, dass zwei verschiedene X.509-Zertifikatspräfixe so ergänzt werden können, dass sie denselben MD5-Wert erhalten.

Die Unterscheidung steuert die Abwehr. Die herangezogenen Quellen behaupten nicht, ein Microsoft-Root- oder Intermediate-Schlüssel sei extrahiert worden. Die legitime CA schützte ihren Schlüssel und führte eine normale Signaturoperation aus. Gebrochen wurde die Eindeutigkeit: Eine Genehmigung für einen Inhalt wurde zugleich zur Genehmigung eines anderen Inhalts mit anderer Wirkung.

Umgekehrt ist der Vorfall nicht deshalb harmlos, weil kein Schlüssel das Sicherheitsmodul verließ. Schlüsselverwahrung ist nur eine Grenze. Signiert eine CA angreiferbeeinflussbare Daten mit einer Funktion ohne ausreichende Kollisionsresistenz, kann die Autorität den geschützten Bereich verlassen, obwohl das Geheimnis darin bleibt.

RFC 6151 erklärte 2011, MD5 sei in Anwendungen mit erforderlicher Kollisionsresistenz, darunter digitale Signaturen, nicht mehr akzeptabel. Zugleich unterschied das Dokument diese Schwäche von HMAC-MD5. Ein Scanner, der nur die Zeichenfolge MD5 findet, erfasst daher nicht das Entscheidende: Wer formt die Nachricht, welche Eigenschaft braucht die Signatur und welche Befugnis erbt das kollidierende Objekt?

Kritisch bedeutete: unbekanntes Objekt ablehnen

Ein reguläres Zertifikat aus der Terminal-Server-Lizenzinfrastruktur enthielt einen CRL Distribution Point, Authority Information Access und eine kritische Microsoft-Hydra-Erweiterung. Dem Flame-Zertifikat fehlten die erwarteten Erweiterungen.

„Kritisch“ beschreibt im X.509-System keine redaktionelle Wichtigkeit. Es ist eine Anweisung an die auswertende Implementierung: Versteht sie die Erweiterung nicht, muss sie das Zertifikat ablehnen. RFC 5280 beschreibt außerdem, dass Key Usage und Extended Key Usage gemeinsam den zulässigen Zweck einschränken, wenn beide vorhanden sind.

Windows Vista und spätere Versionen setzten die Hydra-bezogene Ablehnung durch. Ein normales Lizenzzertifikat war daher für die beabsichtigte Code-Signatur nicht brauchbar. Laut Microsoft benötigte der Angreifer die Kollision, um ein anderes Zertifikat ohne die kritische Einschränkung zu schaffen und zugleich den signierten MD5-Wert zu bewahren. Vor Vista konnte der Angriff nach Microsofts Darstellung ohne diese Kollision funktionieren. Diese Aussage betrifft konkrete Windows-Generationen und darf nicht auf beliebige X.509-Bibliotheken übertragen werden.

Eine Erweiterung in einer Vorlage ist noch keine Kontrolle. Sie muss innerhalb der signierten Daten liegen, darf in keinem Ausgabeweg fehlen, muss wo nötig als kritisch gekennzeichnet sein und auf allen relevanten Clients nachweisbar zur Ablehnung führen. Flame überredete moderne Clients nicht, eine Regel zu ignorieren; es präsentierte ein Objekt, in dem die Regel nicht mehr vorhanden war.

Deshalb braucht die Abnahme Negativtests. Nicht nur das normale Zertifikat muss akzeptiert werden. Varianten mit fehlender, unbekannter, verschobener oder beschädigter Einschränkung müssen fehlschlagen. Der Beleg einer Zweckbindung ist das beobachtete Nein des Clients.

Die Signatur brauchte weiterhin einen Lieferweg

Microsoft erklärte, für eine Vortäuschung von Windows Update sei zusätzlich zum unautorisierten Zertifikat eine Man-in-the-Middle-Position erforderlich gewesen. Das signierte Paket musste den Update-Mechanismus erreichen. Die Quellen dokumentieren keine Übernahme der zentralen Windows-Update-Server.

Der Angriff kombinierte begrenzte Fähigkeiten. Das Zertifikat schuf eine scheinbar akzeptable Herkunft. Die Netzposition erlaubte das Ersetzen einer legitimen Antwort. Die Richtlinie des Update-Agenten entschied, ob eine unter der breiten Microsoft-Root stehende Signatur als Update-Autorität genügte.

Diese Zerlegung verhindert zwei Fehlschlüsse. Zertifikate zu sperren beendet nicht jede feindliche Zustellung. Den Kanal zu härten genügt nicht, solange eine unberechtigte Code-Signatur akzeptiert wird. Herkunft des Signierers, Berechtigung für genau dieses Produkt und Integrität der Übertragung sind getrennte Prüfungen.

Unternehmensproxys, Caches, WSUS, SCCM, TLS-Inspektion und interne Namensauflösung vervielfachen mögliche Einlieferungspositionen. Sie waren nicht automatisch Ursache des historischen Vorfalls. Sie gehören aber in das Fähigkeitsmodell: Wer kann welchem Prüfer ein Objekt vorlegen, und welche Signatur reicht dort zur Ausführung?

Microsoft entzog einer ganzen Hierarchie das Vertrauen

Als Sofortmaßnahme verschob Microsoft drei Intermediate-Zertifikate in den Windows Untrusted Certificate Store: zwei Microsoft Enforced Licensing Intermediate PCA und eine Microsoft Enforced Licensing Registration Authority CA (SHA1). Anschließend wurde die gesamte gegenwärtige und frühere Terminal-Server-Lizenzierungs-Hierarchie ungültig gemacht.

Die Maßnahme war bewusst breiter als der beobachtete Missbrauch. Wenn Ausgabemodelle, verwandte Zertifikate und historische Reichweite nicht schnell genug vollständig eingegrenzt werden können, bewahrt eine punktuelle Sperre möglicherweise unbekannte Geschwisterfähigkeiten. Die Hierarchie-Sperre reduzierte dieses Nachahmungsrisiko und nahm Betriebsfolgen in Kauf.

Die Ersatzarchitektur war enger. Ihre eigenständige Root wurde von gewöhnlichen Windows-Clients nicht als vertrauenswürdig behandelt. Code-Signaturzertifikate wurden eingestellt. Ein nicht für Code verwendeter Extended Key Usage begrenzte die neue Kette auf Terminal-Server-Lizenzierung. Der Geschäftsprozess blieb möglich, ohne seine Autorität aus der allgemeinen Microsoft-Vertrauensstellung zu erben.

Microsoft härtete außerdem Windows Update und führte einen automatischen Mechanismus für die Disallowed Certificate Trust List ein. Neu nicht vertrauenswürdige Zertifikate konnten dadurch schneller an Clients verteilt werden, ohne jedes Mal auf eine getrennte manuelle Aktualisierung zu warten. Ablehnung wurde zu einer betreibbaren verteilten Fähigkeit.

Der Entzug von Autorität verändert den Betrieb

Vorhandene Terminal Server Client Access Licenses wurden nicht ungültig. Administratoren mussten jedoch einen Lizenzserver reaktivieren, wenn sie ihn neu einrichteten, reaktivierten oder ein neues CAL-Paket installierten, weil sich die Zertifikate des Product Activation Clearinghouse geändert hatten.

Das Detail ist für die Führungsebene zentral. Breites Vertrauen senkt zunächst Integrationskosten; beim Entzug werden die verdeckten Abhängigkeiten sichtbar. Wer nicht weiß, welche legitimen Abläufe an einer Root hängen, wird in der Krise zwischen Sicherheitslücke und unbekanntem Ausfall zögern.

Der Ausstieg muss deshalb vor dem Vorfall entworfen sein: Client-Inventar, unabhängige Sperrverteilung, Ersatz-Root, Reaktivierung, Administrator-Kommunikation und der Nachweis, dass die Ersatzkette keine Code-Signatur zurückbringt. Widerrufsfähigkeit ist eine Architektureigenschaft.

Heng Lus Lehre vom Vorrang des laufenden Codes lenkt den Blick auf den tatsächlichen Clientzustand. Eine neue Richtlinie entfernt keine weiterhin akzeptierte Kette; eine verteilte Liste schützt kein isoliertes System, das sie nicht verarbeitet. Praktische Souveränität über Vertrauen besteht darin, Akzeptanz in der gesamten maßgeblichen Population ändern zu können.

Grenzen der Belege

Die offiziellen Quellen belegen aktiven Missbrauch, das gefälschte Zertifikat und die technische Reaktion, nennen jedoch weder eine vollständige Opferzahl noch ein vollständiges Verzeichnis aller Flame-Einsätze. Die hier verwendeten Dokumente schreiben den Angriff keinem Staat, keiner Organisation und keiner Person zu; Attribution bleibt außerhalb dieses Beitrags.

Die Kollision war keine Schlüsselwiederherstellung und erlaubt nicht das beliebige Ändern bereits ausgegebener Zertifikate. Die Vista-Grenze ist eine Aussage über das von Microsoft beschriebene Windows-Verhalten. Das Update-Szenario brauchte eine Lieferposition und war keine dokumentierte Kompromittierung des zentralen Dienstes.

SHA-1 in der Ersatzhierarchie ist ein historischer Fakt; seine spätere Abkündigung ist nicht rückwirkend mit der MD5-Kollision von 2012 gleichzusetzen. Die RFCs liefern Standardkontext, keine Vorfallchronologie. Heng Lus Texte werden ausdrücklich als analytischer Rahmen verwendet, nicht als Belegquelle für Flame.

Quellen