g0tmi1k/debian-sshPRNG prevedibile di Debian OpenSSL (CVE-2008-0166)
URL originale: http://metasploit.com/users/hdm/tools/debian-openssl/ (Mirror)
Exploit:
Strumento consigliato: Crowbar (in grado di forzare chiavi SSH)
Metodo di test: ssh-vulnkey & dowkd.pl
CVE (CVE-2008-0166):
Il 13 maggio 2008, il progetto Debian ha annunciato che Luciano Bello aveva trovato una vulnerabilità interessante nel pacchetto OpenSSL che stavano distribuendo. Il bug in questione è stato causato dalla rimozione della seguente riga di codice da md_rand.c
MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */
Queste righe sono state rimosse perché causavano la generazione di avvisi da parte degli strumenti Valgrind e Purify sull'uso di dati non inizializzati in qualsiasi codice collegato a OpenSSL. Puoi vedere un tale rapporto al team di OpenSSL qui. La rimozione di questo codice ha l'effetto collaterale di compromettere il processo di seeding del PRNG di OpenSSL. Invece di mescolare dati casuali per il seed iniziale, l'unico valore 'casuale' utilizzato era l'ID del processo corrente. Sulla piattaforma Linux, l'ID massimo predefinito del processo è 32.768, risultando in un numero molto piccolo di valori di seed utilizzati per tutte le operazioni PRNG.
Tutte le chiavi SSL e SSH generate su sistemi basati su Debian (Ubuntu, Kubuntu, ecc.) tra settembre 2006 e il 13 maggio 2008 potrebbero essere affette. Nel caso delle chiavi SSL, tutti i certificati generati dovranno essere ricreati e inviati all'Autorità di Certificazione per la firma. Qualsiasi chiave di Autorità di Certificazione generata su un sistema basato su Debian dovrà essere rigenerata e revocata. Tutti gli amministratori di sistema che consentono agli utenti di accedere ai propri server con SSH e autenticazione tramite chiave pubblica devono controllare tali chiavi per vedere se qualcuna è stata creata su un sistema vulnerabile. Qualsiasi strumento che si affidava al PRNG di OpenSSL per proteggere i dati trasferiti potrebbe essere vulnerabile a un attacco offline. Qualsiasi server SSH che utilizza una chiave host generata da un sistema difettoso è soggetto a decifratura del traffico e un attacco man-in-the-middle sarebbe invisibile agli utenti. Questa falla è brutta perché anche i sistemi che non utilizzano il software Debian devono essere controllati nel caso in cui venga utilizzata una chiave creata su un sistema Debian. I progetti Debian e Ubuntu hanno rilasciato una serie di strumenti per identificare le chiavi vulnerabili. Puoi trovarli elencati nella sezione riferimenti qui sotto.
Le blacklist pubblicate da Debian e Ubuntu dimostrano quanto sia piccolo lo spazio delle chiavi. Quando si crea una nuova chiave OpenSSH, ci sono solo 32.767 possibili risultati per una data architettura, dimensione della chiave e tipo di chiave. La ragione è che l'unico dato 'casuale' utilizzato dal PRNG è l'ID del processo. Per generare le chiavi effettive che corrispondono a queste blacklist, abbiamo bisogno di un sistema contenente i binari corretti per la piattaforma di destinazione e un modo per generare chiavi con un ID di processo specifico. Per risolvere il problema dell'ID di processo, ho scritto una libreria condivisa che può essere pre-caricata e che restituisce un valore specificato dall'utente per la chiamata libc getpid().
Il passo successivo è stato costruire un ambiente chroot che contenesse i binari e le librerie effettivi di un sistema vulnerabile. Ho preso un'istantanea da un sistema Ubuntu sulla rete locale. Puoi trovare l'intero ambiente chroot qui. Per generare una chiave OpenSSH con un tipo, una dimensione in bit e un ID di processo specifici, ho scritto uno script shell che può essere eseguito all'interno dell'ambiente chroot. Puoi trovare questo script shell qui. Questo script viene inserito nella directory root del filesystem Ubuntu estratto. Per generare una chiave, questo script viene chiamato con la seguente riga di comando:
# chroot ubunturoot /dokeygen.sh 1 -t dsa -b 1024 -f /tmp/dsa_1024_1
Questo genererà una nuova chiave DSA OpenSSH a 1024 bit con il valore di getpid() che restituisce sempre il numero '1'. Ora abbiamo la nostra prima chiave SSH pre-generata. Se continuiamo questo processo per tutti i PID fino a 32.767 e poi lo ripetiamo per le chiavi RSA a 2048 bit, abbiamo coperto gli intervalli di chiavi validi per sistemi x86 che eseguono la versione difettosa della libreria OpenSSL. Con questo set di chiavi, possiamo compromettere qualsiasi account utente che abbia una chiave vulnerabile elencata nel file authorized_keys. Questo set di chiavi è utile anche per decifrare una sessione SSH precedentemente catturata, se il server SSH stava usando una chiave host vulnerabile. I collegamenti ai set di chiavi pre-generati per chiavi DSA a 1024 bit e RSA a 2048 bit (x86) sono forniti nella sezione download qui sotto.
La cosa interessante di queste chiavi è come sono legate all'ID di processo. Poiché la maggior parte dei sistemi basati su Debian utilizza valori di ID di processo sequenziali (incrementando dall'avvio del sistema e ricominciando da capo secondo necessità), l'ID di processo di una determinata chiave può anche indicare quanto tempo dopo l'avvio del sistema è stata generata quella chiave. Se guardiamo l'inverso di ciò, possiamo determinare quali chiavi utilizzare durante un attacco di forza bruta in base al bersaglio che stiamo attaccando. Quando si tenta di indovinare una chiave generata all'avvio (come una chiave host SSH), quelle chiavi con valori PID inferiori a 200 sarebbero le scelte migliori per un attacco di forza bruta. Quando si attacca una chiave generata dall'utente, possiamo presumere che la maggior parte delle chiavi utente valide siano state create con un ID di processo maggiore di 500 e minore di 10.000. Questa ottimizzazione può accelerare significativamente un attacco di forza bruta su un account utente remoto tramite il protocollo SSH.
Nel prossimo futuro, questo sito verrà aggiornato per includere uno strumento di forza bruta che può essere utilizzato per ottenere rapidamente l'accesso a qualsiasi account SSH che consenta l'autenticazione tramite chiave pubblica utilizzando una chiave vulnerabile. Le chiavi nei file di dati sottostanti utilizzano la seguente convenzione di denominazione:
/ Algorithm / Bits / Fingerprint-ProcessID
and
/ Algorithm / Bits / Fingerprint-ProcessID.pub
Per ottenere il file della chiave privata per una data chiave pubblica, è necessario conoscere l'impronta digitale della chiave. Il modo più semplice per ottenere questa impronta è tramite il seguente comando:
$ 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
Se guardiamo la chiave pubblica in un editor, possiamo anche dedurre che il tipo di chiave è RSA. Per individuare la chiave privata per questa chiave pubblica, dobbiamo estrarre i file di dati e cercare un file denominato:
rsa/2048/**c67b14faaeb689e66717ee0417b0ec4e-26670**
Nell'esempio sopra, l'impronta digitale è rappresentata in esadecimale con i due punti rimossi, e l'ID di processo è indicato come '26670'. Se vogliamo autenticarci su un sistema vulnerabile che utilizza questa chiave pubblica per l'autenticazione, eseguiremmo il seguente comando:
$ ssh -i rsa/2048/c67b14faaeb689e66717ee0417b0ec4e-26670 root@targetmachine
D: Quanto tempo ci è voluto per generare queste chiavi?
R: Ho utilizzato 31 core Xeon con clock a 2.33 GHz. Ci sono volute due ore per generare le chiavi DSA a 1024 bit e RSA a 2048 bit per x86. Le chiavi RSA a 4096 bit hanno richiesto circa 6 ore per essere generate. La generazione delle chiavi RSA a 8192 bit richiederebbe circa 100 ore al ritmo attuale e probabilmente verrà interrotta prima del completamento.
D: Condividerai il tuo codice per distribuire la generazione delle chiavi su più processori?
R: No. Il codice è hardcoded per questo cluster specifico ed è troppo mal scritto per valere la pena di ripulirlo.
D: Quanto tempo ci vuole per decifrare un account utente SSH utilizzando queste chiavi?
R: Dipende dalla velocità della rete e dalla configurazione del server SSH. Dovrebbe essere possibile provare tutte le 32.767 chiavi sia DSA-1024 che RSA-2048 entro un paio d'ore, ma fai attenzione agli script anti-forza bruta sul server di destinazione.
D: Utilizzo chiavi RSA a 16384 bit, possono essere violate?
R: Sì, è solo una questione di tempo e potenza di calcolo. Il set di chiavi RSA a 8192 bit richiederebbe circa 3100 ore di CPU per generare tutte le 32.767 chiavi (100 ore sui 31 core che sto usando ora). Immagino che il set di chiavi RSA a 16384 bit richiederebbe circa 100.000 ore di CPU. Una cosa da tenere a mente è che la maggior parte delle chiavi rientra in un intervallo molto più piccolo, basato sul seed dell'ID di processo, e l'intero set non avrebbe bisogno di essere generato per coprire la maggior parte delle chiavi utente (la maggior parte delle chiavi rientra nei primi 3.000 ID di processo).
Copyright © 2008 H D Moore