Skip to content

OpenSSL - Der Heartbleed Bug und seine Folgen

In OpenSSL wurde eine kritische Schwachstelle behoben: Der Heartbleed Bug. Und diesmal ist "kritisch" sehr ernst gemeint. Oder um Bruce Schneier zu zitieren:

""Catastrophic" is the right word. On the scale of 1 to 10, this is an 11."

Über die Schwachstelle können vertrauliche Daten, insbesondere die privaten Schlüssel der Server, aber auch Sitzungsschlüssel, übertragene Zugangsdaten und vieles mehr ausgespäht werden.

Betroffen sind alle Dienste, die TLS verwenden und eine angreifbare OpenSSL-Version einsetzen. Vor allem sind das natürlich Webserver, aber auch Mailserver, VPN, Updatefunktionen, ... sind von der Schwachstelle betroffen und damit angreifbar.

Was ist der 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, 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.

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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Der Heartbleed-Bug und seine Folgen

Vorschau anzeigen
Warum ist die Heartbleed-Schwachstelle in OpenSSL so schlimm und warum sollte man SSL-Zertifikate und Passwörter betroffener Server austauschen? Alles im folgenden geschriebene gilt sinngemäß auch die Client-Installationen von

Dipl.-Inform. Carsten Eilers am : Nutzt die NSA den Heartbleed Bug seit 2 Jahren?

Vorschau anzeigen
Der Heartbleed Bug in OpenSSL wurde von der NSA angeblich schon seit 2 Jahren ausgenutzt. Was die natürlich dementiert. Was ist davon zu halten? Blomberg meldet, die NSA dementiert Michael Riley von der Nachrichtenagentur Bloomberg hat

Dipl.-Inform. Carsten Eilers am : Neues zum Heartbleed Bug in OpenSSL

Vorschau anzeigen
Es gibt ein paar Neuigkeiten zum Heartbleed Bug in OpenSSL. Und leider mit einer Ausnahme nichts Gutes. Die Ausnahme ist ein xkcd-Cartoon, der den Heartbleed-Fehler sehr schön erklärt. Und damit kommen wir zu den schlechten Nachrichten

Dipl.-Inform. Carsten Eilers am : Heartbleed: Problematische Zertifikats-Rückrufe

Vorschau anzeigen
Über die Heartbleed-Schwachstelle in OpenSSL können die privaten Schlüssel der Server-Zertifikate ausgespäht werden. Ob das wirklich auf einem bestimmten Server passiert ist, kann niemand mit Sicherheit feststellen. Also m&uuml

Dipl.-Inform. Carsten Eilers am : Neues rund um die Heartbleed-Schwachstelle

Vorschau anzeigen
Es gibt ein paar Neuigkeiten rund um die Heartbleed-Schwachstelle in OpenSSL: Weitere Angriffe entdeckt Es sind weitere Angriffe bekannt geworden, allerdings wurden alle erst nach Veröffentlichung der Patches und damit der Schwachstell

Dipl.-Inform. Carsten Eilers am : Das große Problem mit den Patches und Updates

Vorschau anzeigen
Zur Zeit gibt es zwei Probleme, die auf die problematische Verbreitung von Patches und Updates hinweisen: Die Installation der Patches für die Heartbleed-Schwachstelle in OpenSSL scheint nicht mehr voran zu kommen, und im WordPress-Plugin Ti

Dipl.-Inform. Carsten Eilers am : Neues eBook: "Verschlüsselung im NSA-Zeitalter"

Vorschau anzeigen
Bei entwickler.press ist mein E-Book zur Verschlüsselung nach den Snowden-Enthüllungen über die NSA-Spionage erschienen: "Verschlüsselung im NSA-Zeitalter". Seit der Veröffentlichung der von Edward Snowden

Dipl.-Inform. Carsten Eilers am : Kommentare zum iCloud-Angriff, Heartbleed-Angriffen und Angriffen über Werbung

Vorschau anzeigen
Heute gibt es mal wieder Kommentare zu neuen Entwicklungen bei altbekannten Problemen. Los geht es mit einem nicht besonders alten Problem, den aus der iCloud geklauten Promi-Nacktfotos: Die iCloud wurde nicht angegriffen, nur ihre Nutzer!

Dipl.-Inform. Carsten Eilers am : 2014 - Das Jahr, in dem die Schwachstellen Namen bekamen

Vorschau anzeigen
2014 wird als das Jahr in die Geschichte eingehen, in dem die Schwachstellen Namen bekamen. Vorher gab es bereits Namen für Schadsoftware, aber für Schwachstellen haben die sich erst dieses Jahr wirklich durchgesetzt. Die Schwachstelle von

Dipl.-Inform. Carsten Eilers am : Die GHOST-Schwachstelle - Mehr Schein als Sein

Vorschau anzeigen
Es gibt mal wieder eine neue Schwachstelle mit Namen: GHOST. Aber die ist bei weitem nicht so gefährlich wie zum Beispiel der Heartbleed-Bug oder die ShellShock-Schwachstelle. Eine uralte Schwachstelle spukt auf Linux-Systemen Erst

Dipl.-Inform. Carsten Eilers am : Die "Equation Group", Carbanak, JASBUG - Namen sind in!

Vorschau anzeigen
Es gibt neue Angriffe und Schwachstellen mit mehr oder weniger schönen Namen: Die "Equation Group", den Schädling Carbanak, und den JASBUG. Mit dem sich seine Entdecker gerne ein Denkmal setzen würden. Die "Equation Group" - Cyberk

Dipl.-Inform. Carsten Eilers am : Venom - Ein Name macht eine Schwachstelle nicht automatisch zur Katastrophe

Vorschau anzeigen
Es gibt eine neue Schwachstelle mit Namen: Venom. Das ist seit letztem Jahr ja üblich. Aber nur, weil eine Schwachstelle einen Namen hat, wird sie dadurch nicht automatisch ganz besonders schlimm. Auch wenn manche das zu meinen scheinen.

Dipl.-Inform. Carsten Eilers am : Drucksache: Mobile Technology 3.2015 - Wie sicher sind Cross-Plattform-Apps?

Vorschau anzeigen
Im Magazin Mobile Technology 3.2015 ist ein Artikel über die Sicherheit von Cross-Plattform-Apps erschienen. Um Verwirrungen vorzubeugen: Das ist zwar das gleiche Thema wie das des Artikels im Windows Developer 7.15, aber ein ander

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

notizblog.digital am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!