g0tmi1k/debian-sshDebian OpenSSL vorhersagbarer PRNG (CVE-2008-0166)
Original-URL: [http://metasploit.com/users/hdm/tools/debian-openssl/][1] ([Mirror][2])
Exploit:
Empfohlenes Tool: [Crowbar][13] (geeignet zum Brute-Forcen von SSH-Schlüsseln)
Testmethode: [ssh-vulnkey][14] & [dowkd.pl][15]
CVE (CVE-2008-0166):
Am 13. Mai 2008 gab das Debian-Projekt [bekannt][5], dass Luciano Bello eine interessante Schwachstelle im von ihnen vertriebenen OpenSSL-Paket gefunden hatte. Der betreffende Fehler wurde durch die Entfernung der folgenden Codezeile aus md_rand.c verursacht
MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */
Diese Zeilen wurden [entfernt][6], weil sie dazu führten, dass die Tools [Valgrind][7] und Purify Warnungen über die Verwendung nicht initialisierter Daten in Code ausgaben, der mit OpenSSL verknüpft war. Einen solchen Bericht an das OpenSSL-Team finden Sie [hier][8]. Die Entfernung dieses Codes hatte den Nebeneffekt, dass der Seed-Prozess des OpenSSL-PRNG lahmgelegt wurde. Anstatt Zufallsdaten für den initialen Seed zu mischen, wurde als einziger „zufälliger“ Wert die aktuelle Prozess-ID verwendet. Auf der Linux-Plattform beträgt die standardmäßige maximale Prozess-ID 32.768, was dazu führt, dass für alle PRNG-Operationen nur eine sehr kleine Anzahl von Seed-Werten verwendet wird.
Alle SSL- und SSH-Schlüssel, die auf Debian-basierten Systemen (Ubuntu, Kubuntu usw.) zwischen September 2006 und dem 13. Mai 2008 generiert wurden, könnten betroffen sein. Im Fall von SSL-Schlüsseln müssen alle erstellten Zertifikate neu erstellt und zur Signatur an die Zertifizierungsstelle gesendet werden. Alle Zertifizierungsstellenschlüssel, die auf einem Debian-basierten System generiert wurden, müssen neu generiert und widerrufen werden. Alle Systemadministratoren, die Benutzern den Zugriff auf ihre Server mit SSH und Public-Key-Authentifizierung erlauben, müssen diese Schlüssel überprüfen, um festzustellen, ob einer von ihnen auf einem anfälligen System erstellt wurde. Jedes Tool, das sich auf den OpenSSL-PRNG verlassen hat, um die übertragenen Daten zu sichern, könnte anfällig für einen Offline-Angriff sein. Jeder SSH-Server, der einen Host-Schlüssel verwendet, der von einem fehlerhaften System generiert wurde, unterliegt der Entschlüsselung des Datenverkehrs, und ein Man-in-the-Middle-Angriff wäre für die Benutzer unsichtbar. Dieser Fehler ist hässlich, weil sogar Systeme, die die Debian-Software nicht verwenden, überprüft werden müssen, falls ein Schlüssel verwendet wird, der auf einem Debian-System erstellt wurde. Die Debian- und Ubuntu-Projekte haben eine Reihe von Tools zur Identifizierung anfälliger Schlüssel veröffentlicht. Diese finden Sie im Referenzabschnitt unten.
Die von Debian und Ubuntu veröffentlichten Blacklists zeigen, wie klein der Schlüsselraum tatsächlich ist. Beim Erstellen eines neuen OpenSSH-Schlüssels gibt es für eine bestimmte Architektur, Schlüsselgröße und Schlüsselart nur 32.767 mögliche Ergebnisse. Der Grund ist, dass die einzigen „zufälligen“ Daten, die vom PRNG verwendet werden, die ID des Prozesses sind. Um die tatsächlichen Schlüssel zu generieren, die diesen Blacklists entsprechen, benötigen wir ein System, das die korrekten Binärdateien für die Zielplattform enthält, sowie eine Möglichkeit, Schlüssel mit einer bestimmten Prozess-ID zu generieren. Um das Problem der Prozess-ID zu lösen, habe ich eine [shared library][9] geschrieben, die vorgeladen werden kann und einen benutzerspezifizierten Wert für den getpid()-Libc-Aufruf zurückgibt.
Der nächste Schritt war die Erstellung einer Chroot-Umgebung, die die tatsächlichen Binärdateien und Bibliotheken eines anfälligen Systems enthielt. Ich habe einen Snapshot von einem Ubuntu-System im lokalen Netzwerk genommen. Die gesamte Chroot-Umgebung finden Sie [hier][10]. Um einen OpenSSH-Schlüssel mit einem bestimmten Typ, einer bestimmten Bitanzahl und einer bestimmten Prozess-ID zu generieren, habe ich ein Shell-Skript geschrieben, das innerhalb der Chroot-Umgebung ausgeführt werden kann. Dieses Shell-Skript finden Sie [hier][11]. Dieses Skript wird im Wurzelverzeichnis des extrahierten Ubuntu-Dateisystems platziert. Um einen Schlüssel zu generieren, wird dieses Skript mit der folgenden Befehlszeile aufgerufen:
# chroot ubunturoot /dokeygen.sh 1 -t dsa -b 1024 -f /tmp/dsa_1024_1
Dies generiert einen neuen OpenSSH 1024-Bit-DSA-Schlüssel, wobei getpid() immer den Wert „1“ zurückgibt. Wir haben nun unseren ersten vorab generierten SSH-Schlüssel. Wenn wir diesen Vorgang für alle PIDs bis 32.767 fortsetzen und dann für 2048-Bit-RSA-Schlüssel wiederholen, decken wir die gültigen Schlüsselbereiche für x86-Systeme ab, die die fehlerhafte Version der OpenSSL-Bibliothek ausführen. Mit diesem Schlüsselsatz können wir jedes Benutzerkonto kompromittieren, das einen anfälligen Schlüssel in der Datei authorized_keys aufgeführt hat. Dieser Schlüsselsatz ist auch nützlich, um eine zuvor aufgezeichnete SSH-Sitzung zu entschlüsseln, wenn der SSH-Server einen anfälligen Host-Schlüssel verwendet hat. Links zu den vorab generierten Schlüsselsätzen für 1024-Bit-DSA- und 2048-Bit-RSA-Schlüssel (x86) finden Sie im Download-Bereich unten.
Das Interessante an diesen Schlüsseln ist, wie sie an die Prozess-ID gebunden sind. Da die meisten Debian-basierten Systeme sequentielle Prozess-ID-Werte verwenden (beginnend mit dem Systemstart und bei Bedarf zurückgesetzt), kann die Prozess-ID eines bestimmten Schlüssels auch darauf hinweisen, wie bald nach dem Systemstart dieser Schlüssel generiert wurde. Wenn wir die Umkehrung betrachten, können wir basierend auf dem Ziel, das wir angreifen, bestimmen, welche Schlüssel wir bei einem Brute-Force-Angriff verwenden sollen. Beim Versuch, einen beim Systemstart generierten Schlüssel zu erraten (wie einen SSH-Host-Schlüssel), wären Schlüssel mit PID-Werten unter 200 die besten Optionen für einen Brute-Force-Angriff. Beim Angriff auf einen benutzergenerierten Schlüssel können wir annehmen, dass die meisten gültigen Benutzerschlüssel mit einer Prozess-ID größer als 500 und kleiner als 10.000 erstellt wurden. Diese Optimierung kann einen Brute-Force-Angriff auf ein entferntes Benutzerkonto über das SSH-Protokoll erheblich beschleunigen.
In naher Zukunft wird diese Seite aktualisiert, um ein Brute-Force-Tool zu enthalten, das verwendet werden kann, um schnell Zugriff auf jedes SSH-Konto zu erhalten, das eine Public-Key-Authentifizierung mit einem anfälligen Schlüssel erlaubt. Die Schlüssel in den folgenden Datendateien verwenden die folgende Namenskonvention:
/ Algorithmus / Bits / Fingerabdruck-ProzessID
und
/ Algorithmus / Bits / Fingerabdruck-ProzessID.pub
Um die private Schlüsseldatei für einen bestimmten öffentlichen Schlüssel zu erhalten, müssen Sie den Schlüsselfingerabdruck kennen. Der einfachste Weg, diesen Fingerabdruck zu erhalten, ist der folgende Befehl:
$ ssh-keygen -l -f targetkey.pub
2048 c6:7b:14:fa:ae:b6:89:e6:67:17:ee:04:17:b0:ec:4e targetkey.pub
Wenn wir den öffentlichen Schlüssel in einem Editor betrachten, können wir auch ableiten, dass der Schlüsseltyp RSA ist. Um den privaten Schlüssel für diesen öffentlichen Schlüssel zu finden, müssen wir die Datendateien extrahieren und nach einer Datei mit dem Namen suchen:
rsa/2048/**c67b14faaeb689e66717ee0417b0ec4e-26670**