Was OpenSSL alles verraten kann

Die Heartbleed-Katastrophe: Wie funktioniert der Angriff und was kann passieren?
Kommentare

Der Heartbleed-Bug in OpenSSL ist eine äußerst kritische Schwachstelle. Oder wie es Krypto-Guru Bruce Schneier so schön formuliert hat: „“Catastrophic“ is the right word. On the scale of 1 to 10, this is an 11.“

Aber wieso eigentlich?

Heartbeat – Ein Herzschlag hält die Verbindung aufrecht

Für mit TLS geschützte Verbindungen gibt es die Heartbeat-Funktion, welche dazu dient, die Verbindung aufrecht zu halten, auch wenn sie gerade nicht benutzt wird. Dazu werden Heartbeat-Requests an den Kommunikationspartner geschickt. Diese Requests bestehen aus zufälligen Daten (der sogenannten Payload) und einem Feld, das die Länge dieser Daten enthält. Empfängt einer der Kommunikationspartner (egal ob Client oder Server) einen Heartbeat-Request, muss er mit den gleichen zufälligen Daten antworten, die er empfangen hat.

Wenn im Folgenden vom Server die Rede ist, kann genauso gut auch ein Client angegriffen werden. Auf dem Client sind aber im Allgemeinen weniger Daten auszuspähen und die Folgen eines Angriffs beschränken sich vor allem auf den betroffenen Benutzer. Bei einem Angriff auf einem Server hingegen sind potentiell alle seine Benutzer betroffen.

Heartbleed – OpenSSL war zu vertrauensselig

Die Heartbleed-Schwachstelle in OpenSSL besteht darin, dass die Längenangabe ungeprüft übernommen und verwendet wird. Empfängt ein Server einen Heartbeat-Request, reserviert OpenSSL entsprechend dem Wert im Längenfeld einen Puffer. Danach werden die Daten gemäß diesem Wert aus der Eingabe in den Puffer kopiert. Gibt ein Angreifer eine größere Länge an als die von ihm gesendete Payload tatsächlich umfasst, werden die hinter der Payload liegenden Speicherbereiche in den Puffer kopiert.

Wird zum Beispiel die Payload-Länge mit 64KB angegeben (das ist der Maximalwert), obwohl nur wenige Byte Payload gesendet werden, werden knapp 64KB des vorhandenen Speichers in den Puffer kopiert – samt der zuvor darin enthaltenen, möglicherweise sensitiven Daten. Nach dem Kopieren der Daten wird der gefüllte Puffer dann als Antwort auf den Heartbeat-Request an den Client gesendet.

Sehr schön wird das in diesem xkcd-Cartoon illustriert.

Aufmacherbild: Heartbleed bug von shutterstock.com / Urheberrecht: wwwebmeister

[ header = Seite 2: Was OpenSSL alles verraten kann ]

Was OpenSSL alles verraten kann

Zusätzlich verschärft wird das Problem dadurch, dass OpenSSL seinen Speicher selbst verwaltet und deshalb immer größere Speichermengen auf einmal reserviert. Dadurch werden bei einem Angriff nur Daten von OpenSSL an den Angreifer geschickt. Und die können sehr wichtig sein. Ausgespäht werden können zum Beispiel:

  • … der private Schlüssel des Servers (was mehrfach bewiesen wurde). Wer den privaten Schlüssel kennt, kann sich als der betreffende Server ausgeben.
  • … über TLS empfangene Benutzernamen und Passwörter (was am Beispiel von Yahoo! Mail demonstriert wurde). Wer die kennt, kann sich damit natürlich anmelden.
  • … Session-Cookies (gezeigt am Beispiel von Flickr). Mit dem Session-Cookie kann der Angreifer eine laufende Sitzung eines Benutzers übernehmen.
  • … die aus dem Schlüssel abgeleiteten so genannten CRT-Parameter, die vom Server verwendet werden, um die späteren Berechnungen der Krypto-Funktionen zu beschleunigen (siehe eine Analyse eines Patches von Akamai und Akamais Antwort). Wer diese Parameter kennt, kann daraus den privaten Schlüssel berechnen.

Der Angreifer kann allerdings nicht bestimmen, was ihm der Server schickt – er muss nehmen, was kommt. Hat er Glück, landet er einen der Haupttreffer und bekommt privaten Schlüssel oder CRT-Parameter frei Haus. Hat er Pech, gibt es nur Datenmüll. Dazwischen liegen dann Informationen wie Zugangsdaten irgendwelcher Benutzer und ähnliches.

Besonders unangenehm ist die Schwachstelle auch, weil der Angriff keine Spuren auf dem Server hinterlässt. Es werden keine Dateien angelegt oder verändert, der Angriff erfolgt komplett über das Netzwerk. Lediglich in Logfiles tauchen verräterische Heartbeat-Requests auf – vorausgesetzt, diese werden ausführlich protokolliert, was eigentlich nicht üblich ist.

Es gab bereits Angriffe

Die Electronic Frontier Foundation (EFF) hat Hinweise darauf, dass ein Botnet die Schwachstelle bereits im November 2013 ausgenutzt hat.

In einem Logfile wurden Einträge gefunden, die mit denen eines aktuellen Proof-of-Concept-Exploits für die Heartbleed-Schwachstelle identisch sind. Die Requests kamen von IP-Adressen, die zu einem Botnet gehören, und zwar zu einem, das systematisch versucht hat, die IRC-Kommunikation auf Freenode und einer Reihe weiterer IRC-Netzwerke zu sammeln – was dafür spricht, dass ein Geheimdienst hinter den Angriffen steckt. Was sollten Cyberkriminelle mit Chat-Protokollen?

Der Zeitraum „November 2013“ ist dabei nur ein Hinweis darauf, wann die Angriffe spätestens begannen. Sie können durchaus auch schon noch länger laufen, zufällig liegen Logfiles mit verdächtigen Einträgen aus dem November 2013 vor. Vielleicht finden sich ja auch noch ältere Logfiles mit verdächtigen Einträgen.

Zwei weitere Angriffe wurden nach der Veröffentlichung der Patches gemeldet.

  • Die britische Website Mumsnet hat gemeldet, dass bei ihr Passwörter ausgespäht wurden. Der Angriff wurde bemerkt, als sich jemand mit den Zugangsdaten einer der Gründerinnen der Website angemeldet und eine Nachricht geposted hat. Danach wurde den Betreibern mitgeteilt, dass die Zugangsdaten über die Heartbleed-Schwachstelle ausgespäht wurden. Ob das stimmt, weiß man natürlich nicht.
  • In Kanada meldete die Steuerbehörde einen Angriff, bei dem die Sozialversicherungsnummern von ca. 900 Steuerzahlern „entfernt“ wurden („removed from CRA systems by someone exploiting the Heartbleed vulnerability“). Ob und wenn ja welche weiteren Daten betroffen sind, wird zur Zeit noch untersucht. Das Ausspähen von Daten mit „Entfernen“ zu umschreiben, ist etwas merkwürdig, das klingt ja eher nach „Löschen“. Aber es scheinen tatsächlich Daten ausgespäht worden zu sein, zumindest hat die Royal Canadian Mounted Police einen Verdächtigen verhaftet, dem vorgeworfen wird, die Daten ausgespäht zu haben: „[…] was able to extract private information held by the CRA by exploiting the security vulnerability known as the Heartbleed Bug.“

[ header = Seite 3: OpenSSL auf Clients ]

OpenSSL auf Clients

Für Clients sind die Auswirkungen der Schwachstelle nicht so kritisch wie für Server. Viele Programme und Systeme sind gar nicht von der Schwachstelle betroffen: Windows verwendet eine eigene Krypto-Bibliothek, ebenso Mozilla und Googles Chrome. Auch Mac OS X ist nicht betroffen, unter Linux und *BSD kommt es darauf an, welche OpenSSL-Version installiert ist. Betroffen sind die OpenSSL-Releases 1.0.1 (bis einschließlich 1.0.1f) und 1.0.2-beta (bis einschließlich 1.0.2-beta1). Die Schwachstelle wurde in Version 1.0.1g behoben. Für 1.0.2-beta wird der Patch in Version 1.0.2-beta2 enthalten sein.

Ähnlich gut sieht es bei den Smartphones aus: iOS und Windows Mobile sind gar nicht betroffen, von Android ist es nur Version 4.1.1. Für möglicherweise anfällige Android-Geräte steht mit dem Heartbleed Detector von Lookout ein Tool zum Test der Schwachstelle zur Verfügung. Laut der damit gesammelten Daten ist ein betroffenes Gerät vor allem in Deutschland populär. Welches, wird leider nicht verraten.

Smartphone-Apps können auch indirekt betroffen sein: wenn die von ihnen genutzten Webservices etc. für die Schwachstelle offen sind. Trend Micro hat bei einem Test von rund 390.000 Apps aus Google Play 1.300 Apps gefunden, die sich mit anfälligen Servern verbinden. Bei einem erneuten Test wurden sogar rund 7.000 betroffene Apps entdeckt. Das ist aber im wesentlichen ein Problem der Entwickler und Server-Betreiber, die Benutzer müssen lediglich ggf. Updates installieren und/oder Passwörter ändern.

Eine Gefahr droht ansonsten immer dann, wenn entweder zum Beispiel unter Mac OS X die anfällige OpenSSL-Version nachinstalliert wurde oder ein Programm oder eine App eine betroffene OpenSSL-Version enthält. Im ersten Fall muss der Benutzer selbst für ein Update von OpenSSL sorgen. Aber wer so ein doch ziemlich spezielles Programm installiert, wird schon darauf achten, dass es aktuell bleibt. Kritischer sind gebundlete Versionen – wer weiß schon, welches der Programme auf seinem Rechner und welche App auf seinem Smartphone welche Komponenten enthält? Hier gilt es, auf Informationen durch die Entwickler zu warten.

Angriffe auf Clients

Wenn im Folgenden von (Desktop-)Programmen die Rede ist, sind analog auch Smartphone-Apps gemeint.

Clients sind deutlich weniger gefährdet als Server, denn Angriffe sind nur auf laufende OpenSSL-Installationen möglich. Das läuft darauf hinaus, dass auf dem Client ein laufendes Programm eine betroffene OpenSSL-Version nutzen muss. Außerdem muss sich dieses Programm mit einem Server unter der Kontrolle des Angreifers verbinden.

Ein Angreifer müsste das Opfer also dazu bringen, so eine Verbindung aufzubauen, was im Zweifelsfall kein all zu großes Problem sein dürfte. Das könnte zum Beispiel vergleichbar einer Drive-by-Infektion über präparierte Websites, als Man-in-the-Middle oder über entsprechende Links in E-Mails passieren.

Danach kann der Angreifer Daten aus dem Speicher des Clients ausspähen. Genauer: aus dem von OpenSSL genutzten Speicher. Die entscheidende Frage ist also: Was kann der Angreifer denn darin finden? Nicht besonders viel.

Während auf Servern viele parallele Verbindungen gleichzeitig offen sind und dadurch die Daten vieler Benutzer im Speicher von OpenSSL abgelegt sind, gibt es auf den Clients deutlich weniger Verbindungen und damit weniger Möglichkeiten, Daten auszuspähen. Vor allem gibt es auf den wenigsten Clients Client-Zertifikate und damit private Schlüssel zum Ausspähen.

Natürlich könnten diese Client-Zertifikate für bestimmte Angreifer sehr interessant sein. Vielleicht sogar so interessant, dass sie gezielte Angriffe zum Ausspähen dieser Client-Zertifikate starten. Aber dann dürfte eingeschleuste Spyware schneller zum Ziel führen als ein Angriff über die Heartbleed-Schwachstelle.

[ header = Seite 4: Spezialfall „Internet der Dinge“ ]

Spezialfall „Internet der Dinge“

Ein Problem könnte die Heartbleed-Schwachstelle für das „Internet der Dinge“ werden. Router, Telefonanlagen und viele andere Geräte können die betroffenen OpenSSL-Versionen verwenden. Verbindet sich eines dieser Geräte mit einem bösartigen Server oder nimmt es Anfragen von einem bösartigen Client an, kann der Angreifer über die Heartbleed-Schwachstelle Daten ausspähen – wenn denn welche da sind, die sich auszuspähen lohnen.

Das größte Problem in diesem Fall sind die notwendigen Updates. Mit Ausnahme der (SOHO-)Router, für die durch die vielen Angriffe in letzter Zeit des Öfteren neue Firmware-Versionen veröffentlicht und auch installiert wurden, sieht es bei Firmware-Updates doch im Allgemeinen sehr traurig aus. Oft gibt es gar keine, und selbst wenn es sie gibt, werden sie meist nicht installiert, weil die meisten Benutzer nicht einmal wissen, dass es ein Update gibt.

So lange auf diesen Geräten „nichts zu holen ist“, ist das kein größeres Problem. Es wird wahrscheinlich nie Angriffe darauf geben – was hätten die Angreifer davon? Falls aber zum Beispiel auf Routern Zugangsdaten ausgespäht oder in Spielekonsolen oder Fernsehern virtuelle Währungen „geklaut“ werden können, könnte sich das ändern. Denn wenn die Cyberkriminellen hinter etwas her sind, dann sind es alle möglichen Zugangsdaten und jede Form von Geld.

Andererseits fahren die Cyberkriminellen mit ihrer Spyware und den Onlinebanking-Trojanern anscheinend sehr gut. Angriffe auf noch so smarte Geräte dürften sich daher kaum lohnen. Wozu sich etwas Neues ausdenken, wenn die bewährten Schädlingsbaukästen zum gleichen Ziel führen?

Akut gefährdet könnten allenfalls Router sein, sofern sie eine betroffene OpenSSL-Version nutzen und die Fernwartung aktiviert ist. Denn die wird im Allgemeinen über SSL/TLS abgesichert. Wenn möglich, sollten Sie die betroffenen Geräten ausschalten. Ob Ihr Router betroffen ist, können Sie zum Beispiel hier testen – Sie müssen nur Ihre öffentliche IP-Adresse eingeben.

Die Heartbleed-Katastrophe Teil 1: Wie funktioniert der Angriff und was kann passieren? Teil 2: Was Unternehmen über Heartbleed wissen müssen – und wie Sie jetzt reagieren sollten Teil 3: Was Privatpersonen über Heartbleed wissen müssen – und wie sie jetzt reagieren sollten

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -