© DrHitch/Shutterstock.com
Websecurity

1 Angriffe in OpenSSL und SSL/TLS


Noch nie war es mit der Sicherheit im Internet so schlecht bestellt wie 2014. Jedenfalls gewinnt man diesen Eindruck, wenn man die ganzen Vorfälle im vergangenen Jahr betrachtet. Inzwischen gibt es sogar eine Website, die laufend die Frage „Is The Internet On Fire?“ beantwortet [1]. Ganz vorne mit dabei: OpenSSL und SSL/TLS allgemein. Wir blicken zurück.

Zwar steht nicht das ganze Internet in Flammen, aber es kokelt doch an etlichen Ecken. Leider mal wieder an vorderster Front involviert: SSL/TLS. Dass das dafür verwendete Zertifizierungssystem eher einem brennenden Kartenhaus als der nötigen stabilen Festung gleicht, mussten wir ja schon 2011/2012 zur Kenntnis nehmen [2]. 2014 waren erneut die Protokolle selbst sowie ihre Implementierungen die Quelle des Übels. Los ging es mit OpenSSL und ganz viel Herzblut.

Der Heartbleed-Bug in OpenSSL

Am 7. April 2014 wurde von OpenSSL ein Security Advisory [3] zu einer neu behobenen Schwachstelle mit der CVE-ID CVE-2014-0160 [4] veröffentlicht, die folgendermaßen beschrieben wurde: A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

Eine parallel veröffentlichte Website [5] einiger Entdecker des Sicherheitsrisikos machte dann schnell deutlich, dass die Schwachstelle das Potenzial hat, zu einem großen Problem zu werden. Nebenbei bekam die Entdeckung im Gegensatz zu den meisten anderen sogar einen eigenen Namen: Heartbleed-Bug.

Der Heartbleed-Bug basiert auf einer fehlenden Bereichsprüfung in der Heartbeat-Funktion. Ein Angreifer kann darüber einen „buffer over-read“ auslösen. Als Antwort auf einen präparierten Heartbeat-Request sendet OpenSSL bis zu 64 KB Speicherinhalte an den Angreifer. Dieser Speicher kann unter anderen den privaten Schlüssel des Servers, Sessionschlüssel oder über TLS übertragene Zugangsdaten enthalten. Der Angriff kann ggf. wiederholt werden, um weitere Speicherbereiche auszulesen. Das ist schlimm, sehr schlimm. Oder wie Bruce Schneier es formuliert hat, eine Katastrophe [5]: „‘Catastrophic’ is the right word. On the scale of 1 to 10, this is an 11.“

Wie funktioniert der Angriff?

Die „Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension“ [6] dient dazu, eine Verbindung aufrechtzuerhalten, obwohl keine Daten übertragen werden („keep-alive“). Heartbeat-Nachrichten bestehen aus zufälligen Daten und einem Feld mit der Payload-Länge. Der Kommunikationspartner muss auf einen Heartbeat-Request mit genau den gleichen Daten antworten.

Der Heartbleed-Bug besteht darin, dass die Payload-Länge nicht geprüft wird, bevor sie verwendet wird. OpenSSL reserviert entsprechend dem Wert im Längenfeld einen Puffer. Danach werden die Daten entsprechend diesem Wert aus der Eingabe in den Puffer kopiert. Gibt ein Angreifer eine größere Länge als Payload-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 64 KB angegeben (das ist der Maximalwert), obwohl nur 1 KB Payload gesendet wird, werden also 63 KB des vorhandenen Speichers in den Puffer kopiert – samt der zuvor darin enthaltenen und nicht überschriebenen, möglicherweise sensitiven, Daten. Nach dem Kopieren der Daten wird der gefüllte Puffer als Antwort auf den Heartbeat-Request an den Kommunikationspartner gesendet.

Der Angriff funktioniert sowohl gegen Server als auch gegen Clients, ist gegen Server aber deutlich einfacher, da der Angreifer von sich aus eine Verbindung zum Opfer aufnehmen kann. Beim Angriff auf einen Client muss der sich dafür mit einem bösartigen Server verbinden. Was im Zweifelsfall mit etwas Social Engineering oder durch einen Man-in-the-Middle-Angriff zu erreichen, also auch kein unüberwindbares Hindernis ist.

Der Angriff wird durch zwei Faktoren verschlimmert: Da OpenSSL seinen Speicher selbst verwaltet, stammten alle ausgespähten Daten aus dem OpenSSL-Prozess. Der Angreifer enthält also immer mehr oder weniger sensitive OpenSSL-Daten und niemals harmlose Daten anderer Prozesse. Außerdem hinterlässt ein Angriff keine Spuren auf dem Server, da weder Code eingeschleust noch Daten verändert werden. Allenfalls fallen in Logfiles die präparierten Heartbeat-Requests oder der Unterschied zwischen kurzem Heartbeat-Request und langer Heartbeat-Response auf.

Was kann ausgespäht werden?

Schon gleich nach der Veröffentlichung der Schwachstelle wurden einige mögliche Angriffe bekannt. Einige Beispiele:

  • Laut der Beschreibung auf heartbleed.com können der private Schlüssel des Servers, Benutzernamen und Passwörter, Instant-Message-Nachrichten, E-Mails und mehr ausgespäht werden [7]. Mit dem privaten Schlüssel kann sich der Angreifer als der entsprechende Server ausgeben oder aufgezeichnete verschlüsselte Verbindungen aufzeichnen, sofern der Server nicht Perfect Forward Secrecy verwendet.
  • Unter FreeBSD wurde vom ersten Request nach einem Neustart des Webservers der private Schlüssel des Servers kopiert [8].
  • Es wurden die Session-Cookies eines Flickr-Benutzers [9] und Passwörter für Yahoo!-Mail ausgespäht [10].

Da weitere Tests bestätigt haben, dass die privaten SSL-/TLS-Schlüssel ausgespäht werden können [11], ist es mit der Installation des OpenSSL-Updates nicht getan: Auch die SSL-/TLS-Schlüssel müssen erneuert werden, da man ja nicht sicher sein kann, dass sie nicht ausgespäht wurden. Schließlich hinterlässt ein Angriff im Allgemeinen keine Spuren.

Unabhängig davon müsste man als Benutzer konsequenterweise alle nach dem Bekanntwerden der Schwachstelle auf betroffenen Servern eingegebenen Passwörter nach der Installation der Patches und eines neuen Zertifikats austauschen, da sie ebenfalls über die Heartbleed-Schwachstelle ausgespäht worden sein könnten.

Es gibt aber auch einen kleinen Lichtblick: Der Angreifer kann nur irgendwelche Daten ausspähen und nicht bestimmen, welche das sind. Es ist also nicht möglich, gezielt zum Beispiel den privaten Schlüssel oder die Zugangsdaten eines bestimmten Benutzers auszuspähen. Der Angreifer muss sich mit dem zufriedengeben, was ihm der Server liefert. Aber er kann den Angriff bei Bedarf so oft wiederholen, bis er für seine Zwecke brauchbare Daten ausgespäht hat.

Wurde die Schwachstelle vor ihrer Veröffentlichung ausgenutzt?

Terrence Koeman von MediaMonks hat in Logfiles seiner Server Anzeichen für Angriffe durch ein Botnet gefunden, die bis in den November 2013 zurückgehen [12]. Die EFF sucht weitere Hinweise auf diesen möglichen Angriff [13]. Das Botnet ist zuvor durch Angriffe auf Freenode und IRC-Netzwerke aufgefallen, was eher auf Geheimdienste als auf Cyberkriminelle als Hintermänner hindeutet. Berichte, dass die NSA die Schwachstelle seit zwei Jahren ausgenutzt hat, wurden von dort umgehend dementiert [14], und irgendwie ist die Sache dann im Sande verlaufen.

Nach ihrer Veröffentlichung wurde sie ausgenutzt!

Nach der Veröffentlichung von Patch und Beschreibung gab es etliche Angriffe, zum Beispiel:

  • 8. April 2014: Bei einem gezielten Angriff auf einen SSL VPN Concentrator wurden laufende Sessions übernommen [15]. Die Angreifer konnten dadurch sowohl die Multifaktorauthentifizierung des angegriffenen Unternehmens als auch die VPN-Client-Software, die sicherstellen sollte, dass nur erlaubte Clients eine Verbindung zum Netzwerk aufbauen können, unterlaufen. Der Angriff wurde durch die Analyse von IDS-Signaturen und VPN-Logfiles erkannt.
  • 11. April 2014: Auf der britischen Website Mumsnet wurden Passwörter ausgespäht [16]. Bemerkt wurde der Angriff, weil sich jemand mit den Zugangsdaten einer der Gründerinnen der Website angemeldet, eine Nachricht gepostet und den Betreibern mitgeteilt hatte, dass die verwendeten Zugangsdaten über die Heartbleed-Schwachstelle ausgespäht wurden [17].
  • 11. April 2014: In Kanada wurden bei der Steuerbehörde die Sozialversicherungsnummern von ca. 900 Steuerzahlern ausgespäht [18], [19]. Die Royal Canadian Mounted Police hat kurz nach dem Angriff einen Verdächtigen verhaftet [20].
  • 16. April 2014: Laut BSI haben sich die Angriffe von den Webservern auf andere Systeme fokussiert. Welche Systeme konkret gefährdet sind, verriet man aber nicht und riet nur, „auch E-Mail-Server, Server für Video- und Telefonkonferenzen und weitere von außen erreichbare Server daraufhin zu untersuchen, ob sie eine verwundbare OpenSSL-Version einsetzen.“ [21].
  • 17. April 2014: Auf SMS-Gateways wurden im großen Maßstab SMS-Nachrichten ausgespäht [22]. Die betroffenen Gateways konnten über ein Web-API aus dem Internet gesteuert werden und verwendeten eine der betroffenen OpenSSL-Versionen.
  • April/Juni 2014: Beim US-Krankenhausbetreiber Community Health Systems (CHS) aus Tennessee wurden die Daten von ca. 4,5 Millionen Patienten ausgespäht [23]. Die Angreifer konnten über die Heartbleed-Schwachstelle auf einem nicht gepatchten Juniper-Gerät Zugangsdaten ausspähen und darüber über VPN auf das Netzwerk von CHS zugreifen [24].

Das kam jetzt aber ganz anders als erwartet ...

Fällt Ihnen bei diesen Angriffen etwas auf? Richtig: Es wurden bisher keine privaten Schlüssel ausgespäht, sondern „nur“ verschiedene Zugangsdaten (und der allein damit angerichtete Schaden ist schon ziemlich groß). Dabei war die erste große Befürchtung nach dem Bekanntwerden der Schwachstelle ja, dass darüber die privaten Schlüssel ausgespäht werden können und die Angreifer sich damit dann als der betreffende Server ausgeben oder zuvor aufgezeichnete verschlüsselte Verbindungen entschlüsseln können.

Das scheint zumindest bisher nicht passiert zu sein. Oder besser formuliert: Es sind keine entsprechenden Angriffe entdeckt worden. Es könnte durchaus sein, dass der ein oder andere Geheimdienst sich über den Heartbleed-Bug private Schlüssel beschafft und damit aufgezeichnete Verbindungen entschlüsselt hat, ohne dass an die große Glocke zu hängen. Oder dass die Hintermänner von Advanced Persistand Threats private Schlüssel ausgespäht und damit dann zum Beispiel Phishing-Angriffe gestartet haben. Solche Angriffe müssen ja nicht zwingend auffallen, sie hinterlassen ja nirgends Spuren.

Heartbleed – Ein längerfristiges Problem

Nach und nach zeigte sich, dass Heartbleed ein längerfristiges Problem ist. Zum einen stellte sich heraus, dass der durch die erneuerten SSL-Zertifikate notwendige Rückruf großer Mengen von Zertifikaten problematisch ist, und manche Browser die Rückrufe gar nicht prüfen [24]. Zum anderen stockte nach einiger Zeit die Installation des Patches, sodass es immer noch etliche Server gibt, die eine betroffene OpenSSL-Version einsetzen [25].

Der Heartbleed-Bug betrifft nur OpenSSL, und er erlaubt „nur“ das Ausspähen von Daten auf dem Server. Dass auch die Verschlüsselung selbst nicht immer so sicher ist, wie oft angenommen wird, zeigt der nächste Angriff. Er betrifft nicht nur eine Implementierung, sondern gleich das ganze Protokoll. Auch er hat, wie es 2014 üblich war, einen Namen bekommen: „Padding Oracle On Downgraded Legacy Encryption“, oder kurz: Poodle.

Vorsicht, bissiger Poodle in der Mitte!

Vereinfacht geht es beim Poodle-Angriff darum, dass ein Man in the Middle zunächst dafür sorgt, dass bei der Aushandlung der Verschlüsselung das Protokoll SSL 3.0 verwendet wird, um danach dessen schwache Verschlüsselung zumindest teilweise zu brechen. Die Lösung des Problems ist zum Glück sehr einfach, es reicht, SSL 3.0 auszuschalten. Das Protokoll gibt es seit achtzehn Jahren und ist sowieso völlig veraltet. Es wird nur noch als Fallback-Lösung für Systeme benötigt, di...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang