Dieser Artikel beschreibt ein aktuelles Ereignis. Die Informationen können sich deshalb rasch ändern.

Als Heartbleed oder auch Heartbleed-Bug wird ein schwerwiegender Fehler in der Open-Source-Bibliothek OpenSSL bezeichnet. Durch seine Tragweite hatte er Auswirkungen auf große Teile des Internets und erzeugte ein weltweites Medienecho.

Der Fehler befand sich in der TLS-Heartbeat-Funktion. Diese sieht vor, dass der Client eine bis zu 16 kByte große Menge an beliebigen Daten an den Server schickt, welcher anschließend selbige Daten zurücksendet um zu signalisieren, dass die Verbindung noch in Ordnung ist. Bei der Implementation dieser Funktion, wurde vergessen zu überprüfen, ob die angegebene Länge der Daten tatsächlich mit der Länge der Daten übereinstimmt. Ist die angegebene Länge größer als die Tatsächliche Länge, so kann aufgrund dieser fehlenden Überprüfung ein Angreifer dabei bis zu 16 kByte-1 Byte^[1] des Hauptspeichers der Gegenstelle auslesen.^[2] In Tests gelang es damit u. a. den privaten Schlüssel des Serverzertifikats, Benutzernamen und Passwörter auszulesen.^[3][4]

Anfang April 2014 wurde bekannt, dass die OpenSSL-Versionen 1.0.1 bis einschließlich 1.0.1f, sowie 1.0.2-beta bis einschließlich 1.0.2-beta1^[5] vom sogenannten Heartbleed-Bug^[6] betroffen sind. Die Sicherheitslücke bestand insgesamt für 27 Monate, bis sie unabhängig voneinander von Antti Karjalainen (Codenomicon, Oulu, Finnland) und Neel Mehta (Google Security) entdeckt wurde^[7]. Helsinki)

Der Quellcode, der den Fehler aufweist wurde am 1. Januar 2012 in das OpenSSL-Git-Repository eingepflegt^[8] und erstmals am 14. März 2012 mit OpenSSL-Version 1.0.1 veröffentlicht. Der Code wurde zuvor von einem Studenten der Universitäten Münster und Duisburg-Essen im Rahmen der Vorarbeiten zu seiner Dissertation über das SCTP-Protokoll entwickelt und sollte OpenSSL um ein sog. Heartbeat-Verfahren erweitern, mit dem es möglich ist, zu erfragen, ob der Server noch am Leben ist.^[9] Der Programmierer beteuerte, es habe sich dabei um einen reinen Programmierfehler gehandelt.^[10] Obwohl der Programmierer in seiner Dissertation auf die Möglichkeit hinweist, dass Payload-Informationen durch Lengthguessing ausgenutzt werden könnten,^[11] hat er mit seiner Änderung zuvor selbst eine ebensolche Sichrheitslücke eingebaut.

Abgesehen von möglicherweise abgegriffenen Zugangsdaten (Benutzernamen, Passwörter) kann mit dem privaten Schlüssel des Serverzertifikats ein, auch lange vor dem Bekanntwerden des Fehlers, aufgezeichneter Datenverkehr nachträglich entschlüsselt werden, sofern die Verschlüsselung nicht mit Perfect Forward Secrecy geschützt war. Außerdem können mit dem privaten Schlüssel des Serverzertifikats Man-in-the-middle-Angriffe durchgeführt werden, sofern das Serverzertifikat noch nicht abgelaufen oder widerrufen ist. Es können alle Dienste betroffen sein, wie beispielsweise E-Mail-Verkehr oder verschlüsselte Chats, sofern eine betroffene OpenSSL-Version verwendet wurde. SSH ist nicht betroffen da es TLS nicht verwendet.^[12]

Private Schlüssel der Serverzertifikate (und möglicherweise auch andere Zugangsdaten) auf betroffenen Systemen sollten als kompromittiert betrachtet werden. Es wurde empfohlen, diese auszutauschen. Sicherheitsbewussten Nutzern wurde empfohlen, ihre Passwörter zu ändern.^[13] Durch die hohe Anzahl betroffener Systeme stellte dies im April 2014 auch professionelle Zertifikatsanbieter vor Herausforderungen.^[14] Der Kryptologe und Sicherheitsexperte Bruce Schneier beschreibt die Tragweite des Problems als:

OpenBSD- und OpenSSH-Entwickler Theo de Raadt bezeichnete in diesem Zusammenhang das OpenSSL-Team als nicht vertrauenswürdig, da dieses einen Sicherheitsmechanismus, der bei der Entwicklung diesen Fehler nicht zugelassen hätte, aus Gründen der Bequemlichkeit explizit umgehe.^[16]

Das Abgreifen dieser Daten hinterlässt kaum Spuren auf dem angegriffenen System, daher ist nicht sicher, ob der Fehler in der Vergangenheit bereits ausgenutzt wurde,^[17][18] es gibt jedoch Hinweise auf einen Missbrauch im November 2013.^[19] Die Nachrichtenagentur Bloomberg berichtete, dass der Heartbleed-Bug praktisch von Beginn an durch die NSA genutzt wurde,^[20] was vom Büro des NSA-Direktors umgehend dementiert wurde.^[21][22]

1. ↑ So funktioniert der Heartbleed-Exploit
2. ↑ existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug detaillierte technische Beschreibung, englisch, abgerufen am 10. April 2014.
3. ↑ Passwort-Zugriff: Heartbleed-Lücke mit katastrophalen Folgen. Abgerufen am 10. April 2014.
4. ↑ Eine leicht verständliche Erläuterung zur Funktionsweise des Heartbleed-Exploit gibt es hier So funktioniert der Heartbleed-Exploit. Abgerufen am 11. April 2014.
5. ↑ OpenSSL Security Advisory vom 7. April 2014, englisch, abgerufen am 10. April 2014.
6. ↑ The Heartbleed Bug Englisch. Abgerufen am 8. April 2014.
7. ↑ http://www.businessinsider.com/heartbleed-bug-codenomicon-2014-4
8. ↑ git-commit
9. ↑ SCTP. Strategies to Secure End-To-End Communication, S. 66f.
10. ↑ Der Programmierer im Sunday Morning Herald
11. ↑ a.a.O. S. 67
12. ↑ http://www.golem.de/news/openssl-wichtige-fragen-und-antworten-zu-heartbleed-1404-105740.html
13. ↑ Wilhelms-Universitätitsluecke-jetzt-passwoerter-aendern-a-963590.html Heartbleed-Sicherheitslücke: Diese Passwörter müssen Sie jetzt ändern Abgerufen am 10. April 2014.
14. ↑ Heartbleed SSL-GAU: Neue Zertifikate braucht das Land. Abgerufen am 10. April 2014.
15. ↑ Heartbleed. Abgerufen am 11. April 2014.
16. ↑ Theo De Raadt on Hearbleed
17. ↑ Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL. Abgerufen am 8. April 2014.
18. ↑ Keys auslesen mit OpenSSL. Abgerufen am 8. April 2014.
19. ↑ Spuren von Heartbleed schon im November 2013 Abgerufen am 10. April 2014.
20. ↑ Spiegel Online vom 11. April 2014: Internet-Sicherheitslücke: NSA soll "Heartbleed"-Fehler systematisch ausgenutzt haben
21. ↑ http://www.sueddeutsche.de/digital/nsa-und-die-heartbleed-luecke-wucht-des-misstrauens-1.1935920
22. ↑ http://icontherecord.tumblr.com/post/82416436703/statement-on-bloomberg-news-story-that-nsa-knew