April 11, 2014 •Admin
Vor einigen Tagen sorgte eine entdeckte Sicherheitslücke in OpenSSL für großes Aufsehen in der Entwicklergemeinde. Experten sprechen sogar davon, dass es sich um die größte bis dato entdeckte Sicherheitslücke im Internet handle. Doch was genau steckt hinter dem als „Heartbleed“ bezeichneten Bug und wieso schlägt dieser so hohe Wellen?
Zunächst ist OpenSSL nur eine Implementierung des als TLS bekannten Transportprotokolls, welches dazu verwendet wird, um die Kommunikation im Internet zu verschlüsseln. Da TLS lediglich ein Transportprotokoll zur sicheren Datenübertragung im Internet ist, bedarf es einer Implementierung von Softwarebibliotheken, um es nutzen zu können. Neben OpenSSL gibt es zwar noch eine Vielzahl anderer Implementierungen, wie z.B. GnuTLS oder PolarSSL, doch ist OpenSSL die am weitesten verbreitete Bibliothek. Gerade deshalb erschüttert diese entdeckte Lücke geradezu die Grundfesten der Internetkommunikation. OpenSSL ist so weit verbreitet, dass es sich dabei um einen quasi-Standard handelt. Der Grund für diese hohe Verbreitung der Bibliothek ist die freie Lizenz, unter der sie vertrieben wird.
Was genau ermöglicht der Heartbleed-Bug
Sobald ein Besucher eine SSL-verschlüsselte Seite besucht, tauschen Client und Server über das TLS Protokoll im Hintergrund Kryptographieschlüssel aus, die anschließend für die Verschlüsselung der Kommunikation verwendet werden. Da eine Sitzung allerdings eine lange Zeit dauern kann, wurde im Frühjar 2012 eine Funktion eingeführt, die sich Heartbeat nennt. Diese ist dafür zuständig, die Erreichbarkeit der Gegenstelle zu prüfen. Dazu schickt der Client dem Server ein kleines Datenpaket, das der Server kopiert und seinerseits zurück an den Client schickt.
An dieser Stelle greift nun die Lücke, die dafür sorgt, dass der Server die Länge der Nachricht nicht überprüft und dem Client eine Nachricht in der von ihm angegebenen Größe zurückschickt. Wenn nun der Client beispielsweise eine leere, 1 Byte große Nachricht an den Server schickt, sie aber als 64KByte groß deklariert, kopiert der Server sie in den Speicher und schickt seinerseits dann eine 64KByte große Nachricht zurück. Es kommt vor, dass sich zu diesem Zeitpunkt auf dem Server sensible Daten im Speicher befinden und diese zurückgeschickt werden.
Normalerweise befinden sich nicht nur Benutzernamen und Passwörter im Speicher, mitunter ist es sogar möglich, dass sich auch private Schlüssel darin befinden. Sollte es einem Angreifer gelingen, einen solchen Schlüssel zu ergattern, dann kann er eine zuvor aufgenommene Kommunikation zwischen zwei Parteien, die mit diesem Schlüssel verschlüsselt wurden, ohne Probleme nachträglich entschlüsseln.
Zur Verdeutlichung veröffentlichte Randall Munroe auf xkcd.com einen passenden Comic zum Thema:
CC BY-NC 2.5 | xkcd.com/1354
Spätestens jetzt offenbart sich die Tragweite dieses Bugs: Da dieser Angriff kaum Spuren auf dem Server hinterlässt, kann im Nachhinein nicht mit Sicherheit festgestellt werden, welche Daten der Server übermittelt hat. Nun stellt sich die Frage, welche Schritte eingeleitet werden sollen und welche konkrete Auswirkungen dies mit sich führt.
Schnelles Handeln ist das Wichtigste
Bei HDNET waren wir von der Sicherheitslücke genauso betroffen wie bspw. Google, Yahoo oder Web.de. Zusammen mit unseren Technologiepartnern haben wir alles unternommen, um den Fehler so schnell wie möglich zu beheben. Schon eine Stunde nach Bekanntwerden, hatten wir alle notwendigen Vorkehrungen getroffen.
Eine Ausnutzung der Sicherheitslücke konnten wir in unseren Systemen nicht feststellen. Dennoch empfehlen wir SSL Schlüsselpaare neu zu erzeugen. Falls Sie OpenSSL einsetzen, sollten Sie es auf Version 1.0.1g updaten. Eine genaue Liste aller betroffenen Versionen können Sie hier einsehen.
Laptop-Icon made by Freepik from Flaticon.com