Schwache SSL-Zertifikate

Kritische Schwachstelle bei der Erstellung von Krypto-Schlüsseln unter Debianbasierten Linuxdistributionen

Aufgrund eines Fehlers im OpenSSL-Paket von Debian müssen alle nach September 2006 unter Debian (bzw. darauf aufsetzenden Distributionen wie Ubunto oder Knoppix) erzeugten Krypto-Schlüssel aus dem Verkehr gezogen und duch neue Schlüssel ersetzt werden. Dies betrifft insbesondere Schlüssel für SSH, OpenVPN oder SSL-Zertifikate. Insbesondere müssen die zugehörigen Public Keys von allen Systemen entfernt werden, bei denen diese für eine Authentifizierung eingesetzt werden.

Gefährdete Systeme:

Alle Systeme auf denen das schadhafte Schlüsselmaterial verwendet wird. D.h. nicht nur die Systeme, auf denen das Schlüsselmaterial erzeugt wurde!

Hintergrund:

Aufgrund einer fehlerhaften Änderung des OpenSSL-Pakets im Mai 2006 in Debian/unstable und Debian/etch wurden bei der Verwendung dieser Distributionen und der darauf aufbauenden Distributionen wie Ubuntu, Knoppix, ... seit 2006 fehlerhafte Krypto-Schlüssel erzeugt. Der Fehler wirkte sich derart aus, dass bei der Schlüsselerzeugung über OpenSSL pro Schlüsseltyp lediglich 32767 unterschiedliche Schlüssel möglich waren! Dies betrifft sowohl Schlüssel, die direkt mit OpenSSL erzeugt wurden, als auch Schlüssel, die in anderen Programmen erzeugt wurden, falls diese Programme sich wiederum auf OpenSSL abstützen.

Betroffene Softwarepakete sind unter anderem:

• OpenSSH
• SSL-Verbindungen (Z.B. HTTPS)
• Betrieb eigener PKI-Hierarchien
• Dropbear
• OpenVPN
• encfs
• TOR
• ...

Eine Liste der Debian- bzw. Ubuntu-basierten Distributionen ist unter diesem Link einsehbar. Die Distributoren stellen aktuell bereinigte OpenSSL-Pakete zur verfügung, in denen der Fehler bei der Schlüsselerzeugung behoben wurde.

Auswirkungen:

Das kritische Element sind die mit dem fehlerhaften Paket erzeugten schadhaften Schlüssel, da diese zur Identifikation und Authentifizierung von Nutzern bzw. Rechnern verwendet werden. Dies trifft z.B. bei OpenSSH unter Verwendung der Datei "authorized_keys" zum passwortlosen Login zu. Es genügt dabei nicht, einfach einen neuen Schlüssel zu erzeugen und auf dem Zielsystem abzulegen. Vielmehr müssen sämtliche Referenzen auf die schadhaften Schlüssel getilgt werden, da das Zielsystem z.B. bei der Verwendung von authorized_keys einen Nutzer allein anhand des dort abgelegten öffentlichen Schlüssels identifiziert, indem es über kryptografische Methoden sicherstellt, dass der Nutzer sich im Besitz des zugehörigen geheimen/privaten Schlüssels befindet.

Sämtliche mögliche Schlüssel sind mittlerweile vorberechnet im Internet verfügbar. Ebenso gibt es Programme, die Systeme nach schadhaften öffentlichen Schlüsseln abscannen. Ein Angreifer kann somit bei Kenntnis des öffentlichen Schlüssels den zugehörigen geheimen Schlüssel direkt in der Liste nachschlagen. Falls der öffentliche Schlüssel nicht allgemein bekannt ist, dann kann der Angreifer einfach alle bekannten Schlüssel durchprobieren, was bei 32767 Möglichkeiten pro Schlüsseltyp nicht besonders aufwändig ist.

Empfohlenes Vorgehen:

1. Entfernen schadhafter Public Keys aus den jeweiligen Dateien (z.B. authorized_keys)
2. Erzeugen neuer Schlüssel, falls das bisherige Material unter einem betroffenen System erstellt wurde.
3. Insbesondere bei Servern ist zu überprüfen, ob schadhaftes Schlüsselmaterial zur Zugangskontrolle verwendet wird.
4. Einschränkung im Zielsystem insbesondere des SSH-Zugriffs auf die notwendigen Accounts/Gegenstellen.

Weiterführende Informationen

Das Debian-Wiki  stellt weitergehende Informationen bereit.
 

 

Überprüfen von SSH-Schlüsseln auf die Debianschwachstelle

Um vorhandene Public Keys auf die genannte Schwachstelle zu überprüfen, hat das Debian-Projekt ein Script erstellt. Das soll als "Schnelltest" fungieren, um SSH-Hostkeys, Nutzerschlüssel (und nach entsprechender Behandlung) auch SSL-Schlüssel zu überprüfen. Das Script testet dabei leider nur Schlüssel, die mit den Standardoptionen (Größe, Typ) erstellt wurden und auch bei diesen werden anscheinend nur die wahrscheinlichsten Schlüssel abgetestet.

Achtung: Das Script enthält einen Kommentar, laut dem die Vollständigkeit der enthaltenen Signaturen nicht gewährleistet ist!

Der Aufruf des Scripts erfolgt mit:

# perl dowkd.pl <Befehl> <Parameter>

Falls keine Befehle übergeben werden, dann wird eine kurze Hilfe ausgegeben:

# perl dowkd.pl

Testen der Hostkeys (auch über das Netz möglich)

Der Test erfolgt als normaler Nutzer mit:

# perl dowkd.pl host <host1> <host2> ...

Beispiel:

# perl dowkd.pl host localhost webhost

# localhost SSH-2.0-OpenSSH_4.7
# webhost SSH-1.99-OpenSSH_4.2
# localhost SSH-2.0-OpenSSH_4.7
# webhost SSH-1.99-OpenSSH_4.2
localhost: weak key
localhost: weak key

Testen der Public Keys in Nutzerverzeichnissen

Getestet werden die Dateien "authorized_keys", "authorized_keys2", "known_hosts", "id_rsa.pub" und "id_dsa.pub". Als normaler Nutzer kann man lediglich seine eigenen Publlic Keys überprüfen. Als root ist es möglich, die Schlüssel aller Nutzer zu testen.

Der Aufruf erfolgt mit:

# perl dowkd.pl user <username>

 Beispiel (als testuser angemeldet):

# perl dowkd.pl user testuser

/home/testuser/.ssh/authorized_keys:1: warning: unparsable line
/home/testuser/.ssh/authorized_keys:2: warning: unparsable line
/home/testuser/.ssh/authorized_keys:3: warning: no suitable blacklist
/home/testuser/.ssh/authorized_keys:5: warning: weak key
/home/testuser/.ssh/known_hosts:48: weak key

In den Zeilen 1 und 2 der Datei "authorized_keys" befinden sich Inhalte, die vom Script nicht als Schlüsselmaterial erkannt werden (z.B. Kommentare)

In der Zeile 3 der Datei "authorized_keys" ist ein Schlüssel enthalten, zu dessen Format (RSA/DSA + Schlüsselgröße) das Script keine Liste fehlerhafter Schlüssel besitzt. Falls die Wahrscheinlichkeit besteht, dass der Schlüssel auf einem betroffenen System erstellt wurde, dann wird dringend empfohlen ihn auszutauschen.

In der Zeile 5 der Datei "authorized_keys" ist ein definitv schadhafter Public Key enthalten, der den Zugriff auf den Account ermöglicht. Dieser Schlüssel muss ersetzt werden.

In der Datei "known_hosts" wurde ein schadhafter Hostkey eines Systems gefunden, zu dem sich der Nutzer in der Vergangenheit verbunden hat. Der dortige Hostkey muss ersetzt werden.

Testen sonstiger Dateien

Die oben angegebenen Befehle suchen an fest vorgegebenen Stellen im System nach festgelegten Dateinamen. Andere Dateien können mit folgendem Aufruf getestet werden:

# perl dowkd.pl file <Dateiname>