Dipl.-Inform. Carsten Eilers

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, Session-Schlüssel oder über TLS übertragene Zugangsdaten enthalten. Der Angriff kann ggf. wiederholt werden, um weitere Speicherbereiche auszulesen.

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.

Da sich der Fehler in der Heartbeat-Funktion befindet, wurde er von einigen der Entdecker "Heartbleed Bug" genannt. Die offizielle CVE-ID ist CVE-2014-0160

Die Schwachstelle wurde unabhängig voneinander sowohl von Riku, Antti und Matti von Codenomicon (die auch die Website Heartbleed.com gestartet haben) als auch von Neel Mehta von Google Security (der sie als erster an die OpenSSL-Entwickler gemeldet hat) entdeckt. Die Koordination der Reaktion auf die Schwachstelle hat das NCSC-FI übernommen.

Der Fehler und seine Auswirkungen

Eine gute Beschreibung des Heartbleed Bug liefern außer der zugehörigen Website einige Blogartikel, zum Beispiel von Matthew Green, von Cesar von IOActive (der den betreffenden Code sehr genau durchgeht), Sean Cassidy oder Paul Ducklin von Sophos.

Im Folgenden gehe ich von einem Angriff auf einen Server aus, da der deutlich gefährlicher ist. Genau so wie OpenSSL auf dem Server angegriffen werden kann, kann es auch auf einem Client angegriffen werden. Mit dem Unterschied, dass ein Angreifer zwar jederzeit eine Verbindung mit einem Server aufnehmen kann, im Allgemeinen aber darauf warten muss, dass sich ein Client mit ihm verbindet.

Die "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension" wird in RFC 6520 standardisiert. Sie dient dazu, eine Verbindung aufrecht zu erhalten, obwohl keine Daten übertragen werden ("keep-alive"). Heartbeat-Nachrichten bestehen aus zufälligen Daten und der Payload-Länge. Der Kommunikationspartner muss auf einen Heartbeat-Request mit genau den gleichen Daten antworten.

Der Fehler 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 64KB angegeben (das ist der Maximalwert), obwohl nur 1KB Payload gesendet wird, werden also 63KB 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 dann als Antwort auf den Heartbeat-Request an den Kommunikationspartner gesendet.

Was kann ausgespäht werden? Einige Beispiele:

• Codenomicon konnte den geheimen Schlüssel des Servers, Benutzernamen und Passwörter, Instant-Message-Nachrichten, E-Mails und mehr ausspähen.
• Unter FreeBSD wurde laut @1njected vom ersten Request nach einem Neustart des Webservers der private Schlüssel des Servers kopiert.
• Errata Security konnte bei einem Test von Flickr Session-Cookies eines Benutzers ausspähen.
• Ars Technica berichtet, dass Passwörter für Yahoo!-Mail ausgespäht werden konnten.

Matthew Sullivan hat beschrieben, wie mit Hilfe der Heartbleed-Schwachstelle Session-Hijacking möglich ist.

Ein alter Fehler, und eine Besonderheit

Der Fehler und damit die Schwachstelle war seit der Einführung der Heartbeat Extension in OpenSSL enthalten. Und die war am 1. Januar 2012.

Verschlimmert wird die Schwachstelle dadurch, dass OpenSSL die Speicherreservierung über einen Wrapper selbst durchführt statt direkt die entsprechenden Systemfunktionen zu verwenden. Dadurch werden die Schutzfunktionen des Systems für die Speicherfunktionen unterlaufen. Außerdem reserviert sich OpenSSL dadurch größere Speicherblöcke am Stück und verteilt die dann intern. Dadurch enthalten die über die Heartbleed-Lücke ausgespähten Speicherbereiche auch ausschließlich OpenSSL-Daten und nicht auch evtl. harmlosere Daten anderer Prozesse.

Matt Suiche hat sich statt der Schwachstelle den Patch angesehen und ist etwas verwirrt. Zum einen weil die Kommentare und Variablennamen irreführend sind, zum anderen weil er Abweichungen zum Standard festgestellt hat. Oder zumindest glaubt, festgestellt zu haben. Weshalb er auch um Kommentare bittet:

"Reading a RFC can be hard, including widely deployed code such as OpenSSL. I'd be curious to hear your interpretation of the RFC."

Die Folgen des Angriffs

Ein Angreifer kann einem Server über einen Heartbeat-Request im Grunde anweisen, ihm bis zu 64 KB seines Speicher zu schicken. Da OpenSSL diesen Speicher auch verwendet, um seinen privaten Schlüssel, Session-Schlüssel und Zugangsdaten zu speichern, sind die unter Umständen in der Antwort enthalten.

Schon das Ausspähen von Zugangsdaten ist natürlich sehr schlecht. Noch schlimmer wird es aber, wenn Schlüssel ausgespäht werden. Mit dem Session-Schlüssel kann der Angreifer die aktuelle Verbindung entschlüsseln und belauschen. Gelangt er aber an den privaten Schlüssel des Servers, kann er damit auch vorherige, von ihm gespeicherte Sessions entschlüsseln (sofern das nicht durch den Einsatz von Perfect Forward Secrecy (PFS) verhindert wird.

Katastrophal wird die Schwachstelle, weil der Angreifer sich mit den ausgespähten privaten Schlüssel auch jederzeit als der betreffende Server ausgeben kann. Als weitere Steigerung hinterlässt ein Angriff im Allgemeinen keine Spuren auf dem Server. Allenfalls in Logfiles könnten verdächtige Requests auftauchen. Wenn die denn protokolliert werden. Was normalerweise nicht der Fall ist.

Angriffe laufen?!?

Exploits kursieren angeblich bereits im Internet. In der Exploit-DB wurde ein Proof of Concept veröffentlicht, außerdem gibt es etliche Test-Tools (siehe unten).

Terrence Koeman von MediaMonks hat Art Technica berichtet, dass er in Logfiles seiner Server Anzeichen für Angriffe durch ein Botnet gefunden hat, die bis in den November 2013 zurück gehen. Die EFF sucht weitere Hinweise auf diesen möglichen Angriff.

SeaCat hat seit dem 23. März ebenfalls Hinweise auf Heartbleed-Angriffe in Logfiles gefunden, entsprechende Muster können aber auch von anderen Tools erzeugt werden.

Ars Technica hat aufgrund sich häufender Angriffe über eventuell durch einen Heartbleed-Angriff ausgespähten Zugangsdaten seine Benutzer aufgefordert, ihre Passwörter zu ändern.

Tools zum Testen

Es gibt eine ganze Reihe von Tools, um Server auf die Schwachstelle zu testen. Denken Sie aber daran, dass diese Seiten die Schwachstelle nicht nur testen, sondern theoretisch auch ausnutzen können. Sie sollten dem jeweiligen Entwickler und/oder Betreiber also vertrauen.

• masscan von Robert Graham von Errata Security wurde an Heartbleed angepasst. Graham hat damit bei einem Scan des Internets in der Nacht vom 8. auf den 9. April festgestellt, dass von 28.581.134 getesteten IP-Adressen "nur" 615.268 angreifbar waren.
• Einen Online-Test hat Filippo Valsorda auf http://filippo.io/Heartbleed/ bereit gestellt (das gleiche Tool auf GitHub zum Downloaden oder Forken).
• Einen weiteren Online-Test gibt es von 1st Ltd. auf http://possible.lv/tools/hb/
• Die CA Comodo hat ebenfalls einen Online-Test bereit gestellt.
• Und auch von LastPass gibt es einen Online-Test.
• Der SSL Server Test von Qualys / SSL Labs enthält ebenfalls einen (experimentellen) Test auf die Heartbleed-Schwachstelle.
• Steffen Ullrich hat auf GitHub ein Perl-Skript veröffentlicht, mit dem sich außer Web- auch Mailserver (IMAP, POP, SMTP) testen lassen.
• Einen Test für Clients hat Peter Wu entwickelt.
• Für einige Scanner gibt es ebenfalls Module:
  • Metasploit (Bericht dazu)
  • Nmap
  • Nessus
  • OpenVAS

Mustafa Al-Bassam hat Massentests der Alexa Top 10.000 Websites durchgeführt. Mit Stand 8. April, 16:00 Uhr UTC, waren noch 630 diese 10.000 Websites von der Schwachstelle betroffen.

Updates installieren, und wie geht es dann weiter?

Updates stehen seit dem 7.4. von OpenSSL zur Verfügung, die Linux-Distributoren und weiteren betroffenen Hersteller haben zum größten Teil bereits eigene Updates veröffentlicht. Ein Problem sind noch die Embedded Devices wie zum Beispiel Router und Access Points, für die erst passende Firmware veröffentlicht werden muss. Wenn sie denn entwickelt wird.

Eine Übersicht über veröffentlichte Updates etc. gibt es im ISC-Diary.

Wie so oft gibt es auch dieses Mal wieder welche, die gleicher sind als andere. Diesmal ist das mindestens CloudFlare, wo man einige Tage früher einen Patch hatte ("We fixed this vulnerability last week before it was made public."). Was einen gewisses Beigeschmack hat. Oder merkwürdige Gerüche entwickelt.

Wichtig ist, nach der Installation des Updates die SSL-Zertifikate zu erneuern. Es gibt keinerlei Möglichkeit, sicher festzustellen, ob sie kompromittiert wurden oder nicht. Zumindest GlobalSign, Comodo, Verisign/Symantec, RapidSSL / GeoTrust und die PSW Group geben die Zertifikats-Updates kostenlos aus. Die Frage ist, ob die Infrastruktur mit den massenhaften Rückruf von Zertifikaten klar kommt.

Das gleiche gilt für alle über TLS geschützt übertragenen Zugangsdaten. Wenn der Server von der Schwachstelle betroffen ist, sollten die Zugangsdaten ausgetauscht werden. Informieren Sie also ihre Benutzer, nachdem Sie OpenSSL aktualisiert und das Zertifikat ausgetauscht haben. Erst dann ist ein Passwortwechsel sicher möglich. Und verzichten Sie auf Links in der Info-Mail.

Im Handlers Diary des ISC wird bereits vor Phishing-Mails gewarnt, die die Schwachstelle als Köder verwenden. Parallel gibt es erste echte Warn-Mails. Links in entsprechenden unaufgefordert zugesandten Info-Mails sollten Sie generell nicht anklicken. Rufen Sie die Websites direkt auf und nutzen sie dort die Funktion zur Änderung des Passworts. Wird ihnen daraufhin eine E-Mail mit einem Reset-Link o.Ä. zugesandt, können Sie diesen Link natürlich nutzen.

Carsten Eilers