Diese Sicherheitsanfälligkeit hat große potenzielle Auswirkungen, da Ihr System nach einem Angriff auch nach dem Patchen anfällig bleibt und Angriffe möglicherweise keine Spuren in den Protokollen hinterlassen haben. Wenn Sie schnell gepatcht haben und kein hochkarätiges Ziel sind, ist wahrscheinlich niemand dazu gekommen, Sie anzugreifen, aber es ist schwer, sicher zu sein.
Bin ich verletzlich?
Die fehlerhafte Version von OpenSSL
Die fehlerhafte Software ist die OpenSSL-Bibliothek 1.0.1 bis 1.0.1f und OpenSSL 1.0.2 bis Beta1. Ältere Versionen (0.9.x, 1.0.0) und Versionen, in denen der Fehler behoben wurde (ab 1.0.1g, ab 1.0.2 Beta 2), sind nicht betroffen. Es ist ein Implementierungsfehler, kein Fehler im Protokoll, daher sind nur Programme betroffen, die die OpenSSL-Bibliothek verwenden.
Mit dem Befehlszeilentool können Sie openssl version -adie OpenSSL-Versionsnummer anzeigen. Beachten Sie, dass einige Distributionen die Fehlerbehebung auf frühere Releases portieren. Wenn das Änderungsprotokoll Ihres Pakets die Heartbleed-Fehlerbehebung erwähnt, ist dies in Ordnung, auch wenn Sie eine Version wie 1.0.1f sehen. Wenn Sie openssl version -aein Erstellungsdatum (nicht das Datum in der ersten Zeile) vom 07.04.2014 gegen Abend UTC oder später erwähnen, sollten Sie in Ordnung sein. Beachten Sie, dass das OpenSSL-Paket möglicherweise 1.0.0einen Namen hat , obwohl die Version 1.0.1 lautet ( 1.0.0bezieht sich auf die Binärkompatibilität).
Betroffene Anwendungen
Die Ausnutzung erfolgt über eine Anwendung, die die OpenSSL-Bibliothek zum Implementieren von SSL-Verbindungen verwendet . Viele Anwendungen verwenden OpenSSL für andere kryptografische Dienste, und das ist in Ordnung: Der Fehler liegt in der Implementierung einer bestimmten Funktion des SSL-Protokolls, dem „Heartbeat“.
Möglicherweise möchten Sie überprüfen, welche Programme mit der Bibliothek auf Ihrem System verknüpft sind. Auf Systemen, die dpkg und apt verwenden (Debian, Ubuntu, Mint,…), listet der folgende Befehl installierte Pakete auf, die keine Bibliotheken verwenden libssl1.0.0(das betroffene Paket):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
Wenn Sie eine Serversoftware ausführen , die in dieser Liste aufgeführt ist und SSL-Verbindungen überwachtSie sind wahrscheinlich betroffen. Dies betrifft Webserver, E-Mail-Server, VPN-Server usw. Sie wissen, dass Sie SSL aktiviert haben, weil Sie ein Zertifikat generieren mussten, indem Sie eine Zertifikatsignierungsanforderung an eine Zertifizierungsstelle senden oder Ihre eigene Signatur erstellen Zertifikat. (Es ist möglich, dass bei einer Installationsprozedur ein selbstsigniertes Zertifikat generiert wurde, ohne dass Sie es bemerken. Dies gilt jedoch im Allgemeinen nur für interne Server, nicht für Server, die dem Internet ausgesetzt sind.) Wenn Sie einen anfälligen Server ausgeführt haben, der dem Internet ausgesetzt ist, sollten Sie ihn als gefährdet betrachten es sei denn, Ihre Protokolle weisen seit der Ankündigung am 07.04.2014 keine Verbindung mehr auf. (Dies setzt voraus, dass die Sicherheitsanfälligkeit vor ihrer Bekanntgabe nicht ausgenutzt wurde.) Wenn Ihr Server nur intern verfügbar gemacht wurde,
Die Client-Software ist nur betroffen, wenn Sie sie zum Herstellen einer Verbindung mit einem böswilligen Server verwendet haben. Wenn Sie also über IMAPS eine Verbindung zu Ihrem E-Mail-Anbieter hergestellt haben, müssen Sie sich keine Sorgen machen (es sei denn, der Anbieter wurde angegriffen - in diesem Fall sollten Sie dies jedoch wissen lassen) sich Sorgen machen. Bisher wurde die Sicherheitsanfälligkeit anscheinend nicht ausgenutzt, bevor sie entdeckt wurde. Sie müssen sich also nur Sorgen machen, wenn Sie seit dem 08.04.2014 eine Verbindung zu bösartigen Servern hergestellt haben.
Die folgenden Programme sind nicht betroffen, da sie OpenSSL nicht zum Implementieren von SSL verwenden:
- SSH (das Protokoll ist nicht SSL)
- Chrome / Chromium ( verwendet NSS )
- Firefox (benutzt NSS) (zumindest mit Firefox 27 unter Ubuntu 12.04, aber nicht mit allen Builds?
Was ist die Auswirkung?
Der Fehler ermöglicht es jedem Client, der eine Verbindung zu Ihrem SSL-Server herstellen kann, ca. 64 KB Arbeitsspeicher gleichzeitig vom Server abzurufen. Der Client muss in keiner Weise authentifiziert werden. Durch Wiederholen des Angriffs kann der Client in aufeinanderfolgenden Versuchen verschiedene Teile des Speichers sichern. Dadurch kann der Angreifer möglicherweise alle Daten abrufen, die sich im Speicher des Serverprozesses befunden haben, einschließlich Schlüssel, Kennwörter, Cookies usw.
Einer der kritischen Datenbestandteile, die der Angreifer möglicherweise abrufen kann, ist der private SSL-Schlüssel des Servers. Mit diesen Daten kann sich der Angreifer als Ihr Server ausgeben.
Der Fehler ermöglicht es auch jedem Server, mit dem Ihr SSL-Client verbunden ist, ungefähr 64 KB Speicher auf einmal vom Client abzurufen. Dies ist problematisch, wenn Sie einen anfälligen Client zum Manipulieren vertraulicher Daten verwendet und später mit demselben Client eine Verbindung zu einem nicht vertrauenswürdigen Server hergestellt haben. Die Angriffsszenarien auf dieser Seite sind daher deutlich unwahrscheinlicher als auf der Serverseite.
Beachten Sie, dass für typische Distributionen keine Auswirkungen auf die Sicherheit der Paketverteilung bestehen, da die Integrität von Paketen von GPG-Signaturen und nicht vom SSL-Transport abhängt.
Wie behebe ich die Sicherheitsanfälligkeit?
Sanierung von exponierten Servern
Schalten Sie alle betroffenen Server offline. Solange sie ausgeführt werden, können wichtige Daten verloren gehen.
Aktualisieren Sie das OpenSSL-Bibliothekspaket . Alle Distributionen sollten jetzt ein Update haben (entweder mit 1.0.1g oder mit einem Patch, der den Fehler behebt, ohne die Versionsnummer zu ändern). Wenn Sie von der Quelle kompiliert haben, aktualisieren Sie auf 1.0.1g oder höher. Stellen Sie sicher, dass alle betroffenen Server neu gestartet werden.
Unter Linux können Sie überprüfen, ob möglicherweise betroffene Prozesse noch ausgeführt werdengrep 'libssl.*(deleted)' /proc/*/maps
Generieren Sie neue Schlüssel . Dies ist erforderlich, da der Fehler möglicherweise einem Angreifer ermöglicht hat, den alten privaten Schlüssel abzurufen. Gehen Sie genauso vor, wie Sie es ursprünglich getan haben.
- Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwenden, senden Sie Ihre neuen öffentlichen Schlüssel an Ihre Zertifizierungsstelle. Wenn Sie das neue Zertifikat erhalten, installieren Sie es auf Ihrem Server.
- Wenn Sie selbstsignierte Zertifikate verwenden, installieren Sie diese auf Ihrem Server.
- Bewegen Sie in jedem Fall die alten Schlüssel und Zertifikate aus dem Weg (aber löschen Sie sie nicht, stellen Sie nur sicher, dass sie nicht mehr verwendet werden).
Jetzt, da Sie neue, kompromisslose Schlüssel haben, können Sie Ihren Server wieder online schalten .
Sperren Sie die alten Zertifikate.
Schadensbewertung : Alle Daten, die sich im Speicher eines Prozesses befanden, der SSL-Verbindungen bedient, sind möglicherweise durchgesickert. Dies kann Benutzerkennwörter und andere vertrauliche Daten umfassen. Sie müssen auswerten, wie diese Daten gewesen sein könnten.
- Wenn Sie einen Dienst ausführen, der die Kennwortauthentifizierung ermöglicht, sollten die Kennwörter von Benutzern, die sich kurz vor Bekanntgabe der Sicherheitsanfälligkeit angemeldet haben, als gefährdet eingestuft werden. Überprüfen Sie Ihre Protokolle und ändern Sie die Kennwörter aller betroffenen Benutzer.
- Deaktivieren Sie auch alle Sitzungscookies, da diese möglicherweise kompromittiert wurden.
- Client-Zertifikate werden nicht gefährdet.
- Alle Daten, die kurz vor der Sicherheitsanfälligkeit ausgetauscht wurden, befinden sich möglicherweise noch im Speicher des Servers und wurden möglicherweise an einen Angreifer weitergegeben.
- Wenn jemand eine alte SSL-Verbindung aufgezeichnet und die Schlüssel Ihres Servers abgerufen hat, kann er jetzt sein Transkript entschlüsseln. (Es sei denn, PFS wurde sichergestellt - wenn Sie nicht wissen, war es nicht.)
Sanierung in anderen Fällen
Server, die nur auf localhost oder in einem Intranet empfangsbereit sind, gelten nur dann als verfügbar, wenn nicht vertrauenswürdige Benutzer eine Verbindung zu ihnen herstellen können.
Bei Clients gibt es nur selten Szenarien, in denen der Fehler ausgenutzt werden kann: Für einen Exploit muss derselbe Client-Prozess verwendet werden
- vertrauliche Daten manipulieren (z. B. Passwörter, Client-Zertifikate, ...);
- und dann im selben Prozess über SSL mit einem böswilligen Server verbunden.
So ist beispielsweise ein E-Mail-Client, mit dem Sie nur eine Verbindung zu Ihrem (nicht vollständig nicht vertrauenswürdigen) E-Mail-Anbieter herstellen, kein Problem (kein bösartiger Server). Das Ausführen von wget zum Herunterladen einer Datei ist kein Problem (keine vertraulichen Daten zu verlieren).
Wenn Sie dies zwischen dem 07.04.2014 (UTC) und dem Upgrade Ihrer OpenSSL-Bibliothek getan haben, sollten Sie alle Daten, die sich im Speicher des Clients befanden, als gefährdet betrachten.
Verweise