Dipl.-Inform. Carsten Eilers

Eine Untersuchung der Electronic Frontier Foundation hat ergeben, dass seit Juni dieses Jahres 4 Zertifizierungsstellen (Certificate Authority, CA) kompromittiert wurden. Bisher war lediglich die Kompromittierung von Diginotar bekannt, außerdem die Behauptung des sog. "ComodoHacker", dass er Zugriff auf vier weitere "HIGH profile CAs", darunter GlobalSign, habe. Wobei GlobalSign bei einer auf die Ankündigung folgenden Untersuchung keinen Angriff feststellen konnte.

Die EFF hat nun die Zertifikats-Rückruflisten (Certificate Revocation Lists, CRL) ausgewertet, in denen auch der Grund für den Rückruf eines Zertifikats angegeben werden kann. Demnach haben seit Juni dieses Jahres 4 CAs Zertifikate auf Grund einer Kompromittierung zurückgezogen. Insgesamt wurden aktuell 248 Zertifikate von 14 CAs auf Grund einer Kompromittierung zurückgezogen, im Juni waren es erst 55 Zertifikate von 10 CAs. Der Zuwachs geht übrigens nicht auf das Konto von DigiNotar, denn dort wurden ja mindestens 531 gefälschte Zertifikate ausgestellt, die dürften also ohne Angabe des Grunds oder mit einer falschen Angabe zurück gerufen worden sein. Sofern man sich nicht auf das Löschen der Root-Zertifikate durch die Browserhersteller verlassen und auf den Rückruf der letzten Zertifikate ganz verzichtet hat.

Wie viele weitere CAs kompromittiert wurden, aber entweder gar keinen Grund für den folgenden Zertifikatsrückruf angaben oder ihn nur als "Unspecified" markierten, möchte man dann wohl besser gar nicht wissen. Denn insgesamt 921683 mal wurde gar kein Grund angegeben, 168993 mal "Unspecified". Wer nichts zu verbergen hat, kann doch den Grund eigentlich angeben, oder? Immerhin handelt es sich ja nur um allgemeine Kategorien und nicht um Detailinformationen.

Im Zusammenhang mit Duqu, zu dem ich gleich noch komme, ist ein anderer Punkt interessant: 73345 Zertifikate wurden zurückgerufen, weil der zugehörige private Schlüssel kompromittiert wurde (im Juni waren es noch "nur" 59527 Zertifikate). Auch Duqu wurde ja vermutlich mit einem "gestohlenen" privaten Schlüssel signiert. Die Zertifikatsinhaber scheinen teilweise also recht leichtsinnig mit ihrer digitalen Unterschrift umzugehen. Ob die im "Real Life" auch so leichtsinnig sind? Ob man von denen dann wohl auch ein paar Blankoschecks bekommen könnte?

SSL: DoS-Angriffe auf Server

Ein SSL nutzender Server wird durch das laufende Ver- und Entschlüsseln nicht übermäßig belastet. Lediglich das Aushandeln der Verschlüsselung, der "Handshake" beim Verbindungsaufbau, ist aufwendig. Während für die laufende Ver- und Entschlüsselung die effektiv zu berechnenden symmetrischen Verschlüsselungsverfahren wie AES verwendet werden, wird für die Aushandlung des dafür verwendeten AES-Schlüssels ein aufwändig zu berechnendes asymmetrische Verfahren wie RSA benötigt. Hinzu kommt die bei den asymmetrischen Verfahren deutlich größere Schlüssellänge, die den Aufwand weiter steigert.

Das kann zum Problem werden, wenn ein Angreifer ständig neue Verbindungen aufbaut (bei denen jedes Mal ein neuer Schlüssel ausgehandelt werden muss) oder bei einer bestehenden Verbindung ständig eine Neuaushandlung (Key Renegotiation) erzwingt. Das DoS-Angriffe durch ständige Key Renegotiation möglich sind, ist seit langem bekannt. Im Grunde kann man die Angriffe z.B. durch ein Shellskript und OpenSSL durchführen. Trotzdem werden solche Angriffe jetzt akut(er), da von "The Hacker's Choice" ein Tool zum Durchführen solcher DoS-Angriffe veröffentlicht wurde. Wobei fest zu halten ist, dass das Tool bereits vor einiger Zeit veröffentlicht wurde, wirklich neu ist lediglich die Ankündigung und Webseite zum Tool. Mit dem Tool kann ein normaler Laptop über eine Standard-DSL-Verbindung einen HTTPS-Server lahm legen.

Zur Abwehr der DoS-Angriffe durch das Tool reicht es, die Key Renegotiation auszuschalten. Am grundsätzlichen Problem ändert das aber nichts, da sich auch durch den Aufbau einer großen Anzahl neuer Verbindungen ein DoS erreichen lässt. Im Endeffekt hilft also nur "Mehr Power!".

Insgesamt gesehen wird es wohl Zeit, sich über mögliche Alternativen für SSL/TLS Gedanken zu machen.

Neues zu Duqu

Auch zu Duqu gibt es einiges Neues. Z.B. eine Analyse des Dell SecureWorks Counter Threat Unit Research Teams, der zu Folge es gar nicht so sicher ist, dass Duqu und Stuxnet von den gleichen Entwicklern stammen. Insbesondere, weil die Schadfunktionen sich überhaupt nicht gleichen.

Einer Analyse von ESET zufolge ähneln sich aber z.B. die Implementierungen des RPC-Protokolls stark. Stuxnet implementiert 10 Prozeduren, Duqu nur 7, die aber alle auch in Stuxnet enthalten sind. Ob beide Schädlinge von den gleichen Entwicklern stammen oder nicht ist also noch nicht eindeutig bestätigt, bisher scheinen aber mehr Indizien dafür als dagegen zu sprechen. Zumal SecureWorks Argument der unterschiedlichen Payload auf wackligen Füßen steht, schließlich wollen die Angreifer mit beiden Schädlingen unterschiedliche Ziele angreifen und unterschiedliche Aktionen durchführen.

Immerhin gibt es neue Informationen über die möglichen Ziele von Duqu, wenn auch wenige. Einem Bericht von Kaspersky zu Folge wurden bisher vier Infektionen mit Duqu durch das Cloud-basierte Kaspersky Security Network entdeckt: Eine im Sudan, drei im Iran.

Im Sudan wurde ein bisher unbekannter Treiber entdeckt, den Kaspersky jedoch nicht erhalten konnte. Daher sind nur der Dateiname (adp55xx.sys), die Größe und die Prüfsumme bekannt. Auch im Iran kamen neue Treiber und auch neue Konfigurationsdateien zum Einsatz, von denen Kaspersky aber oft keine Kopien bekommen konnte. Außer im Sudan und im Iran wurden von Kaspersky bisher keine Infektionen registriert. Das hat aber evtl. nichts weiter zu besagen. Es kann ja sein, dass Tausende weiterer Rechner infiziert sind, aber auf allen keine Kaspersky-Lösung eingesetzt wird.

Wie Duqu auf die infizierten Rechner gelangt, ist immer noch nicht bekannt. Merkwürdig, oder? Kaspersky berichtet lediglich über einen Fall, in dem auf einem infizierten Rechner zwei Angriffsversuche auf die mit dem Security Bulletin MS08-067 veröffentlichte Schwachstelle beobachtet wurden. Diese Schwachstelle wurde auch von Conficker/Downadup und Stuxnet ausgenutzt. Beide Angriffe gingen von der gleiche IP-Adresse in den USA aus.

Nachtrag 2.11.:
Symantec hat ein von CrySyS Labs entdecktes Word-Dokument, dass eine 0-Day-Schwachstelle im Windows-Kernel ausnutzt, um Duqu einzuschleusen, analysiert. Das Word-Dokument ist so formuliert, dass es die angegriffene Organisation interessiert, der eingeschleuste Shellcode lässt die Installation von Duqu nur in einem Zeitraum von 8 Tagen im August dieses Jahres zu.

Danach wird es in Symantecs Bericht etwas mysteriös:

"Once Duqu is able to get a foothold in an organization through the zero-day exploit, the attackers can command it to spread to other computers. In one organization, evidence was found that showed the attackers commanding Duqu to spread across SMB shares."

Bisher wurde immer behauptet, Duqu enthalte keinerlei Verbreitungsroutinen - wie kann die Hintertür dann aber angewiesen werden, sich auszubreiten?

Weitere Neuigkeiten gibt es zur Kontrolle von Duqu. Zum einen wurde ein neuer Command&Control-Server (mit Standort in Belgien) entdeckt, zum anderen ein zweiter Command&Control-Kanal: Auf Rechnern, die keine Verbindung zum Internet haben, enthält die Konfigurationsdatei Anweisungen, über ein Filesharing-Protokoll Verbindung mit einem Rechner aufzunehmen, der eine Verbindung zum Internet hat und der dann die Verbindung mit dem Command&Control-Server aufnimmt.

Symantec gibt auch ein paar Informationen über die Opfer bekannt. Bisher wurden demnach sechs Organisationen in verschiedenen Staaten angegriffen:

Einige Organisationen wurden nur anhand ihres ISPs identifiziert, so dass sie u.U. zusammen gehören. Von anderen Antiviren-Herstellern wurden weitere Infektionen in Österreich, Ungarn, Indonesien, Großbritannien und dem Iran entdeckt, wobei die Infektionen im Iran andere als die von Symantec entdeckten sind.

Symantec hat sein Whitepaper (PDF) aktualisiert.
Ende des Nachtrags

Duqu scheint also weiterhin sehr gezielt eingesetzt zu werden, aber da der Schädling im Gegensatz zu Stuxnet keine Verbreitungsroutinen enthält, kann er auch nicht unbemerkt entfleuchen und zu großmaßstäblichen Infektionen führen.

Unklar ist auch, von wo aus die infizierten Rechner jetzt gesteuert werden. Die in Indien lokalisierten Command&Control-Server wurden inzwischen aus dem Verkehr gezogen und teilweise beschlagnahmt. Genauer: Es wurden "several hard drives and other components" beschlagnahmt, die nun analysiert werden.

Da bleibt wohl nur die Feststellung, dass es zu Duqu immer noch mehr offene als beantwortete Fragen gibt. Vor allem der Infektionsweg ist immer noch ungeklärt. Ich fürchte, das "dicke Ende" kommt noch...

Nachtrag 2.11.:
Symantec hat wieder etwas Licht ins Dunkel gebracht - und eine neue Frage aufgeworfen: Wie kann Duqu sich auf Befehl ausbreiten, wenn es doch gar keine entsprechenden Funktionen gibt? Auch ist immer noch unklar, wie Duqu zur Zeit gesteuert wird, da der Server in Belgien natürlich auch aus dem Verkehr gezogen wurde. Haben die Angreifer die Möglichkeit, Duqu im Betrieb umzukonfigurieren, nachdem der Command&Control-Server ausgefallen ist?
Ende des Nachtrags

Carsten Eilers

Übersicht über alle Artikel zum Thema "Stuxnet und Duqu"

Stuxnet - Ein paar Fakten

Standpunkt: Stuxnet - Wer will da wem an die Produktion?

Standpunkt: Stuxnet - Der erste Schritt zum Cyberwar?

Standpunkt: Stuxnet - Ein Überblick über die Entwicklung

Standpunkt: Stuxnet: Kaum neue Fakten, ein neues Gerücht

Standpunkt: Stuxnet - Stand der Dinge

Standpunkt: Der Wink mit dem Stuxnet

Standpunkt: Neues zu Stuxnet, Android-Trojanern, USB-Keyloggern und Facebook

Standpunkt: Conficker ist wieder da. Und was macht Stuxnet?

Das RAT, das aus dem Stuxnet kam

Standpunkt: Clickjacking gegen Flash, urchin.js und Duqu - nichts als Wiederholungen!

Standpunkt: Neues zu SSL und Duqu

Standpunkt: Wie gefährlich ist die Duqu-0-Day-Schwachstelle?

Standpunkt: Neues zu Duqu