OpenSSL-Schwachstelle
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Am 13.05.2008 wurde eine schwerwiegende Schwachstelle in den OpenSSL-Paketen von Debian entdeckt. Diese Schwachstelle entstand auf Grund eines fehlerhaften Patches des Debian-Paketes. Von der Schwachstelle sind alle auf Debian aufbauenden Distributionen und somit auch Ubuntu betroffen. Da die Schwachstelle seit dem 17.09.2006 (OpenSSL Version 0.9.8c-1) existiert, ist die Ubuntu-Version Hardy Heron 8.04 betroffen. Alle Programme, die OpenSSL verwenden, sind von der Schwachstelle betroffen. Es stehen Updates bereit, die die Schwachstelle beheben und in der Regel automatisch während einer Aktualisierung installiert werden.
Hinweis:
Von der Schwachstelle nicht betroffen ist GnuPG und die darauf aufbauende Verschlüsselung, da hier nicht OpenSSL verwendet wird!
Technischer Hintergrund¶
Der fehlerhafte Patch betraf den Zufallszahlgenerator von OpenSSL. Mit Hilfe des Patches sollten Warnmeldungen des Debuggers Valgrind verhindert werden, die aussagten, dass auf nicht initialisierte Variablen lesend zugegriffen wurde (siehe Debian Bug 363516 🇬🇧 ). Generell können durch einen solchen Zugriff Programmfehler entstehen. Es wurde an zwei Stellen in den Quellcode eingegriffen und der lesende Zugriff auskommentiert. An einer Stelle war dies legitim und korrekt, an der anderen Stelle wurde der Zufallszahlengenerator damit de facto außer Betrieb gesetzt (siehe SVN Commit 🇬🇧 ).
Als Folge wurde nun nur noch die Prozess-ID zur Generierung von Zufallszahlen verwendet. Diese nur 16 Bit lange Zahl ist viel zu kurz, um wirklich zufällige Zahlen zu generieren. Pro Schlüsseltyp und -länge gibt es nur 32768 verschiedene Schlüssel (aber nur zwei dieser Kombinationen, nämlich DSA/1024 und RSA/2048, sind weit verbreitet), somit wurden alle mittels OpenSSL erzeugten Schlüssel berechenbar. Besonders SSH-Keys und SSL-Zertifikate, die mit einer fehlerhaften OpenSSL Version erzeugt wurden, sind somit aus einem berechenbaren Schlüsselpool und können per Brute-Force leicht und schnell gebrochen werden. Davon betroffen sind somit alle Anwendungen, die OpenSSL verwenden insbesondere Serveranwendungen.
Achtung!
Durch Einspielen der Updates ist nicht sichergestellt, dass eine Kommunikation sicher ist. Verwendet der Server ein schwaches Zertifikat ist die Kommunikation nicht sicher! Das bedeutet, dass eine aufgezeichnete SSL-Verbindung entschlüsselt werden kann und ein Angreifer somit an den Klartext (z.B. Passwörter) gelangen kann! Leider ist es für einen Anwender nicht möglich, zu überprüfen, ob das Zertifikat schwach ist.
Betroffen sind somit auch andere Systeme als Debian-basierte. Verwendet ein Server ein Zertifikat, dass unter Debian oder einem Derivat generiert wurde, so ist der Server verwundbar. Dabei ist das Betriebssystem des Servers irrelevant. Selbst ein Microsoft-Windows-Server kann durch ein fehlerhaftes Zertifikat betroffen sein. Somit sind prinzipiell alle Anwender durch diese Schwachstelle gefährdet. Hier ist der Adminstrator des Servers gefragt, Sicherheitsupdates und damit neue Zertifikate zu installieren.
SSH¶
Für SSH-Server besteht die größte Gefahr. Hierbei ist es irrelevant, welche Linux-Distribution auf dem Server läuft. Verwendet einer der Nutzer einen schwachen Schlüssel zur Authentifizierung, so kann dieser Account geknackt werden. Brute-Force-Angriffe gegen SSH-Server sind bereits angelaufen! Daher ist es unabdingbar, alle SSH-Schlüssel auf einem SSH-Server zu überprüfen und unsichere zu sperren.
Verwendet man Ubuntu, wird dies automatisch erledigt. Die bereinigte Version überprüft bei jedem Anmeldevorgang automatisch, ob der verwendete Schlüssel verwundbar ist und verweigert in diesem Fall die Anmeldung und schreibt eine Meldung in /var/log/auth.log:
sshd[26085]: Public key a3:80:be:45:83:71:38:dd:7f:06:77:70:c9:83:29:7a blacklisted (see ssh-vulnkey(1))
Für die vereinfachte Überprüfung existiert das Paket openssh-blacklist. Dieses wurde automatisch bei dem Update mitinstalliert. Das Paket enthält ein Programm zum Überprüfen der Schlüssel auf einem Server. Dieses muss man als root-Benutzer ausführen, um alle Benutzerkonten zu überprüfen [1]:
sudo ssh-vulnkey -a
Dieses findet alle Schlüssel und zeigt an, ob diese "Not blacklisted" oder "COMPROMISED" sind. Ein solcher Schlüssel muss unbedingt sofort gesperrt werden, da über ihn ein nicht authorisierter Zugang erfolgen könnte. "Not blacklisted" bedeutet nicht, dass der Schlüssel sicher ist. Es existiert lediglich keine passende Blacklist, da der Schlüssel ein unübliches Format hat.
OpenSSL¶
Auch SSL-Keys sind von der Schwachstelle betroffen. Hier gibt es ebenfalls ein Paket, welches eine Blacklist enthält: openssl-blacklist. Dieses wurde ebenfalls automatisch mit den Updates installiert. Hier gibt es das Programm openssl-vulnkey, welches verwendet werden kann, um einen SSL-Key zu überprüfen [1]. Dafür muss jedoch der Key im PEM-Format vorliegen und man muss das Passwort des Keys besitzen.
openssl-vulnkey key.pem
OpenVPN¶
Auch OpenVPN ist von der Schwachstelle betroffen. Hier gibt es über das Paket openvpn-blacklist ebenfalls eine Blacklist und OpenVPN überprüft Schlüssel beim Verbindungsaufbau und lehnt eine Verbindung ggf. ab. Diese Blacklist bezieht sich jedoch nur auf einen statischen pre-shared Key. Mit folgendem Befehl [1]
openvpn-vulnkey
wird somit nur ein pre-shared Key überprüft. Wer Zertifikate zur Authentifizierung verwendet, muss diese mittels openssl-vulnkey überprüfen.
Links¶