Debian OpenSSL Vorhersagbarer PRNG

Links

Original-URL: http://metasploit.com/users/hdm/tools/debian-openssl/ (Mirror)

Exploit:

Empfohlenes Tool: Crowbar (geeignet zum Brute-Forcen von SSH-Schlüsseln)

Testmethode: ssh-vulnkey & dowkd.pl

CVE (CVE-2008-0166):

Informationen

Der Fehler

Am 13. Mai 2008 gab das Debian-Projekt bekannt, 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, weil sie dazu führten, dass die Tools Valgrind 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. 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.

Die Auswirkungen

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 Spielzeuge

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 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. 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. 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**

Im obigen Beispiel wird der Fingerabdruck hexadezimal ohne Doppelpunkte dargestellt, und die Prozess-ID wird als „26670“ angegeben. Wenn wir uns bei einem anfälligen System authentifizieren möchten, das diesen öffentlichen Schlüssel zur Authentifizierung verwendet, würden wir den folgenden Befehl ausführen:

 $ ssh -i rsa/2048/c67b14faaeb689e66717ee0417b0ec4e-26670 root@targetmachine

Häufig gestellte Fragen

F: Wie lange hat es gedauert, diese Schlüssel zu generieren?

A: Ich habe 31 Xeon-Kerne mit 2,33 GHz verwendet. Es dauerte zwei Stunden, um die 1024-Bit-DSA- und 2048-Bit-RSA-Schlüssel für x86 zu generieren. Die 4096-Bit-RSA-Schlüssel benötigten etwa 6 Stunden. Die Generierung von 8192-Bit-RSA-Schlüsseln würde bei der derzeitigen Rate etwa 100 Stunden dauern und wird wahrscheinlich vor Abschluss gestoppt.

F: Werden Sie Ihren Code zur Verteilung der Schlüsselgenerierung auf mehrere Prozessoren teilen?

A: Nein. Der Code ist hartcodiert für diesen spezifischen Cluster und zu schlecht geschrieben, um ihn zu bereinigen.

F: Wie lange dauert es, einen SSH-Benutzeraccount mit diesen Schlüsseln zu knacken?

A: Das hängt von der Geschwindigkeit des Netzwerks und der Konfiguration des SSH-Servers ab. Es sollte möglich sein, alle 32.767 Schlüssel sowohl von DSA-1024 als auch RSA-2048 innerhalb weniger Stunden auszuprobieren, aber achten Sie auf Anti-Brute-Force-Skripte auf dem Zielserver.

F: Ich verwende 16384-Bit-RSA-Schlüssel, können diese geknackt werden?

A: Ja, es ist nur eine Frage der Zeit und der Rechenleistung. Der 8192-Bit-RSA-Schlüsselsatz würde etwa 3100 Stunden CPU-Zeit benötigen, um alle 32.767 Schlüssel zu generieren (100 Stunden auf den 31 Kernen, die ich derzeit verwende). Ich stelle mir vor, dass der 16384-Bit-RSA-Schlüsselsatz eher 100.000 Stunden CPU-Zeit benötigen würde. Eine Sache, die man bedenken sollte, ist, dass die meisten Schlüssel in einem viel kleineren Bereich liegen, basierend auf dem Prozess-ID-Seed, und der gesamte Satz müsste nicht generiert werden, um die Mehrheit der Benutzerschlüssel abzudecken (die meisten Schlüssel liegen innerhalb der ersten 3.000 Prozess-IDs).

debian-ssh

Beliebteste