Sicherheitslücken gibt es viele - allerdings erreichen nur wenige den Bekanntheitsgrad, den Heartbleed erlangte. Das lag nicht nur an der Nomenklatur und einem eigenen Brand-Logo, sondern auch am Verbreitungsgrad der OpenSSL-Sicherheitslücke.
Heartbleed - Definition
Heartbleed ist eine Sicherheitslücke in OpenSSL, die im April 2014 bekannt wurde. Sie befand sich auf Tausenden von Webservern, darunter auch auf denen großer Websites wie Yahoo. OpenSSL ist eine Open-Source-Codebibliothek, die die Protokolle Transport Layer Security (TLS) und Secure Sockets Layer (SSL) implementiert. Der Heartbleed Bug hatte zur Folge, dass böswillige Angreifer anfällige Webserver leicht dazu bringen konnten, vertrauliche Informationen - inklusive Benutzernamen und Passwörter - zu senden.
Die TLS/SSL-Standards sind für die Verschlüsselung im Web von entscheidender Bedeutung. Der Fehler lag dabei eher in der OpenSSL-Implementierung als in den Standards selbst, löste aber bei seinem Bekanntwerden eine massive Security-Krise aus - schließlich waren 17 Prozent aller SSL-Server weltweit von der Schwachstelle betroffen.
Den Namen Heartbleed verdankt der Bug Heartbeat - einer wichtigen Komponente des TLS/SSL-Protokolls. Mit dem Heartbeat-Protokoll teilen sich zwei miteinander kommunizierende Rechner mit, dass sie noch verbunden sind - auch wenn der Benutzer gerade nichts herunter- oder hochlädt. Gelegentlich sendet einer dieser Computer ein verschlüsseltes Datenpaket, eine so genannte Heartbeat-Anfrage, an den anderen. Der zweite Computer antwortet mit genau demselben verschlüsselten Datenpaket und beweist damit, dass die Verbindung noch besteht. Weil Angreifer mithilfe von Heartbeat-Anfragen Informationen aus einem Zielserver extrahieren können, wurde die Schwachstelle Heartbleed getauft.
Heartbleed - Funktionsweise
Heartbleed funktioniert, indem es sich eine entscheidende Tatsache zunutze macht: Eine Heartbeat-Anfrage enthält Informationen über ihre eigene Länge, aber die verwundbare Version der OpenSSL-Bibliothek prüft nicht, ob diese Informationen korrekt sind. Das kann ein Angreifer nutzen, um den Zielserver so auszutricksen, dass er Zugriff auf Teile seines Speichers gewährt, die privat bleiben sollten. Um den Mechanismus dahinter zu verstehen, betrachten wir im Folgenden ein typisches Beispiel für OpenSSL in Aktion.
Stellen Sie sich vor, Sie lesen gerade Ihre Yahoo-Mails, haben aber seit einiger Zeit die Seite nicht mehr aktualisiert. Ihr Webbrowser möchte sicherstellen, dass der Yahoo-Server noch aktiv ist und sendet eine Nachricht, die im Wesentlichen besagt: "Du bekommst gleich eine 40 KB große Nachricht. Schick sie mir zurück." Die Heartbeat-Anfragen können unterschiedliche Größen aufweisen (bis zu 64 KB) und jede Anfrage muss Informationen über ihre spezifische Länge enthalten.
Empfängt der Yahoo-Server diese Nachricht, weist er einen Speicherpuffer zu, also einen Bereich des physischen Speichers, in dem er Informationen ablegen kann. Dessen Größe entspricht der gemeldeten Länge der Heartbeat-Anfrage, in unserem Beispiel also 40 KB. Als Nächstes speichert der Server die verschlüsselten Daten der Anfrage in diesem Speicherpuffer, liest sie dann sofort wieder aus und sendet sie zurück an Ihren Webbrowser. Wenn Ihr Browser dieselben Informationen zurückerhält, die er gesendet hat, kann er sicher sein, dass er immer noch eine Verbindung zu dem Server hat, mit dem er bis zu diesem Punkt kommuniziert hat.
Die Heartbleed-Schwachstelle konnte entstehen, weil die Implementierung der Heartbeat-Funktionalität in OpenSSL eine entscheidende Sicherheitsvorkehrung vermissen ließ: Der Rechner, der die Heartbeat-Anfrage empfing, überprüfte nie, ob die Anfrage tatsächlich so lang war, wie sie vorgab. Wenn also eine Anfrage angeblich 40 KB groß war, in Wirklichkeit aber nur 20 KB umfasste, legte der empfangende Rechner 40 KB Pufferspeicher beiseite, speicherte dann die 20 KB, die er tatsächlich erhielt. Anschließend schickte er jedoch nicht nur diese 20 KB zurück, sondern auch das, was sich in den nächsten 20 KB des Speichers befand. Diese Informationen hat der Angreifer somit aus dem Webserver extrahiert.
Heartbleed - Risikopotenzial
Heartbleed ist gefährlich, weil der Inhalt des Speicherpuffers sensible Informationen enthalten kann. Zugegeben, wenn Sie der Angreifer sind, haben Sie keine Möglichkeit, im Voraus zu wissen, was in den 20 KB, die Sie gerade vom Server geholt haben, lauert. Wenn Sie aber viel Glück haben, könnten Sie an die privaten SSL-Schlüssel gelangen, die eine Entschlüsselung der sicheren Kommunikation mit dem Server ermöglichen. Das ist zwar unwahrscheinlich, aber der heilige Gral für einen Angreifer. Wahrscheinlicher ist es schon, Benutzernamen und Kennwörter aufzudecken, die an Anwendungen und Services auf dem Server übermittelt wurden.
Randall Munroes ist dafür bekannt, mit seinem Webcomic xkcd komplexe Konzepte verständlich zu machen - insbesondere wenn es dabei um sein Fachgebiet, die Informatik, geht. Folgender Comic aus dem Jahr 2014 fasst die Funktionsweise der Heartbleed-Sicherheitslücke hervorragend zusammen:
Heartbleed - Detektion
Heartbleed wurde von zwei verschiedenen Akteuren entdeckt, die unabhängig voneinander und auf sehr unterschiedliche Weise arbeiteten: Einmal im Zuge einer Überprüfung der OpenSSL-Codebasis und einmal während einer Reihe simulierter Angriffe auf Server, die OpenSSL verwenden. Die beiden unabhängigen Detektionen erfolgten im Abstand von wenigen Wochen, was vor dem Hintergrund, dass die Sicherheitslücke zuvor zwei Jahre lang unentdeckt geblieben war, etwas ironisch anmutet.
Der erste, der Heartbleed entdeckte, war Google-Ingenieur Neel Mehta im März 2014. Er hatte sich entschlossen, den OpenSSL-Code Zeile für Zeile zu überprüfen, da zwei frühere SSL-Schwachstellen, "Goto Fail" und "GnuTLS" ihn vermuten ließen, dass an anderer Stelle im SSL/TLS-Ökosystem weitere Gefahren lauern könnten. Nachdem er den Fehler entdeckt und seine Auswirkungen erkannt hatte, warnte Google einige Infrastrukturunternehmen wie CloudFlare vor dem Fehler - machte ihn jedoch nicht publik oder meldete ihn den Behörden.
Die zweite Detektion erfolgte nur wenige Wochen später bei Codenomicon, einem finnischen Cybersicherheitsunternehmen. Die Firma arbeitete an einem Produkt namens Safeguard, das für Penetrationstests von Verschlüsselungs- und Authentifizierungs-Tools entwickelt wurde. Beim Test von Safeguard in der eigenen Infrastruktur entdeckten die Sicherheitsexperten, dass sie auf schockierend große Datenmengen zugreifen konnten.
Codenomicon ging dabei ganz anders vor als Google: Sie machten ihre Entdeckung nicht nur öffentlich, sondern gaben ihr auch ein eigenes Branding (PDF): Sie waren diejenigen, die die Sicherheitslücke auf den Namen Heartbleed tauften und sogar ein eigenes Logo für sie entwarfen. Heartbleed war auch eines der ersten Beispiele dafür, wie ein Security-Unternehmen die Entdeckung einer Sicherheitslücke in eine Marketingmöglichkeit verwandeln kann. Heartbleed läuft unter der CVE-ID CVE-2014-0160.
Publishing security advisories on updating broken OpenSSL versions did not help much. Only when #heartbleed happened people started updating the software. Lesson: get a logo! #SuRI18 pic.twitter.com/H1vsZOdFvE
— Bogdan Kulynych ???? (@hiddenmarkov) June 18, 2018
Heartbleed - Code
Eine einzige OpenSSL-Codezeile enthält den Fehler, der für den Heartbleed Bug ursächlich ist:
memcpy(bp, pl, payload);
memcpy() ist der Befehl, der Daten kopiert. bp ist der Ort, an den kopiert wird, pl der, von dem kopiert wird und payload die Länge der kopierten Daten. Wie wir gesehen haben, besteht das Problem darin, dass nie versucht wird, zu überprüfen, ob die Datenmenge in pl gleich dem angegebenen Wert von payload ist.
Die größte Ironie dabei: OpenSSL ist eine Open-Source-Software. Jeder könnte sich den Code ansehen und vermutlich haben das auch Hunderte getan - aber bis Mehta und das Codenomicon-Team darüber gestolpert sind, hat niemand den (ziemlich elementaren) Programmierfehler bemerkt. Und da bei Open-Source-Projekten wie OpenSSL die Mitwirkenden genauestens erfasst werden, ist sogar bekannt, wer Schuld hat: der deutsche Softwareentwickler Robin Seggelman, der maßgeblich zum OpenSSL-Projekt beigetragen hat.
Heartbleed Exploits - Opfer & Kosten
Die Heartbleed-Schwachstelle wurde in der Praxis ausgenutzt, wobei nicht klar ist, ob das bereits vor Bekanntwerden des Bugs passiert ist. Es ist möglich, dass einige Angriffsversuche, die von Sicherheitsunternehmen bereits 2013 entdeckt wurden, auf Heartbleed abzielten. Dabei stehen Vermutungen im Raum, es könnte sich bei den Angreifern um staatliche Sicherheitsbehörden gehandelt haben.
Nach der Detektion durch Codenomicon im April 2014 herrschte hektische Betriebsamkeit und auch ein gewisses Chaos, als sich Unternehmen weltweit bemühten, ihre Systeme zu aktualisieren. So wurde beispielsweise Yahoo- und OKCupid-Nutzern kurzzeitig geraten, sich nicht in ihre Konten einzuloggen, bis diese Dienste ihre OpenSSL-Installationen gepatcht hatten - und ihre Passwörter zu ändern, sobald sie wieder Zugang erhielten.
Dennoch konnten kriminelle Hacker die Sicherheitslücke in mehreren Fällen ausnutzen. Ein Angriff auf den Krankenhausbetreiber Community Health Systems, bei dem Patientendaten gestohlen wurden, wurde Heartbleed genauso zugeschrieben, wie der Diebstahl von Hunderten von Sozialversicherungsnummern bei der kanadischen Steuerbehörde.
Schätzungen des Security Magazine zufolge könnten sich die Kosten, die Heartbleed im Unternehmensumfeld verursacht hat, auf bis zu 500 Millionen Dollar belaufen - allein dafür, SSL-Zertifikate zu widerrufen und zu ersetzen. Rechnet man die Arbeitsstunden hinzu, die für die Überprüfung und Aktualisierung der Systeme erforderlich waren, ergibt sich ein enormer Anstieg der Ausgaben, der direkt mit dem Heartbleed Bug in Verbindung gebracht werden kann.
Heartbleed Bug - Behebung
Die Heartbleed-Schwachstelle wurde mit Version 1.0.1g der OpenSSL-Bibliothek behoben, die am 8. April 2014 veröffentlicht wurde. Aktuelle Informationen und Code finden Sie auf der OpenSSL-Website.
Weil OpenSSL quelloffen ist, können Sie sich den Code zur Behebung der Schwachstelle jederzeit ansehen:
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->relent)
return 0;
/* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0;
/* silently discard per RFC 6520 sec. 4 */
pl = p;
Der erste Teil dieses Codes stellt sicher, dass die Heartbeat-Anfrage nicht 0 KB groß ist, was zu Problemen führen kann. Der zweite Teil stellt sicher, dass die Anforderung tatsächlich so lang ist, wie angegeben.
Heartbleed - immer noch ein Problem?
In Anbetracht der Tatsache, dass Heartbleed vor mehr als acht Jahren entdeckt und gepatcht wurde, sind Sie vielleicht überrascht zu erfahren, dass viele Server immer noch anfällig für den Heartbleed Bug sind. Laut einem Forscher des SANS Internet Storm Center waren im November 2020 über 200.000 solcher Server online. Auch wenn diese Zahl seitdem wahrscheinlich etwas gesunken ist, gibt es mit Sicherheit noch eine Reihe anfälliger Server, die darauf warten, gehackt zu werden.
Erfahrene Sicherheitsprofis wird diese Erkenntnis wahrscheinlich nicht überraschen - es kommt nur allzu oft vor, dass Unternehmen ihr Patch Management vernachlässigen, aus Nachlässigkeit oder um Ausfallzeiten bei geschäftskritischen Systemen ohne Backups zu vermeiden. Dabei sollten Schwachstellen wie Heartbleed ein Weckruf sein und längst deutlich gemacht haben, wie wichtig ein robustes Patch-Management-Programm ist.
Heartbleed entdecken - Online-Schwachstellentest
Sie können Ihre Server ganz einfach mit kostenlosen Online-Tools auf die Heartbleed-Schwachstelle testen. Zum Beispiel mit dem kostenlosen, webbasierten Test von pentest-tools.com. Hierzu geben Sie einfach die entsprechende URL ein, um festzustellen, ob ein Server ordnungsgemäß für Heartbleed und eine Reihe anderer Sicherheitslücken gepatcht wurde.
Wenn Sie feststellen, dass einer Ihrer Server verwundbar ist, reicht es nicht aus, nur den OpenSSL-Code zu aktualisieren. So sollten Sie beispielsweise die von den Servern verwendeten SSL-Zertifikate ändern, da diese möglicherweise kompromittiert worden sind, ohne dass dabei Spuren hinterlassen wurden. Eher umständlich, aber dennoch wichtig: Benutzer, die Konten auf dem System haben, sollten ihre Passwörter ändern.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.
