Heartbleed: Shit hits the fan

Der erste Bug mit eigenem Logo

Erst Apples goto-fail-Bug, dann der Zertifikats-Bug in GnuTLS, und jetzt der Heartbleed-Bug in OpenSSL – in den letzten Wochen hat faktisch jede SSL-Implementierung ihr Fett wegbekommen. Die Schwere der Fehler sind obendrein in aufsteigender Reihenfolge: Sorgten die ersten beiden „nur“ dafür, daß Zertifikate fälschlicherweise als gültig anerkannt wurden, erlaubt Heartbleed es, Speicherbereiche auszulesen.

Das wie

Wie der Heartbleed-Bug ausgenutzt werden kann beschreibt xkcd schön in einem Comic:

(Bild CC by-nc Randall Munroe)

Wer’s gerne etwas technischer mag, dem empfehle ich diese Beschreibung des Hearbleed-Bugs. Festzuhalten ist:

  • Der Angreifer kann ca. 64 kB Speicher auslesen, der „Datenmüll“ von vorheriger Verwendung enthält
  • Der Angreifer hat keinen Einfluß darauf, wo sich dieser Speicher befindet
  • Der Angriff ist trivial durchzuführen, hinterläßt keine Spuren, führt zu keinen Crashes und kann so in kurzer Folge zig-fach angewandt werden
  • Der Angriff funktioniert in beide Richtungen – nicht nur ein böswilliger Client kann so Daten vom Server abgreifen, auch umgekehrt kann ein böswilliger Server einen arglosen Client angreifen.

Das was und wer

Angriffsziele sind naheliegenderweise Webseiten, aber auch diverse VPN-Lösungen nutzen openssl als unterliegende Technologie. Browserseitig scheint die Welt nochmal Glück gehabt zu haben, aber serverseitig sieht es düster aus: Äußerst viele Webserver sind betroffen, über Heartbleed lassen sich verschiedenste Daten sammeln – begonnen bei Daten anderer Leute (bei Webservern möglicherweise das begehrte Sessioncookie) bis hin zu den SSL-Schlüsseln des Servers. Diverse Leute, u.a. CloudFlare [spekulierten darauf, daß das Auslesen der „Kronjuwelen“, nämlich der SSL-Schlüssel nicht so einfach sei] (http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed), allerdings muß diese Ausage inzwischen als widerlegt betrachtet werden.

Gruselig ist die Überlegung, wer da alles Daten sammelt – und seit wann. Berichten zufolge sammelten „Interessierte“ nach Bekanntwerden des Bugs wild gigabyteweise Heartbleed-Dumps. Forensiker entdeckten bald Spuren, die belegten, daß der Bug seit mindestens letztem November aktiv genutzt wird (siehe auch dieser Bericht der EFF). Eine naheliegende Vermutung ist es, entsprechende Aktivitäten seitens Diensten wie der NSA anzunehmen, die dementiert dies jedoch. Die Geschichte wird möglicherweise zeigen, ob das der Wahrheit entspricht.

Konsequenzen

Alle Anwendungen, die die betroffenen openssl-Versionen in den letzten zwei Jahren verwendet haben, müssen konsequenterweise ihr Schlüsselmaterial als kompromittiert betrachten. Das bedeutet neue Zertifikate für Webserver, VPN-Server und -Clients, etc.

Benutzer sollten auf betoffenen Webseiten ihre Kennwörter ändern und ggfs. dort hinterlegte Zahlungsmittel auf ungewöhnliche Aktivitäten hin beobachten. Das ist besonders hart, da kaum abzusehen ist, welche Webseiten alles betroffen waren. Ich bin bis dato von exakt einer(!) Seite benachrichtigt worden, wegen des Bugs zur Sicherheit mein Kennwort zu ändern. Das kann bei weitem nicht alles sein.

Auch eine einfache Zwei-Faktor-Authentisierung (wie z.B. Google Authenticator) ist in diesem Fall keine Sicherheit, denn es ist nicht auszuschließen, daß das zugehörige Geheimnis nicht auch durch den Heartbleed-Bug ausgelesen werden konnte. Besser sieht es bei der SSL-Client-Authentisierung aus, hier wird auf dem Server kein (potentiell auslesbares) Geheimnis, sondern nur ein Zertifikat benötigt, welches keine geheimen Daten beinhaltet.

Für Entwickler sind die mittelfristigen Konsequenzen folgende Fragen:

  • Wie kann insbesondere bei solch verbreiteten und sicherheitskritischen Bibliotheken verhindert werden, daß sich solche Fehler einschleichen? Das Code-Review-Netz bei openssl war in diesem Fall wohl nicht fein genug.
  • Wie schütze ich meine Nutzer in solchen Worst-Case-Szenarien? Die klassische Name-Passwort-Anmeldung hat bereits aus anderer Richtung schon Schrammen und Dellen, mittelfristig werden hier andere Lösungen benötigt. Die Verwendung von Perfect Forward Secrecy beim Übertragen von verschlüsselten Daten sollte eigentlich schon seit den entsprechenden Snowden-Enthüllungen zum Gold-Standard geworden sein.
  • Wie weit sollten Standards ohne eigene Überlegungen 1:1 umgesetzt werden? Die Heartbeat-Erweiterung ist in verschiedenerlei Hinsicht unsinnig. Sie macht nur Sinn bei SSL über UDP, und selbst hier gibt es keine vernünftige Begründung für eine (obendrein variable) Payload bei einem Heartbeat-Paket. Die hartnäckige Frage, ob das vielleicht doch der Versuch einer subtilen Backdoor war, wird sich die IETF und das openssl-Team sicher noch eine Weile gefallen lassen müssen.
  • Welche Programmiersprache ist die geeignete? Sollte man insbesondere bei neuen Projekten überhaupt noch zu C/C++ greifen? Alternativen wie Go oder besser noch Rust zeigen, daß Low-Level-Sprachen heute auch ganz anders aussehen können.