Skip to content

Flame und die Windows-Updates

An Flame war ja anfangs eigentlich nichts besonderes, wenn man mal von der Größe und der Unfähigkeit der Antivirenhersteller, diesen Riesenschädling zeitnah zu entdecken, absieht. Einzig interessant schien die zumindest anfangs unbekannte Verbreitungsmethode zu sein. Und wie sich inzwischen heraus gestellt hat, hat die es wirklich in sich. Und diesmal besteht zumindest begrenzt wirklich Grund zur Panik.

Wie verbreitet sich Flame?

Die ersten bekannt gewordenen Verbreitungsmethoden waren, gelinde gesagt, alte Hüte. Wenn auch in einem Fall etwas aufgehübscht war nichts wirklich beunruhigenderes daran. Flame verbreitet sich

  • mit Hilfe ausgespähter Zugangsdaten über Netzwerk-Shares,
  • über die auch von Stuxnet ausgenutzte Schwachstelle im Printer Spooler,
  • mittels präparierter autorun.inf-Dateien über mobile Massenspeicher (genau wie Stuxnet), und
  • über mobile Massenspeicher, wobei ein unsichtbares Verzeichnis recht trickreich mit der schon von Stuxnet ausgenutzten Shortcut-Schwachstelle kombiniert wird.

Mal abgesehen davon, dass da ein "neuer" Cyberwar-Schädling die gleichen Schwachstellen wie der erste(?) Cyberwar-Schädling Stuxnet ausnutzt, ist das nicht besonders bemerkenswert. Insbesondere eine 0-Day-Schwachstelle wurde bis dahin nicht gefunden, obwohl damit zu rechnen war. Denn auch vollständig gepatchte Windows-7-Installationen wurden mit Flame infiziert, und dafür wäre ein Angriff über eine 0-Day-Schwachstelle die einfachste Erklärung.

Aber dann ging es los...

Microsoft misstraut eigenen Zertifikaten

Am dritten Juni kündigte Microsoft das Security Advisory 2718704 an, drei Intermediate-Zertifikaten von Microsoft wurde das Vertrauen entzogen:

  • Microsoft Enforced Licensing Intermediate PCA (2 Zertifikate)
  • Microsoft Enforced Licensing Registration Authority CA (SHA1)

Anlass waren in Flame entdeckte gefälschte Zertifikate, die sich auf diese Intermediate-Zertifikate zurückverfolgen lassen. Mit diesen Zertifikaten konnte sich Code als von Microsoft stammendes Update ausgeben. Um zu erklären, wie das funktioniert und was das eigentlich bedeutet, muss ich etwas weiter ausholen.

Microsofts Update-Mechanismus

Microsoft signiert Updates, damit das das Update installierende Windows sicher sein kann, dass der Code wirklich von Microsoft stammt und unverändert ist. Normalerweise werden alle Signaturen als gültig anerkannt, die von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) stammen. Das diese CAs nicht immer vertrauenswürdig sind, war hier ja schon mehrmals Thema, z.B. hier, hier, hier oder hier. Damit kein gefälschtes oder erschlichenes Zertifikat zum Einschleusen von Schadcode genutzt werden kann, prüft Microsofts Update-Mechanismus nicht nur die Gültigkeit des Zertifikats an sich, sondern zusätzlich, ob die Root-CA am Ende der Zertifikatskette Microsofts CA ist.

Das funktioniert so lange, wie kein Unbefugter ein Microsoft-Zertifikat zum Signieren von Code erhält. Und genau das ist nun passiert:

"When we initially identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft, we immediately began investigating Microsoft’s signing infrastructure to understand how this might be possible. What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure."

Mit anderen Worten: Microsoft hat, aufgrund welches Fehlers oder Irrtums auch immer, selbst Zertifikate ausgestellt, die zum Signieren von Code verwendet werden können. Damit signierter Code wird von Windows Update-Funktion als von Microsoft stammend anerkannt und auch im Warndialog entsprechend gekennzeichnet. Außerdem wurde von Flame eine Schwachstelle in einem "älteren Kryptographie-Algorithmus" ausgenutzt, dazu unten mehr.

Ein Super-GAU

Falls es Ihnen bisher nicht aufgefallen ist, hier noch mal eine Zusammenfassung des Update-Prozesses samt Man-in-the-Middle-Angriff: Ein Windows-Rechner baut einer Verbindung mit dem Windows-Update-Server auf. Der Man-in-the-Middle schaltet sich in diese Verbindung ein und kann nun eigenen, korrekt signierten Schadcode an den Windows-Rechner schicken. Der akzeptiert diesen Schadcode als von Microsoft stammend und installiert ihn. Die Folgerung: Den von Microsoft gelieferten Updates kann nicht mehr vertraut werden.

So, und jetzt versuchen Sie mal, zuverlässig ein echtes Windows-Update zu installieren, z.B. das, mit dem den "kompromittierten" Zertifikaten das Vertrauen entzogen wird. Erkennen Sie das Problem? Der MitM kann dieses Update problemlos manipulieren und unterdrücken. Flame ist zwar nicht sehr weit verbreitet, und andere Schadsoftware, die die "Zertifikat-Schwachstelle" ausnutzt, ist nicht bekannt - aber wenn es sie geben würde, gäbe es keine Möglichkeit, das Update auf die betroffenen Rechner zu bekommen. Das kann man wohl getrost als Super-GAU bezeichnen.

Übrigens hat vor kurzem das Internet Crime Complaint Center (IC3) des FBI vor der Nutzung von Internet Verbindungen in Hotels gewarnt. Es gab Berichte über Infektionen von Laptops über gefälschte Updates populärer Programme. An der sehr kurz gehaltenen Warnung gab es viel zu kritisieren, mit der aktuellen Schwachstelle kommt ein weiteres Problem hinzu: Das Prüfen von Zertifikaten bzw. Signaturen würde im Fall von Windows das Einschleusen von Schadcode nicht verhindern.

Flames Angriff

Kaspersky stellte bei der Analyse von Flame fest, dass das Flame-Modul "Gadget" in Verbindung mit dem Modul "Munch" die Microsoft-Zertifikate nutzte, um Rechnern im lokalen Netz Schadcode als gefälschte Windows-Updates unter zu schieben. Immer, wenn ein Rechner versuchte, eine Verbindung zu Microsofts Windows Update aufzubauen, wurde die Verbindung über den mit Flame infizierten Rechner umgeleitet, wo "Munch" u.a. auf Update-Anfragen wartete. Auf die antwortete dann "Gadget" mit gefälschten Update-Paketen, über die dann der Schadcode eingeschleust wurde.

Die entscheidende Frage hat Kaspersky nicht beantwortet: Wie kommen die anderen Rechner im lokalen Netz dazu, ihre Verbindung über den mit Flame infizierten Rechner zu leiten, statt direkt auf das Internet zuzugreifen? Laut Symantec ist dafür das Modul "Snack" zuständig. Der Internet Explorer nutzt das sog. "Web Proxy Auto-Discovery Protocol" (WPAD), um im lokalen Netz nach einem evtl. vorhandenen Proxy-Server zu suchen. Dazu versucht er, die Konfigurationsdatei wpad.dat von einem Servers namens wpad in der lokalen Domain zu laden. Die IP-Adresse des Servers fordert es beim DNS-Server an, gibt es dort keinen passenden Eintrag, wird der Server über einen NetBIOS-Broadcast gesucht. Und an diesem Punkt kommt "Snack" ins Spiel: Das Modul gibt sich auf NetBIOS-Anfragen hin als WPAD-Server aus und sendet eine wpad.dat-Datei an den anfragenden Rechner, über die der mit Flame infizierte Rechner als Proxy eingetragen wird. Das Modul "Munch" agiert dann als Proxy, weiter geht es wie von Kaspersky beschrieben.

Symantec hat den ganzen Angriff auch sehr gut grafisch dargestellt. Kaspersky hat zwei Tage später eine genauere Beschreibung der genutzten Techniken veröffentlicht.

Die Zertifikats-"Schwachstelle" unter der Lupe

Am 4. Juni gab Microsoft weitere Informationen zur Schwachstelle und den Angriffen darauf preis:

"The Flame malware used a cryptographic collision attack in combination with the terminal server licensing service certificates to sign code as if it came from Microsoft. However, code-signing without performing a collision is also possible. This is an avenue for compromise that may be used by additional attackers on customers not originally the focus of the Flame malware. In all cases, Windows Update can only be spoofed with an unauthorized certificate combined with a man-in-the-middle attack."

Microsoft hat die weitere Härtung des Update-Mechanismus angekündigt. Updates werden nur noch akzeptiert, wenn sie mit einem speziell dafür erzeugten, neuen Zertifikat signiert wurden. Das gleiche gilt sinngemäß für die Verbindung zum Update Server. Außerdem wurde die Zertifikatsverwaltung von Windows aktualisiert: Die automatisch aktualisierte Disallowed Certificate Trust List (CTL) legt fest, welchen Zertifikaten nicht (mehr) vertraut werden darf, und ab August werden Zertifikate mit RSA-Schlüssel mit einer Schlüssellänge unter 1024 Bit nicht mehr akzeptiert.

Aber werfen wir jetzt mal einen Blick auf den Angriff durch Flame. Dazu ist erst mal eine kurze Einführung in Hashfunktionen nötig.

Hashfunktionen im Zertifizierungssystem

Vereinfacht ausgedrückt berechnet eine Hashfunktion hash(M) aus einer beliebig langen Eingabe M, z.B. einem Zertifikat, einen möglichst eindeutigen Hashwert h fester Länge, z.B. eine Zahlen-Buchstaben-Kombination: h = hash(M). Der Hashwert wird auch als Fingerprint (Fingerabdruck) der Eingabe bezeichnet.

Allgemein wird von Hashfunktionen gefordert, dass sich die Ergebnisse für verschiedene Eingaben mit ausreichend großer Wahrscheinlichkeit unterscheiden: Die Ergebnisse sollen möglichst gleichmäßig auf den definierten Wertebereich verteilt sein. Zwei Eingabewerte mit gleichem Hashwert werden als Kollision bezeichnet. Da die Ausgabemenge kleiner als die Eingabemenge ist, muss es zwangsläufig zu Kollisionen kommen. Für kryptographische Hashfunktionen wird gefordert, dass sich solche Kollisionen nicht effektiv berechnen lassen. Für die angegriffene Funktion MD5 sind entsprechende Angriffe seit einiger Zeit bekannt: Ein Angreifer kann zwei Eingaben finden, die zum gleichen Hashwert führen.

Die für das X.509-Zertifizierungssystem verwendete Public-Key-Kryptographie hat einen Nachteil: Die Algorithmen sind sehr langsam. Um das ganze zu beschleunigen, werden die Signaturen daher nicht über das komplette Zertifikat berechnet, sondern nur über dessen Hashwert. Gelingt es einem Angreifer, zwei Zertifikate mit gleichem Hashwert zu erzeugen, bestehen beide die Signaturprüfung, werden also als gültig anerkannt.

Der Angriff der Flame-Entwickler

Microsoft hat am 6. Juni weitere Details über den Angriff veröffentlicht. Demnach war der Kollisionsangriff nötig, um den Update-Mechanismus von Windows Vista und neuer auszutricksen, für ältere Versionen ist ein Angriff auch ohne Hash-Kollision möglich.

In den von der Terminal Server Lizenz-Infrastruktur erzeugten Zertifikaten ist die "Microsoft Hydra Extension" als kritisch markiert, sie soll dafür sorgen, dass das Zertifikat nur im Rahmen des Terminal Servers eingesetzt wird. Windows ab Vista bricht die Prüfung des Zertifikats beim Erkennen dieser ihm unbekannten kritischen Erweiterung ab. Um auch unter Vista und neueren Windows-Versionen Code einschleusen zu können, mussten die Angreifer also ein Zertifikat ohne diese Extension erzeugen. Konkret erzeugten sie ein Zertifikat ganz ohne Extensions.

Marc Stevens vom "Centrum Wiskunde & Informatica" (CWI) in Amsterdam hat herausgefunden, dass dafür eine komplett neue Variante eines "chosen prefix collision"-Angriffs verwendet wurde. Um so einen Angriff zu entwickeln, sind sehr gute Kryptographie-Experten notwendig. Seiner Ansicht nach spricht die Verwendung eines eigenen Angriffs dafür, dass Flame sich bereits in der Entwicklung befand, als er und einige Kollegen 2009 einen effizienten Algorithmus samt Sourcecode veröffentlichten. Wenn man bedenkt, dass bei Flame oft auf vorhandene Software zugegriffen wurde, erscheint das plausibel. Warum hätten die Entwickler nicht auch in diesem Fall auf ein vorhandenes Programm zurückgreifen sollen? Und so einen Angriff entwickelt man nicht mal eben zwischen Frühstück und Mittagessen, da wurde schon einiger Aufwand betrieben.

War das nun alles?

Ein erfolgreicher Angriff auf Microsofts Update-System ist so ziemlich das schlimmste, was passieren konnte. In diesem Fall ist aber wohl etwas anderes noch schlimmer: Das ein Staat so einen Angriff entwickelt und geheim gehalten und dabei in Kauf genommen hat, dass er auch von Dritten entdeckt und dann gegen alle Windows-Nutzer weltweit eingesetzt wird. Darüber dürften noch einige Diskussionen anstehen.

Aber auch bei Flame ist das Ende der Fahnenstange noch nicht erreicht: Es ist immer noch nicht bekannt, wie die erste Infektion in einem lokalen Netz erfolgt. Es ist also durchaus möglich, das noch 0-Day-Exploits entdeckt werden.

Einige weitere neue Informationen zu Flame finden Sie hier.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Flame schlummert vor sich hin, und der Iran wird (schon wieder?) angegriffen

Vorschau anzeigen
Was ist eigentlich aus Flame geworden? Erst tritt Kaspersky einen Medienhype los, obwohl zumindest anfangs kein Grund zu Panik bestand, dann kommt raus, dass Flame sich über eine 0-Day-Schwachstelle in Windows Update-Funktion verbreitet, un

Dipl.-Inform. Carsten Eilers am : Gezielte Angriffe und Advanced Persistent Threats

Vorschau anzeigen
Die "Operation Aurora", Stuxnet und der Angriff auf RSA sind die bekanntesten Advanced Persistent Threats, es gibt aber eine Reihe weiterer gezielter Angriffe, die zumindest teilweise als APT eingestuft werden können. Diese Angriffe bewe

Dipl.-Inform. Carsten Eilers am : Der neueste Schädling im Cyberwar ist eine kleine Flamme: miniFlame

Vorschau anzeigen
Kaspersky hat mal wieder einen neuen Cyberwar-Schädling gefunden: miniFlame. Was hat es damit auf sich? Vom Flame-C&C-Server zu miniFlame Bei der Analyse der Command&Control-Server von Flame hatte man festgestellt, dass die S

Dipl.-Inform. Carsten Eilers am : Cyberkrieger? Cyberkriminelle!

Vorschau anzeigen
Ein paar Worte zum Patch für die aktuelle 0-Day-Schwachstelle im Internet Explorer 8 führt zum Schluss, dass Cyberkrieger Cyberkriminelle unterstützen. Ein Patch für die 0-Day-Schwachstelle im IE8? Microsoft bemüh

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 7.2013 - Cyberwar

Vorschau anzeigen
Im windows.developer Magazin 7.2013 ist ein Artikel zu Stuxnet und Co. erschienen - den ersten Waffen im Cyberwar der USA und Israels gegen den Irak und andere Länder. Und hier noch die Links und Literaturverweise aus dem Artikel: S

Dipl.-Inform. Carsten Eilers am : Neues zur iOS-Sicherheit, bösartigen E-Mails und Überwachungsmöglichkeiten

Vorschau anzeigen
Heute gibt es mal wieder eine bunte Mischung an Kommentaren. Los geht es mit einem Hinweis auf eine Diskussion im Blog von Bruce Schneier: Ist die "GOTO FAIL"-Lücke in iOS und Mac OS X Mavericks ein Fehler oder eine absichtliche Hintertü

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : Verfahren der Kryptographie, Teil 15: MD4, MD5, SHA und SHA-1 - alle unsicher!

Vorschau anzeigen
Neuere Hashfunktionen als der bereits vorgestellte Algorithmus MD2 sind MD4 und MD5 sowie SHA und SHA-1. Wobei "Neuer" erst mal sehr relativ ist und außerdem nicht gleichzeitig auch "Sicher" bedeutet. MD4 und MD5 MD4 wurde von Ronal

Dipl.-Inform. Carsten Eilers am : Verfahren der Kryptographie, Teil 18: Angriffe auf Hash-Funktionen

Vorschau anzeigen
Welche Hashfunktionen unsicher bzw. sicher sind habe ich bereits bei den jeweiligen Beschreibungen der Funktionen MD4, MD5, SHA und SHA-1 (alle unsicher), der SHA-2-Familie (ab 256 Bit Hashlänge, also SHA-256, noch einige Jahre sicher) und

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 1.17 - Mit Proxy und Proxykonfiguration gegen HTTPS

Vorschau anzeigen
Im PHP Magazin 1.2017 ist ein Überblick über Angriffe auf SSL/TLS erschienen. Dass SSL nicht mehr ausreichend sicher ist und durch TLS in einer möglichst hohen Version ersetzt werden sollte ist seit längerem bekannt. Aber

Dipl.-Inform. Carsten Eilers am : Ein Patchday ohne 0-Days - und ohne Microsoft-Patches

Vorschau anzeigen
Das es mal einen Patchday ohne die Preisgabe von 0-Day-Exploits bzw. laufenden Angriffen gibt, kam ja schon vor. Aber am Februar-Patchday hat nicht nur Adobe nur Bulletins zu bisher unbekannten Schwachstellen veröffentlicht (zu Flash Player,