Blog

Zurück zur Übersicht

OpenSSL-Lücke Heartbleed: Was tun?

   10.04.2014   OpenSSL, Heartbleed, Attacke, SSL, Bug, Sicherheit


Ein neuer Open-SSL Bug namens Heartbleed bringt zurzeit die Köpfe zum rotieren und lässt die Telefonleitungen heisslaufen. Wir liefern Antworten auf die zentralen Fragen: Wie funktioniert er, was kann ein Angreifer machen, was kann man degegen tun und vor allem: geht jetzt die Welt unter?

Worum geht es?

Ein vor kürzlich entdeckter Fehler in der Open-Source-Verschlüsslungsbibliothek OpenSSL ermöglicht jedem den Inhalt des Speichers eines betroffenen Systems auszulesen. Dabei können nicht nur Benutzernamen, Passwörter und eigentlich verschlüsselte Daten in die Hände eines potentiellen Angreifers fallen, sondern im worst case auch der private Schlüssel des Server-Zertifikats. Damit stünden dem Entschlüsseln von eigentlich verschlüsselten Übertragungen keine grossen Hindernisse mehr im Wege. Ob eine spezifische Adresse verwundbar ist oder nicht, kann z.B. unter diesem Link getestet werden.

So funktioniert der Bug

Die Heartbeat-Erweiterung des TLS-Protokolls wurde Anfangs 2012 eingeführt und sorgt dafür, dass Verbindungen länger aufrechterhalten werden, ohne dass sie jedes Mal von neuem wieder ausgehandelt werden müssen. Durch einen Fehler bei der Parameter-Überprüfung kann Heartbeat 64k mehr Daten zurückliefern, als eigentlich geplant. Diese zufälligen Daten kommen dabei nicht von Heartbeat selber sondern aus dem Arbeitsspeicher des Servers und können theoretisch alles beinhalten, was zu dem Zeitpunkt gerade im Arbeitsspeicher liegt.

Was macht ein Angreifer?

Der Angreifer schickt eine mit falschen Parametern versehene Hearbeat-Anforderung und bekommt 64k zufälliger Daten aus dem Arbeitsspeicher des Servers zurück, welchen er noch wichtigen Informationen durchsucht. Das Ganze lässt sich natürlich automatisieren, in der Hoffnung irgendeinmal auf sensitive Daten zu stossen – ganz nach dem Russischen Roulett Prinzip. Dabei hinterlässt er praktisch keine Spuren. Neben interessanten Daten wie Login-Informationen oder Kreditkarten-Daten hofft er natürlich auf den Jackpot zu stossen, den privaten Schlüssel des Serverzertifikates. Damit kann er eine Man-in-the-Middle-Attacke starten, früher gespeicherte verschlüsselte Surf-Sessions knacken oder in eine aktuelle Surf-Session hineinhören.

Was dagegen getan wird

Geräte, auf denen OpenSSL in Versionen 1.0.1 bis 1.0.1f  läuft, können anfällig sein und es sollten, falls sie mit dem Internet verbunden sind, so schnell als möglich die Updates eingespielt werden. Um ganz sicher zu gehen, sollte auch das Serverzertifikat gewechselt (erneuern reicht nicht!) werden, damit nicht später beliebige, verschlüsselte Verbindungen mitgehört werden können, sollte der private Schlüssel in fremde Hände gelangt sein. Und zum Schluss sollten alle Passwörter, die über die unsichere Verbindung verwendet wurden, gewechselt werden. Schwieriger ist die Situation bei Embedded Geräten. Hier ist man auf Gedeih und Verderben dem Hersteller und seiner Update-Politik ausgeliefert, falls eine solche überhaupt existiert. Im schlimmsten Fall sollten solche Geräte als unsicher angesehen und vom Netz genommen werden.

Geht die Welt jetzt unter?

Jein. Aus Sicht des Krypto-Experten ist dies eine riesige Katastrophe und alles, was über die entsprechenden OpenSSL-Versionen lief, muss als kompromittiert gelten. Die Realität sieht aber nicht ganz so düster aus. Ein grosser Teil der Server im Internet verwendet OpenSSL, aber nicht alle. Wichtige Dienste, wie beispielsweise das e-Banking, basieren ihre Sicherheit nicht nur auf (OpenSSL)-Verschlüsselung, sondern verwenden mehrstufige Authentifizierungsmethoden und haben praktisch durchgehend die Änderungen eingespielt, sofern sie überhaupt davon betroffen waren. Auch dass der private Zertifikatsschlüssel überhaupt in falsche Hände gelangte, ist nicht zwingend, aber man weiss es halt nicht. Zumindest kann man annehmen, dass für die grosse Allgemeinheit nur ein kleines Zeitfenster zur Verfügung stand, um diesen Fehler in seiner ganzen Tragweite auszunutzen. Wer zudem noch Perfect Forward Secrecy auf dem Server verwendet, muss zumindest nicht fürchten, dass früher einmal aufgezeichnete Daten nun mit einem neu entwichenen Private-Key doch noch entschlüsselt werden können.


Die unzähligen Möglichkeiten hinterlassen definitiv kein gutes Gefühl, sind aber kein Grund zur Hysterie. Wer auf eine aktuelle und gut gewartete Infrastruktur gesetzt hat, kann zumindest dieses Problem mit wenig Aufwand aus der Welt schaffen.
 

Weiterführende Links:
NIST: Vulnerability Summary for CVE-2014-0160
Filippo Valsorda: Heartbleed test



0
0



Hinterlassen Sie einen Kommentar: