OpenSSL Heartbleed - Was ist da eigentlich los?

Falls Ihnen Heartbleed gar nichts sagt, raten wir DRINGEND dazu, mindestens die Empfehlungen am Ende des Artikels zu lesen. Für alle anderen haben wir eine kleine Zusammenfassung zum OpenSSL Bug Heartbleed erstellt, mit Erklärungen was Heartbleed ist, wie der Exploit funktioniert, wer betroffen war (und immer noch ist) sowie Maßnahmen gegen die Auswirkungen des Bugs.

Blutet Ihnen auch das Herz? Dann sind Sie entweder Kryptologe oder Sie wurden vom Heartbleed Bug getroffen. Wir leiden in beiden Fällen mit Ihnen. Als Sicherheitsexperten, die insgeheim gehofft haben, einen solch massiven Sicherheitsvorfall nie erleben zu müssen und als Anbieter von Produkten, die ebenfalls betroffen waren.

Was ist Heartbleed?

Heartbleed ist die Bezeichnung für einen sehr schwerwiegenden Bug in der SSL/TLS Library OpenSSL. Die Bezeichnung wurde gewählt als Anspielung auf einen Programmierfehler in dem Feature, welches den Bug verursacht hat (SSL/TLS Heartbeat – RFC 6520). Der Name ist aber auch eine Anspielung darauf, dass Sicherheitsexperten das Herz blutet bei den massiven Auswirkungen, die dieser Bug hat.

Wann wurde das Problem öffentlich bekannt?

Das geschah am 07.04.2014, durch die Veröffentlichung eines Security Advisory von OpenSSL: https://www.openssl.org/news/secadv_20140407.txt. In diesem Advisory war jedoch noch gar nicht abzusehen, welche massiven Wellen Heartbleed schlagen würde. Die Warnung in dem Advisory war auch deutlich zu schwach formuliert.

Wie entstand der Fehler?

Ein Programmierer (einer der Autoren des RFC 6520) hat Teile des TLS Heartbeat Features implementiert und dabei einen schwerwiegenden Fehler gemacht. Diese Art von Programmierfehler ist bei der Verwendung der Programmiersprache C seit Jahren bekannt, dennoch tritt der Fehler immer wieder auf. Im Wesentlichen handelt es sich um eine unzureichende Prüfung von Parametern (siehe weiter unten – wie funktioniert der Heartbleed Bug). Der Programmierer wurde daraufhin hart kritisiert und es kursierten Gerüchte über eine absichtlich eingefügte Backdoor. Beweise dafür gibt es bislang jedoch keine.

Wer ist vom Heartbleed Bug betroffen?

JEDER, der ein Produkt verwendet, welches die folgenden Versionen der OpenSSL Library verwendet: OpenSSL 1.0.1 - 1.0.1f (Ausnahme: OpenSSL 1.0.1g). Frühere Versionen sind nicht betroffen. Das Problem ist, dass man als Anwender einer Software nicht weiß, ob OpenSSL in einem Produkt verwendet wird und welche Version. In der Folge des Bugs stellte sich heraus, dass nicht nur Webserver (Apache, etc.) betroffen waren, sondern auch eine ganze Reihe namhafter Hersteller von Sicherheitsprodukten, die eine der oben erwähnten Versionen von OpenSSL eingesetzt hatten.

Wie funktioniert der Heratbleed Bug?

Es gibt inzwischen viele Beschreibungen im Internet, die das Prinzip in jeder beliebigen Detailtiefe erklären.

Wir wollen versuchen, Ihnen das Problem anhand eines einfachen, bildhaften Ansatzes zu verdeutlichen.

Das TLS Heartbeat Feature wurde ursprünglich dafür entwickelt, um eine TLS Verbindung über UDP (DTLS) „offen“ zu halten, bzw. zu prüfen, ob die Verbindung zum Zielsystem noch besteht. Das ist sinnvoll und notwendig, da UDP, im Gegensatz zu TCP, keinerlei eingebaute Mechanismen dafür bietet. Für „normale“ TLS Verbindungen (z.B. HTTPS) wäre das Heartbeat Feature nicht notwendig, es wurde in OpenSSL jedoch auch für TCP implementiert. Durch den Programmierfehler waren dadurch auch alle Systeme betroffen, die TLS über TCP implementieren, nicht nur Systeme, die DTLS (UDP) verwenden. Die Zahl Letzterer wäre überschaubar gewesen.

Die sehr vereinfachte Darstellung des TLS Heartbeat sieht wie folgt aus:

Fachartikel TLS Heartbeat Übersicht_1

Der Client baut eine TLS Verbindung auf (TLS Tunnel / blau) und übermittelt in einem Heartbeat REQUEST angeblich 5000 Byte. Tatsächlich hat der Client aber nur das Längenfeld auf 5000 Byte gesetzt und lediglich 1 Byte geschickt. Der Server prüft, ob der Client berechtigt ist den Heartbeat anzufordern (per Default sind das alle Clients) und liefert dann 5000 Byte an Daten zurück.

Und genau hier wird es interessant! Die 5000 Byte an Daten beschafft sich der Server mittels der OpenSSL Library durch Allokation von Speicher in seinem Adressraum. Er prüft dabei NICHT, ob er die 5000 Byte vom Client auch tatsächlich erhalten und gespeichert hat.

Durch diese Situation ergibt sich ein klassischer Buffer-Overrun im Server, wodurch auf "interessante" Daten im Speicherbereich des Server-Prozess zugegriffen werden kann.

Diese interessanten Daten können viele „spannende Dinge“ enthalten, wie die folgenden Bilder zeigen. HINWEIS: Diese Darstellung ist DEUTLICH vereinfacht, um es auch nichttechnischen Lesern zu ermöglichen, der Erklärung zu folgen. Die tatsächlichen Zusammenhänge sind deutlich komplexer, gehen jedoch über das hinaus, was wir hier zeigen wollen.

Fachartikel TLS Heartbeat Übersicht_2

Der TLS Server (in diesem Beispiel ein Webserver) speichert Daten im Stack und im Heap. Dort werden Daten zur TLS Session, aber auch andere Daten des Prozess abgelegt. Beim Webserver sind das z.B. TLS Session Daten, der TLS Private Key, Session-IDs, User Accounts, usw.

Fachartikel TLS Heartbeat Übersicht_3

Im Heap speichert der Server auch die Heartbeat Daten des Clients, wobei er jedoch NICHT prüft, ob die Menge der vom Client gesendeten Daten mit der angegebenen Länge übereinstimmt. Wenn der Client vorgibt, 5000 Byte (64 Kbyte bei einem Angriff) geschickt zu haben, wird der Server diese Menge an Daten zum Client zurück schicken. Er kopiert dabei die angeforderte Menge an Bytes ab der Stelle im Heap, wo die Client-Daten (in unserem Beispiel nur 1 Byte – siehe oben) gespeichert wurden.

Fachartikel TLS Heartbeat Übersicht_4

Dadurch greift der Server-Prozess auf Daten zu, die mit dem Heartbeat nicht in Verbindung stehen. Dies können weitere Daten der TLS Session sein, wie z.B. der Private Key oder User Accounts (Name/Passwort) und Session-IDs aktiver Web-Sessions.

Da jede TLS Session von einer anderen Instanz des Servers (Thread) bearbeitet wird, erhält man durch mehrmalige Nutzung der Heartbeat Funktion, Stück für Stück, immer mehr Daten aus dem RAM des Server-Prozesses. In unseren Tests dauerte es nur wenige Sekunden/Minuten, um eine Session ID zu erhalten und ca. 0,5 h um den Private Key zu erhalten.

Fachartikel TLS Heartbeat Übersicht_4

Ein Angreifer könnte diese Lücke seit ca. zwei Jahren unbemerkt ausnutzen, da der Buffer-Overrun keine Spuren im System hinterlässt.

Kann man mit Hilfe des Bugs wirklich Schaden anrichten?

Oh Ja, das kann man! Falls man den Private Key erhält, kann man eine „Man in the Middle“ Attacke durchführen, die jedoch mit einem gewissen Aufwand verbunden ist. Einfacher ist es, sich mittels einer Session-ID oder eines User Accounts am betroffenen Server zu authentisieren und dort auf Daten zuzugreifen. Der Begriff Server steht hier allgemein für TLS Server. Vom Heartbleed Bug konkret betroffen waren: Webserver (Apache, usw.) Admin-GUIs verschiedener Produkte SSL VPNs (Kommerzielle Produkte und Open Source) SSL Proxies (SSL Offloading) Mailserver und Mailrelays (STARTTLS) und viele mehr ... Die Vielzahl der betroffenen Produkte ist erstaunlich und das Ausmaß des tatsächlichen Schadens kann heute noch gar nicht richtig eingeschätzt werden.

Empfehlungen für die weitere Vorgehensweise

Wie kann man feststellen, ob man betroffen ist?

In der Zwischenzeit gibt es viele Dienste im Internet, die eine Überprüfung von Webseiten anbieten. Die Suchmaschine Ihrer Wahl gibt hierzu Auskunft (suchen Sie nach: heartbleed check). Alternativ können Sie den Test mit dem folgenden Perl Script selbst durchführen https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl HINWEIS: Das Script selbst richtet keinen Schaden an, aber es gibt Systeme, die sich beim Scan aufgehängt haben (z.B. HP iLO). Verwenden Sie das Script nur nach Absprache mit den beteiligten Personen in Ihrem Unternehmen.

Muss man jetzt überhaupt noch etwas tun, da "alle Systeme" gepatcht wurden?

Ob wirklich alle Systeme gepatcht wurden, möchten wir bezweifeln. Es gibt noch sehr viele Systeme im Internet, die anfällig sind. Auch einige Hersteller sind sich noch nicht ganz schlüssig, ob ihre Produkte von dem Problem betroffen sind oder nicht. Zudem kann es passieren, dass man in der eigenen Infrastruktur möglicherweise Systeme übersieht.

Wir empfehlen daher:

  • Priorität #1: Verschaffen Sie sich bitte umgehend eine Übersicht über alle Systeme die aus dem Internet via SSL angesprochen werden (nicht nur über Port 443). Im Zweifelsfall lassen Sie Ihren externen Adressbereich nach offenen Ports scannen! Prüfen Sie diese Systeme entweder durch Supportanfragen beim Hersteller oder durch die oben erwähnten Methoden.
  • Priorität #2: Verschaffen Sie sich bitte auch eine Übersicht über alle Systeme, die intern via SSL angesprochen werden. Prüfen Sie auch diese Systeme.

Für alle betroffenen Systeme sind folgende Dinge zu tun:

  • Spielen Sie Patches ein. Falls noch kein Patch verfügbar ist, ergreifen Sie geeignete Maßnahmen, um die Systeme, die aus dem Internet ansprechbar sind, zu schützen. Das kann durch ein IDS Pattern auf der Firewall geschehen, oder durch SSL Offloading an einer Firewall bzw. an einem Loadbalancer, die nicht betroffen sind. Sollte Ihnen diese Möglichkeit nicht zur Verfügung stehen, prüfen Sie, ob das System vom Netz genommen werden kann, bis ein Patch zur Verfügung steht. Systeme, die aus dem Internet ansprechbar sind, sind seit Bekanntwerden des Problems stark gefährdet!
  • Ersetzen Sie die SSL Zertifikate auf allen betroffenen Systemen!
  • Ändern Sie die Passworte ALLER Admin Accounts!
  • Ändern Sie die Passworte ALLER User Accounts!
  • Aktivieren Sie PFS (Perfect Forward Secrecy), falls Ihr Produkt diese Funktion anbietet.
  • Prüfen Sie, ob in den Logdaten ungewöhnliche Zugriffe erkennbar sind (z.B. Zugriffe zu ungewöhnlichen Zeiten oder aus ungewöhnlichen Regionen). Diese Aufgabe ist sehr zeitaufwendig, kann aber hilfreich sein bei der Einschätzung eines möglichen Schadens und einer daraus resultierenden weiteren Gefährdung
Wie kann man sich gegen so ein Problem in Zukunft besser schützen?

Die schlechte Nachricht zuerst: Gegen das Problem selbst, also einen Softwarebug mit massiven Auswirkungen auf die Sicherheit, kann man sich prinzipiell nur schwer bzw. gar nicht schützen, weil man die Art des Bugs und die Verbreitung der betroffenen Software vorher nicht kennt. Erst bei Bekanntwerden des Bugs kann man entsprechende Maßnahmen ergreifen. Die gute Nachricht lautet: Man kann den Impact, also die Auswirkungen eines solchen Bugs, mindern, indem man sich konsequent an wenige, aber seit langem gültige Prinzipen hält.

Die folgenden Prinzipien und Vorschläge mögen in Zeiten von Web 2.0, NextGen Firewalls und der bemannten Mars Mission möglicherweise altbacken klingen, aber sie waren und sind der Schlüssel für eine ordentliche Security-Strategie!

  • Wo immer möglich: KISS – Keep it simple and stupid. Ein Angriff auf komplexe Systeme kann mehr Schaden anrichten, als ein Angriff auf Systeme mit wenigen, klar definierten bzw. aufgeteilten Funktionen.
  • Separieren Sie Systeme voneinander (klassische DMZ mit mehreren Zonen), um die Auswirkungen eines Angriffs zu isolieren.
  • Verwenden Sie Zwei-Faktor Authentisierung (z.B. RSA Token – http://www.rsa.com). Das verhindert zwar die Attacke nicht, erspart Ihnen aber das Zurücksetzen der User-Passworte, was sich bei mehreren hundert Anwendern als schwierig herausstellen kann.
  • Nutzen Sie IDS/IPS-Systeme. Auch diese helfen nicht den Angriff zu stoppen, solange er noch nicht bekannt ist, aber danach können IDS/IPS Pattern helfen, die Lage schneller in den Griff zu bekommen. Es hat sich gezeigt, dass die Pattern für den Bug wesentlich schneller verfügbar waren, als die Patches der betroffenen Produkte. Palo Alto (http://www.paloaltonetworks.com/) hat innerhalb von zwei Tagen ein Pattern zur Verfügung gestellt und damit die Systeme hinter der Firewall (DMZ) geschützt. Erste Patches der Hersteller waren erst 3-4 Tage später verfügbar.
  • Testen Sie Ihre Systeme regelmäßig auf Schwachstellen. Auch das garantiert nicht, dass ein bislang unbekannter Bug gefunden wird, aber in der Praxis führen Design- und Konfigurationsfehler wesentlich häufiger zu Sicherheitsproblemen, als Security Bugs dieses Ausmaßes. Wir kooperieren mit Whitehat Hackern und stellen gern den Kontakt her, falls Sie Ihre Systeme prüfen lassen wollen.
  • Setzen Sie auf eine Multi-Vendor Strategie. Im Fall eines Fehlers stehen die Chancen gut, dass nicht alle Hersteller gleichermaßen betroffen sind. Unsere Managed Services konnten wir noch am Tag des Bekanntwerdens von Heartbleed durch diese Strategie schützen, indem wir für die betroffenen Systeme das SSL Offloading auf Loadbalancer von F5 (http://www.f5.com) sowie Riverbed (http://www.riverbed.com) verlagert haben. Diese beiden Produkte waren nicht von Heartbleed betroffen, da sie OpenSSL (in unserem Setup) nicht verwenden.
  • Inventarisieren Sie Ihre Produkte und Anwendungen. Ohne dieses Inventar können Sie im Notfall nicht schnell genug reagieren und die betroffenen Systeme identifizieren bzw. schützen (durch Patches, oder andere Maßnahmen). Produkte wie Greenbone (http://www.greenbone.de/) unterstützen Sie dabei.
  • Erstellen Sie ein Notfallhandbuch, damit Sie im Notfall nicht erst überlegen müssen, wer informiert werden muss und was konkret zu tun ist.
  • Abonnieren Sie CERT-Meldungen, damit Sie von solchen Problemen nicht erst zwei Tage später aus dem Radio hören.
  • Informieren Sie Ihre Anwender,  dass in der Folge des Bugs mit verstärkten Phising Mails zu rechnen ist, die versuchen, die Unwissenheit mancher Anwender auszunutzen, indem sie aufgefordert werden, Ihre Passworte durch einen Klick auf obskure Links zu ändern.

Wenn Sie die meisten dieser Maßnahmen umsetzen, stehen die Chancen gut, dass Sie den nächsten Vorfall – und der wird kommen – besser überstehen und schneller wieder Safe sind.

Falls Sie bei einigen dieser Punkte Unterstützung benötigen: wir beraten Sie gern.