@dfncert@infosec.exchangeHeartbleed / OpenSSL / CVE-2014-0160
Spätestens seit Heise Security Online am Dienstag den 08.04.2014 unter der Überschrift "Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL" darüber berichtet hat, bereitet ein Programmierfehler in OpenSSL nicht nur vielen Systemverantwortlichen, sondern auch Nutzern schlaflose Nächte. Der Fehler in der OpenSSL-Implementierung des TLS/DTLS-Protokolls (verwendet zur Verschlüsselung von Datenverkehr zwischen Servern und Clients/Benutzern) ist unter dem Namen "Heartbleed" (abgeleitet von der angreifbaren Heartbeat-Funktion) in aller Munde.
Beunruhigend ist, dass die Sicherheitslücke nicht neu ist, sondern bereits seit dem OpenSSL Release 1.0.1 am 14.03.2012 existierte, jedoch erst mit Release 1.0.1.g am 07.04.2014 behoben und damit gleichzeitig auch einer größeren Öffentlichkeit bekannt gemacht wurde. Zahlreiche Linux-Distributionen, Software- und Hardware-Hersteller haben zwischenzeitlich aktualisierte Pakete, Firmware, Produkt-Releases/Updates zur Verfügung gestellt. Das DFN-CERT hat die DFN-Anwender umgehend per Advisory DFN-CERT-2014-0420 über die Sicherheitslücke und die jeweils verfügbaren Sicherheitsupdates informiert.
Details
Es handelt sich hier nicht um eine Schwachstelle des Protokolls TLS/SSL als solches, sondern um einen Programmierfehler innerhalb der Softwarebibliothek OpenSSL. Solange angreifbare Versionen von OpenSSL auf einem Server oder in einer Appliance verwendet werden, kann dieser Bug ausgenutzt werden, um z.B. geheime Schlüssel eines Webservers aus dem Speicher auszulesen bzw. zu kopieren. Die Schwachstelle beschränkt sich gerade nicht auf Webserver. Die Verwundbarkeit kann auch durch Anwendungen, Betriebssystemkomponenten oder Firmware in Hardware, die auf den betroffenen OpenSSL-Versionen aufsetzt, ausgenutzt werden. Und damit sind auch IMAP, POP, SMTP und andere typische Protokolle, welche TLS verwenden, betroffen.
Die OpenSSL-Schwachstelle "Heartbleed" kann Speicherinhalte von betroffenen TLS-Anwendungen offenlegen, 64 kB Daten pro Anfrage. Dieses kann alle Arten von sensiblen Daten betreffen, die sich zu dem Zeitpunkt im Speicher befinden, z.B. Nutzernamen, Passworte, Email-Adressen, Session IDs, Formulardaten und evtl. den geheimen Schlüssel des Servers. Der Zugriff auf den geheimen Schlüssel eines Anwendungsservers liefert einem erfolgreichen Angreifer den Zugriff auf die verschlüsselte Kommunikation zwischen Clients und dem kompromittierten Server. Unterstützt eine betroffene TLS-Anwendung die Anmeldung über Nutzername/Passwort (z.B. ein Login in einem Webmail-System, IMAP/POP/SMTP-STARTTLS), so können dadurch auch diese Daten kompromittiert werden.
Eine korrigierte Version von OpenSSL (1.0.1g) steht seit dem 07.04.2014 zur Verfügung und wird seitdem unter Hochdruck von allen bekannten Linux-Distributionen, Software-, Appliance- und Hardware-Herstellern eingepflegt, deren Produkte auf den betroffenen Versionen von OpenSSL aufsetzen; entsprechende Sicherheitspatches stehen von vielen Anbietern bereits zur Verfügung.
Betroffen sind alle Systeme, welche das Softwarepaket OpenSSL in den Versionen 1.0.1 bis 1.0.1f einsetzen und dieses OpenSSL in von möglichen Angreifern erreichbarer Serversoftware in Kombination mit TLS verwenden. Beispiele hierfür sind: Apache, nginx, openvpn, postfix, exim, evtl. openldap.
Anmerkung: Debian patcht ohne Versionsänderung; 1.0.1e-2 + deb 7u6 ist aktuell!
Nicht betroffen sind Systeme mit anderer SSL-Software, auch wenn diese das TLS-Protokoll unterstützen. Microsoft IIS ist z.B. nicht betroffen. Nicht betroffen sind ferner Systeme mit älteren Versionen, z.B. openssl 0.9.8 oder openssl 1.0.0.
Des Weiteren nicht durch "Heartbleed" kompromittierbar sind solche Schlüssel, die nicht in einem Server-Prozess vorliegen, z.B. die geheimen Schlüssel von CA-, OCSP-, Zeitstempeldiensten, wie sie für PKIs typisch sind. Üblicherweise werden solche Schlüssel in Hardware-Security-Modulen gespeichert und auch die kryptographischen Funktionen werden in diesen Modulen implementiert. Damit sind diese Schlüssel gegen Kopieren geschützt und liegen z.B. im Falle der CA-Schlüssel auch nicht auf Systemen, die aus dem Internet erreicht werden könnten.
Weitere Informationen:
http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/
Status von DFN-Diensten
Das DFN-CERT hat seine eigenen Systeme und, als Betreiber der DFN-PKI, alle von dem Fehler betroffenen Anwendungsserver umgehend gepatcht und danach alle relevanten und potentiell kompromittierten Serverzertifikate ausgetauscht. Damit gibt es keine Möglichkeit mehr, über die Schwachstelle eine Kompromittierung der verschlüsselten Zugänge zu bewerkstelligen. Es liegen keine Hinweise vor, dass eine Kompromittierung erfolgte; die Prozesse, die vom DFN-CERT Portal unterstützt werden, benötigen keine Passworte, sondern basieren auf X.509-Nutzer-Zertifikaten.
Maßnahmen für Betreiber
Es besteht eine große Unsicherheit, wie Nutzer und Betreiber sich jetzt richtig verhalten. Wir empfehlen allen Betreiber von TLS-Anwendungen das folgende Vorgehen. Im anschließenden Abschnitt haben wir Tipps für Nutzer.
1) Prüfen auf Angreifbarkeit
Da die OpenSSL-Bibliotheken in der Regel als Teilpaket einer Distribution bzw. Bestandteil einer Software oder Hardware installiert werden, kann es im Einzelfall eine anspruchsvolle Aufgabe sein, die tatsächlich auf einem Server verwendete OpenSSL-Version festzustellen. Einige Werkzeuge von Dritten können Sie dabei unterstützen, gezielt Ihre Webserver auf eine Angreifbarkeit über "Heartbleed" zu überprüfen.
Kommandozeilen-Werkzeug
Web-Test
2) Beheben der Schwachstelle
Wenn Sie betroffen sind, müssen Sie so schnell wie möglich das OpenSSL-Paket aktualisieren. Nach der Aktualisierung müssen Sie dafür sorgen, dass Ihr System die neue Version verwendet (mindestens einen Neustart aller Server-Software, die OpenSSL nutzt, durchführen).
Tipp: "lsof -n / grep ssol / grep DEL"
Nachdem Sie die Software aktualisiert haben, müssen Sie für alle betroffenen Anwendungen die bis zur Aktualisierung der Anwendung verwendeten privaten Schlüssel ersetzen. Es müssen unbedingt neue private Schlüssel erzeugt werden und entsprechend neue Zertifikate ausstellt werden. Da die Schwachstelle das unbemerkte Auslesen des privaten Schlüssels Ihrer Anwendung aus der Ferne ermöglicht, müssen Sie an dieser Stelle auf Nummer sicher gehen.
Die alten Zertifikate müssen nach erfolgreichem Austausch noch gesperrt werden, damit Angreifer diese nicht weiter verwenden können.
3) Weitere Maßnahmen
Unter Ausnutzung der OpenSSL-Schwachstelle "Heartbleed" könnten auch weitere sensible Daten wie Benutzername/Passwort (z.B. beim Login in ein Webmail-System, IMAP/POP/SMTP-STARTTLS) aus dem Speicher ausgelesen worden sein. Wir empfehlen Ihnen deshalb dringend, sich möglichst umgehend ein Bild der möglichen Auswirkungen auf derartige Benutzeranmeldedaten für Ihren Zuständigkeitsbereich zu machen. Das Risiko kompromittierter Passwörter steigt mit dem Zeitraum, über den angreifbare Versionen von OpenSSL im Einsatz waren, sowie der Anzahl der tatsächlich erfolgten Logins von einzelnen Benutzern, an.
Bitte prüfen Sie deshalb auf der Basis Ihrer Analyse (Umfang der möglichen Kompromittierung von Passwörtern) sowie weiterer Kriterien, wie Praktikabilität (Benutzereinbindung, mögliche Informationskanäle), ob
- entweder betroffene Benutzer informiert werden müssen, ihre Passwörter zu ändern,
- pauschal alle Benutzer dazu aufgefordert werden sollten, ihre Passwörter zu ändern,
- sogar alle Passwörter in einer konzertierten Aktion zurückgesetzt werden sollten, oder
- Benutzer bei der nächsten Anmeldung ein neues Passwort eingeben müssen.
Es ist für die Benutzer Ihrer Dienste wichtig zu wissen, ob Ihre Dienste sicher bzw. wieder sicher sind. Wenn es Ihnen möglich ist, kommunizieren Sie dies bitte über Ihre Homepage oder andere Kommunikationsmedien, die Ihnen zur Verfügung stehen.
Maßnahmen für Benutzer
Als Nutzer von Diensten hängen Sie direkt von den Maßnahmen der Betreiber der Dienste ab. Auch wenn es aufgrund der vielen Unbekannten schwierig ist Ruhe zu bewahren, ist dies das Gebot der Stunde. Geben Sie den Betreibern und Sicherheitsverantwortlichen Zeit, ihre Aufgaben zu erfüllen. Diese sind nicht immer so einfach bzw. hängen von anderen Prozessen ab, die für Benutzer nicht offensichtlich sind, und erfordern Zeit. Natürlich muss schnell gehandelt werden, aber auch bei einem solch kritischen Fehler müssen etablierte Prozesse befolgt werden; purer Aktionismus führt nur zu Folgeproblemen.
Sobald Sie wissen, dass Ihr Betreiber vorher verwundbare Systeme gepatcht hat und neue Zertifikate ausgestellt wurden, sollten Sie Ihre Passworte ändern. Hierzu ist es hilfreich, wenn die Betreiber – wie wir empfehlen – selbst auf die Nutzer zugehen, denn dass jeder Benutzer bei der Hotline anruft ist sicher auch nicht im Sinne aller Betroffenen. Viele Betreiber haben die Situation erkannt und informieren z.B. über die Homepages entsprechend.
Für den Fall, dass Passwörter geändert werden müssen, sollten Sie überlegen, ob Sie die betroffene Email-Adresse und das bisherige Passwort, oder auch nur das Passwort außerdem noch für andere Dienste verwendet haben. Das Passwort sollten Sie dann auch bei durch den Heartbleed-Bug nicht betroffenen Systemen ändern. Grundsätzlich sollten Sie unbedingt vermeiden, dieselben Passwörter für verschiedene Systeme/Dienste zu verwenden.
Auf keinen Fall sollten Sie selbst anfangen, nach verwundbaren Systemen zu suchen. Noch schlimmer ist es, Programme zu nutzen, die im Internet frei verfügbar sind und die Schwachstelle zum Diebstahl von Daten verwenden. In Deutschland ist es strafbar, wenn sich jemand z.B. durch diesen Fehler Benutzernamen und Passworte von Dritten verschafft. Durch den Einsatz eines im Konzept sicheren TLS-Protokolls wird eindeutig eine Sicherheitsmaßnahme eingesetzt, auch wenn diese in diesem Fall konkret fehlerhaft ist. Damit ist klar, dass die geschützten Daten nicht für Unbefugte zugänglich sein sollen.
Ausblick
Der "Heartbleed"-Bug öffnet sicherlich eine neue Dimension der Angreifbarkeit von Internet-Diensten, sowohl hinsichtlich des Ausmaßes des Problems als auch der Kritikalität. Und "Heartbleed" verunsichert, denn es greift uns gerade dort an, wo wir an Sicherheit geglaubt haben. Der Sicherheitsmechanismus SSL/TLS-Verschlüsselung selbst wurde nicht unsicher, aber indem eine "kleine" Schwachstelle in einer sonst nützlichen Funktion ausgenutzt wurde, um geheime Schlüssel und sensible Daten auszuspähen, entfiel die Grundlage für jedwede Sicherheit.
So erschreckend dieses Szenario sein mag, ist es sicher nicht das Ende des Internets und auch nicht der SSL/TLS-Verfahren. Es zeigt uns aber deutlich, dass der "Rüstungswettlauf" zwischen der "dunklen Seite der Macht" und dem Hunger nach technischem Fortschritt eine neue Stufe erreicht hat. Bewusstsein für die möglichen Risiken, Information über Gefahren, präventiven und schadensbegrenzenden Abwehrmaßnahmen und zügiger, effizienter Umsetzung kommt eine stetig wachsende Bedeutung zu. Nur in enger Vernetzung von Herstellern, CERTs und anderen Organisationen, national wie international, sowie Anwendern und Nutzern werden wir auch zukünftig in diesem Wettlauf Schritt halten können.
Wenn die unmittelbaren Folgen des Heartbleed-Bugs überstanden sind, werden wir als DFN-CERT mit unseren Partnern die Lektionen, die es diesmal zu lernen gab, zusammentragen und diese in die Praxis umsetzen.
