Erstens , bevor ausgeflippt, achten Sie darauf , dass Sie verstehen , ob diese Anfälligkeit für Sie tatsächlich zutrifft. Wenn Sie einen Server haben, aber noch nie Anwendungen mit TLS hatten, müssen Sie dies nicht mit hoher Priorität beheben. Wenn Sie andererseits schon einmal TLS-fähige Anwendungen hatten, werden Sie sich freuen. Weiter lesen:
Was genau ist CVE-2014-0160 aka "Heartbleed"?
Es ist ein großes Durcheinander, das ist es auch. Kurz gesagt, in den OpenSSL-Versionen 1.0.1 bis 1.0.1f wurde eine Sicherheitslücke entdeckt, durch die ein Angreifer bestimmte Teile des Systemspeichers lesen kann. Diese Teile enthalten unter anderem vertrauliche Daten wie private Schlüssel, vorinstallierte Schlüssel, Kennwörter und hochwertige Unternehmensdaten.
Der Fehler wurde unabhängig von Neel Mehta von Google Security (21. März 2014) und dem finnischen IT-Sicherheitstestunternehmen Codenomicon (2. April 2014) entdeckt.
Was ist die Ursache?
Nun, fehlerhafter Code in OpenSSL. Hier ist das Commit, mit dem die Sicherheitsanfälligkeit eingeführt wurde, und hier das Commit, mit dem die Sicherheitsanfälligkeit behoben wurde. Der Fehler trat im Dezember 2011 auf und wurde heute, am 7. April 2014, behoben.
Der Fehler kann auch als Symptom für ein größeres Problem angesehen werden. Die beiden damit verbundenen Probleme sind (1) welche Prozesse vorhanden sind, um sicherzustellen, dass fehlerhafter Code nicht in eine Codebasis eingeführt wird, und (2) warum die Protokolle und Erweiterungen so komplex und schwer zu testen sind. Punkt (1) ist ein Governance- und Prozessproblem bei OpenSSL und vielen anderen Projekten. Viele Entwickler widersetzen sich einfach Praktiken wie Codeüberprüfung, Analyse und Scannen. Punkt (2) wird in der TLS WG der IETF diskutiert. Siehe Heartbleed / Protokollkomplexität .
Wurde der fehlerhafte Code böswillig eingefügt?
Ich werde nicht darüber spekulieren, ob dies wirklich ein Fehler oder möglicherweise ein bisschen Code für einen schlechten Schauspieler war. Die Person, die den Code für OpenSSL entwickelt hat, gibt jedoch an, dass dies versehentlich geschehen ist. Siehe Man, der schwerwiegende Sicherheitslücken bei Heartbleed eingeführt hat, bestreitet, dass er sie absichtlich eingefügt hat .
Welche Betriebssysteme und Versionen von OpenSSL sind anfällig?
Wie oben erwähnt, jedes Betriebssystem oder jede Anwendung, die OpenSSL 1.0.1 bis 1.0.1f verwendet.
Was sind die Symptome, gibt es Methoden, um einen erfolgreichen Exploit zu erkennen?
Dies ist der beängstigende Teil. Uns ist nicht bekannt, ob diese Sicherheitsanfälligkeit ausgenutzt wurde oder nicht. Es ist theoretisch möglich, dass bald IDS-Signaturen veröffentlicht werden, die diesen Exploit erkennen können, aber zum jetzigen Zeitpunkt sind diese nicht verfügbar.
Es gibt Hinweise darauf, dass Heartbleed bereits im November 2013 in freier Wildbahn aktiv ausgebeutet wurde. Sehen Sie, wie die EFF im November 2013 Heartbleed bei Geheimdiensten einsetzte. Bloomberg berichtet, die NSA habe den Exploit kurz nach Einführung der Sicherheitsanfälligkeit als Waffe eingesetzt. Siehe NSA sagte, Heartbleed Bug für Intelligenz seit Jahren auszunutzen . Die US Intelligence Community bestreitet jedoch die Behauptungen von Bloomberg. Siehe IC ON THE RECORD .
Wie kann ich überprüfen, ob mein System betroffen ist?
Wenn Sie OpenSSL auf Ihrem System warten, können Sie einfach Folgendes ausgeben openssl version:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Wenn die Verteilung OpenSSL wird beibehalten, dann können Sie wahrscheinlich nicht die Version von OpenSSL bestimmen aufgrund zurück Patchen mit opensslBefehl oder die Paketinformationen (zum Beispiel apt-get, dpkg, yumoder rpm). Der von den meisten (allen?) Distributionen verwendete Backpatching-Prozess verwendet nur die Basisversionsnummer (z. B. "1.0.1e"). und hat nicht eine umfassen effektive Sicherheits Version (zB „1.0.1g“).
Es gibt eine offene Frage zum Superuser, um die effektive Sicherheitsversion für OpenSSL und andere Pakete zu bestimmen, wenn Pakete zurückgepatcht werden. Leider gibt es keine nützlichen Antworten (außer auf der Website der Distribution). Weitere Informationen finden Sie unter Ermitteln der effektiven Sicherheitsversion bei Backpatching .
Als Faustregel gilt: Wenn Sie jemals eine der betroffenen Versionen installiert und Programme oder Dienste ausgeführt haben, die mit der OpenSSL for TLS-Unterstützung verknüpft sind, sind Sie anfällig.
Wo finde ich ein Programm zum Testen der Sicherheitsanfälligkeit?
Innerhalb weniger Stunden nach der Heartbleed-Ankündigung hatten mehrere Personen im Internet öffentlich zugängliche Webanwendungen veröffentlicht, mit denen angeblich ein Server auf das Vorhandensein dieser Sicherheitsanfälligkeit überprüft werden konnte. Zum jetzigen Zeitpunkt habe ich noch keine Bewertung abgegeben, daher werde ich ihre Bewerbungen nicht weiter veröffentlichen. Sie können mit Hilfe Ihrer bevorzugten Suchmaschine relativ einfach gefunden werden.
Wie wird diese Sicherheitsanfälligkeit verringert?
Aktualisieren Sie auf eine nicht anfällige Version und setzen Sie anfällige Daten zurück oder sichern Sie sie erneut. Wie auf der Heartbleed- Site vermerkt , lauten die entsprechenden Reaktionsschritte im Allgemeinen:
- Patch verwundbarer Systeme.
- Generieren Sie neue private Schlüssel neu.
- Senden Sie einen neuen CSR an Ihre Zertifizierungsstelle.
- Beziehen und installieren Sie das neu signierte Zertifikat.
- Sitzungsschlüssel und Cookies ungültig machen
- Setzen Sie Kennwörter und freigegebene Geheimnisse zurück
- Alte Zertifikate widerrufen.
Eine detailliertere Analyse und Antwort finden Sie unter Was sollte ein Website-Betreiber mit dem Heartbleed OpenSSL-Exploit tun? auf dem Security Stack Exchange.
Sollte ich mir Sorgen machen, dass meine Schlüssel oder andere private Daten kompromittiert wurden? Welche anderen Nebenwirkungen sollten mir Sorgen machen?
Absolut. Systemadministratoren müssen davon ausgehen, dass ihre Server, die anfällige OpenSSL-Versionen verwendet haben, tatsächlich kompromittiert sind, und entsprechend reagieren.
Kurz nachdem die Sicherheitsanfälligkeit bekannt wurde, bot Cloudfare eine Herausforderung an, um zu prüfen, ob der private Schlüssel eines Servers in der Praxis wiederhergestellt werden konnte. Die Herausforderung wurde unabhängig von Fedor Indutny und Ilkka Mattila gewonnen. Siehe Die Heartbleed-Herausforderung .
Wo finde ich weitere Informationen?
Link Dump, für diejenigen, die mehr Details suchen:
Eine ziemlich ausführlichen Zeitplan der Offenlegung Ereignisse finden Sie unter Heartbleed Offenlegung Zeitplan: Wer wusste was und wann .
Wenn Sie ein Programmierer sind und sich für verschiedene Programmiertricks interessieren, wie das Erkennen eines Heartbleed-Angriffs über den OpenSSL- msg_cbRückruf, lesen Sie die OpenSSL- Sicherheitsempfehlung 2014047 .
