OpenSSL Bug
Im April 2014 wurde bekannt, dass die Versionen 1.0.1 bis einschließlich 1.0.1f, als auch 1.0.2-beta – 1.0.2-beta1 vom sogenannten „Heartbleed-Bug“ betroffen sind.
In erster Linie betroffen sind jetzt alle Betreiber von Servern, die SSL zur Verschlüsselung einsetzen.
Die Version OpenSSL 1.0.1g enthält den Fehler nicht mehr.
Aufgrund eines Zugriffs auf uninitialisierten Speicher kann ein Angreifer dabei bis zu 64 KByte des Hauptspeichers der Gegenstelle auslesen.
Den Entwicklern gelang es bei Tests, damit u. a. den privaten Schlüssel des Serverzertifikats, Benutzernamen und Passwörter auszulesen.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, es gibt jedoch Hinweise auf einen Missbrauch im November 2013.
Abgesehen von möglicherwiese abgegriffenen Zugangsdaten wie Benutzernamen und 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 sind alle Dienste betroffen, wie beispielsweise E-Mail-Verkehr /VPN / FTP Dienste oder verschlüsselte Chats, sofern eine betroffene OpenSSL-Version verwendet wurde. Das heißt auch Banken / Sparkassen und Shops mit SSL verbindung wie Ebay, Amazon etc.. Auch E-Mail Provider wie web.de / GMX / Yahoo / Google oder T-Online können davon betroffen sein.
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. Durch die hohe Anzahl betroffener Systeme stellte dies im April 2014 auch professionelle Zertifikats-Anbieter vor Herausforderungen.
Bruce Schneier beschreibt die Tragweite des Problems als: „“Catastrophic“ is the right word. On the scale of 1 to 10, this is an 11.“ (dt. „“Katastrophal“ ist das richtige Wort. Auf einer Skala von 1 bis 10 ist dies eine 11.“).
Die Version OpenSSL 1.0.1g enthält den Fehler nicht mehr.
Debian stellt bereits ein Update bereit.
Andere Distributionen werden bald folgen.
Wer OpenSSL selbst mit der Option -DOPENSSL_NO_HEARTBEATS übersetzt, kann eine nicht anfällige Bibliothek erzeugen.
[Update: Versionen vor der aktuellen 1.0.1 wie das auf älteren Systemen noch verbreitete OpenSSL 0.9.8 sind offenbar nicht betroffen.]
Endanwender, die Produkte auf OpenSSL-Basis einsetzen, müssen aktualisierte Versionen installieren!
Und das dürften nahezu alle sein. Denn das Problem betrifft nicht nur PC´s, sondern insbesondere auch Smartphones, SmartTVs, Router und viele andere Geräte
Vereinfacht gesagt, alles, was irgendwie mit dem Internet spricht und keine proprietären SSL-Bibliotheken beziehungsweise den Exoten GnuTLS einsetzt.
Update: Security Advisories
- OpenSSL: TLS heartbeat read overrun (CVE-2014-0160)
- Debian: Debian — Security Information — DSA-2896-1 openssl
- Redhat: [RHSA-2014:0376-01] Important: openssl security update
- Ubuntu: USN-2165-1: OpenSSL vulnerabilities
- Fedora: Status on CVE-2014-0160, aka „Heartbleed“
- CentOS: CESA-2014:0376 Important CentOS 6 openssl Update
- SuSE: openSUSE-SU-2014:0492-1: important: update for openssl
SLES 11 nutzt 0.9.8, nicht betroffen - MacOS X: 10.9.2 nutzt 0.9.8, wahrscheinlich nicht betroffen
- FreeBSD: betroffen FreeBSD-10/11: OpenSSL multiple vulnerabilities
Ist SSH betroffen?
Nein. OpenSSH nutzt zwar die OpenSSL-Bibliothek für die Nutzung von kryptographischen Algorithmen, allerdings ist die Heartbeat-Erweiterung eine reine TLS-Angelegenheit. Programme, die zwar vom Kryptographiecode von OpenSSL Gebrauch machen, aber damit andere Protokolle wie SSH realisieren, sind somit nicht betroffen.
Was gilt jeweils für Windows, Linux, MacOS und andere Betriebssysteme?
Windows selbst besitzt eine eigene SSL-Bibliothek namens SChannel, die nichts mit OpenSSL zu tun hat.
MacOS – Apple nutzt eine ältere Version von OpenSSL (0.9.8), die nicht von Heartbleed betroffen ist.
Unter nahezu allen Linux-Distributionen gehört OpenSSL zur Standardausstattung, gleiches gilt auch für alle BSD-Systeme.
Alle wichtigen Distributionen haben Updates bereitgestellt ( siehe oben mit Links).
Für alle Betriebssysteme gilt unabhängig davon:
Es ist immer möglich, dass Programme ihre eigene OpenSSL-Version mitliefern. Auf Webservern betrifft das beispielsweise das „SPDY-Modul“ von Google.
Android
In der bei Android mitgelieferten OpenSSL-Version wurde Heartbeat am 25. Juni 2012 deaktiviert, also wenige Monate nach der Veröffentlichung des problematischen Codes. Vermutlich sind damit nur wenige Android-Telefone und Versionen betroffen. Die einzige Version von Android, die damit betroffen ist, ist laut Googles Sicherheitsteam die Version 4.1.1.
Unabhängig davon ist es natürlich möglich, dass einzelne Apps OpenSSL nutzen und selbst den verwundbaren Code mitliefern. Das kann nur im Einzelnen für jede App überprüft werden.
iPhones + iPads
Das mobile System iOS von Apple liefert OpenSSL nicht mit. Trotzdem gilt dasselbe wie bei Android: Einzelne Apps können den Code von OpenSSL nutzen und selbst mitliefern.
Was müssen Server-Administratoren beachten?
Nach einem Update müssen alle Services, die OpenSSL benutzen, neu gestartet werden.
Das gilt beispielsweise für Webserver oder Mailserver.
Andernfalls haben diese die alte OpenSSL-Version noch im Speicher.
Es gibt ein für Administratoren sehr nützliches Skript namens lib_users, welches unter Linux-Systemen herausfindet, welche laufenden Programme Bibliotheken verwenden, die nicht mehr installiert sind.
Technik + Herkunft + allegemeine Informationen zu SSL
OpenSSL ist eine freie Software für Transport Layer Security, ursprünglich SSLeay nun Secure Sockets Layer (SSL)
OpenSSL umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen sowie das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten.
SSLeay ermöglichte Mitte der 1990er Jahre, SSL auch außerhalb der USA mit starker Verschlüsselung einzusetzen, weil diese Implementierung in Australien entstand und somit keinen Exportbeschränkungen unterlag.Den Namen der Software bildeten die Initialen des Netzwerkprotokolls und des Programmierers. Eric A. Young hatte zuvor an Implementierungen von Kerberos und DES gearbeitet. Zu diesem neuen Projekt regte ihn 1995 sein Freund Tim J. Hudson an. Hudson trug auch maßgeblich zum Projekt bei, indem er zugehörige Patches für andere freie Software und für Windows programmierte.
Die Version SSLeay 0.9.1b vom Sommer 1998 wurde nicht mehr veröffentlicht, sondern von einem neuen Team bis Dezember 1998 weiterentwickelt und als OpenSSL 0.9.1c veröffentlicht.
Ralf S. Engelschall, Mitbegründer dieser Gruppe, beschreibt die Entwicklung von OpenSSL als Voraussetzung für die Schaffung von mod_ssl, dem meistgenutzten Verschlüsselungsmodul für Apache-Webserver. Im Gegensatz zu diesem praktisch fertigen Modul, das nur noch gewartet zu werden brauche, sei die Entwicklung bei OpenSSL noch nicht abgeschlossen. Stattdessen würden engagierte, freie Programmierer weiterhin Applikationen entwerfen und dabei auf den bereits etablierten Basisfunktionen von OpenSSL aufbauen.
Was kann zukünftig helfen?
Um festzustellen, ob sich in einer SSL-verschlüsselten Datei Schadsoftware verbirgt, kann das aktuelle Security-Policy-Enforcement vieler Unternehmen nicht leisten.
Dazu bedarf es einer modernen „Advanced Threat Protection“ (ATP).
Eine solche SSL-Visibility-Lösung leitet dazu die entschlüsselten Daten zur Überprüfung an Sicherheitslösungen wie Malware-Prevention-Systeme beziehungsweise Next-Generation-Firewall-, Intrusion-Detection- oder Data-Loss-Prevention-Systeme weiter.
Diese blockieren dann unerwünschten und schadhaften Datenverkehr. Sind die Inhalte hingegen in Ordnung, werden sie an die SSL-Appliance zurückgeleitet und dort erneut verschlüsselt und an den Empfänger übertragen.
Bleibt die Frage:
Wie es um die Vertraulichkeit und Integrität der betroffenen Daten bestellt ist, wenn sie zwar per SSL übertragen, auf dem Transportweg durch die ATP aber trotzdem ausgelesen werden können.
Eine klare Antwort ist nicht da:
Sicherheit ist nicht mehr nur ein technologisches Problem, das mit Technologie gelöst werden kann. Vielmehr sind es menschliche Überlegungen, die zu einer strategischen Antwort führen müssen. Bevor Unternehmen in Technologie oder Personal investieren, sollten diese ihre Rechts- und Personalabteilungen sowie ihre Mitarbeiter ins Boot holen, um zu verstehen, was auf dem Spiel steht und was man für die Sicherheit im Unternehmen tun kann. Nur dann kann eine Strategie für verschlüsselten Datenverkehr definiert werden. Danach sollten Unternehmen technologische Lösungen finden, die es ermöglichen, ihre eigene Sicherheitsstrategie zu nutzen und gleichzeitig ihre Leistungsfähigkeit beizubehalten.