Quindi, per coloro che non lo sanno, un packager Debian ha modificato il sorgente utilizzato per OpenSSL sui sistemi basati su Debian (Debian e tutta la famiglia Ubuntu) per rimuovere il seed utilizzato per PRNG (Pseudo Random Number Generator) utilizzato durante la creazione di SSL chiavi. Ebbene, HD Moore ha stabilito un nuovo record di velocità da sfruttare con il rilascio di ciò che chiama Debian-OpenSSL Toys.
HD descrive il bug nella pagina, e ho citato la sua spiegazione di seguito:
Il 13 maggio 2008 il progetto Debian annunciato che Luciano Bello ha trovato un'interessante vulnerabilità nel pacchetto OpenSSL che stavano distribuendo. Il bug in questione è stato causato dalla rimozione della seguente riga di codice da
md_rand.cMD_Update(&m, buf, j); [.. ] MD_Update(&m, buf, j); /* purify complains */Queste linee erano RIMOSSO perché hanno causato il Valgrind e strumenti Purify per produrre avvisi sull'uso di dati non inizializzati in qualsiasi codice collegato a OpenSSL. Puoi vedere uno di questi report per il team OpenSSL Qui. La rimozione di questo codice ha l'effetto collaterale di paralizzare il processo di seeding per OpenSSL PRNG. 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 processo massimo predefinito è 32.768, il che comporta l'utilizzo di un numero molto ridotto di valori seed per tutte le operazioni PRNG.
Mmmm... non ami gli strumenti di sicurezza? Questo te lo dimostra, non importa quanto sia eccezionale il tuo set di strumenti, e mi piace Valgrind, devi capire come funzionano e, soprattutto, come funziona il tuo codice. Nessuno strumento può essere abbastanza intelligente da dirti che l'avviso di cui si lamenta con dati non inizializzati dovrebbe essere ignorato (o al massimo meno corretto e non rimosso dalla base di codice) perché renderà effettivamente la crittografia che stai tentando di realizzare castrato.
L’impatto di tutto ciò è incredibilmente enorme, come menziona HD:
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 interessate. Nel caso delle chiavi SSL, tutti i certificati generati dovranno essere ricreati e inviati all'autorità di certificazione per essere firmati. Qualsiasi chiave dell'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 con chiave pubblica devono controllare tali chiavi per vedere se qualcuna di esse è stata creata su un sistema vulnerabile. Qualsiasi strumento che si affidasse 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 decrittografia del traffico e un attacco man-in-the-middle sarebbe invisibile agli utenti.
Questo difetto è grave 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.
Su I giocattoli di HD, fare clic su Leggi di più qui sotto per continuare...
Questo è preso direttamente dalla pagina di HD per risparmiare tempo e perché non sono assolutamente un tipo da criptovaluta:
I giochi
Le liste nere pubblicate da Debian e Ubuntu dimostrano quanto piccolo sia lo spazio delle chiavi. Quando si crea una nuova chiave OpenSSH, ci sono solo 32.767 possibili risultati per una determinata architettura, dimensione e tipo di chiave. Il motivo è che l'unico dato "casuale" utilizzato dal PRNG è l'ID del processo. Per generare le chiavi effettive che corrispondono a queste liste nere, abbiamo bisogno di un sistema contenente i file 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 del processo, ho scritto a libreria condivisa che potrebbe essere precaricato e che restituisce un valore specificato dall'utente per la chiamata libc getpid().Il passo successivo è stato quello di creare un ambiente chroot che contenesse i file binari e le librerie reali di un sistema vulnerabile. Ho scattato un'istantanea da un sistema Ubuntu sulla rete locale. Puoi trovare l'intero ambiente chroot Qui Per generare una chiave OpenSSH con un tipo, un conteggio di bit e un ID di processo specifici, ho scritto uno script di shell che potrebbe essere eseguito dall'interno dell'ambiente chroot. Puoi trovare questo script di shell Qui. Questo script viene inserito nella directory root del filesystem Ubuntu estratto. Per generare una chiave, questo script viene richiamato con la seguente riga di comando:
# chroot ubunturoot /dokeygen.sh 1 -t dsa -b 1024 -f /tmp/dsa_1024_1Questo 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 pregenerata. Se continuiamo questo processo per tutti i PID fino a 32.767 e poi lo ripetiamo per le chiavi RSA a 2048 bit, avremo coperto gli intervalli di chiavi validi per i sistemi x86 che eseguono la versione buggy della libreria OpenSSL. Con questo set di chiavi possiamo compromettere qualsiasi account utente che abbia una chiave vulnerabile elencata nel file chiavi_autorizzatefile. Questo set di chiavi è utile anche per decrittografare una sessione SSH precedentemente acquisita, se il server SSH utilizzava una chiave host vulnerabile. I collegamenti ai set di chiavi pregenerati per le chiavi DSA a 1024 bit e RSA a 2048 bit (x86) sono forniti nella sezione download di seguito.La cosa interessante di queste chiavi è il modo in cui sono legate all'ID del processo. Poiché la maggior parte dei sistemi basati su Debian utilizzano valori ID di processo sequenziali (incrementando dall'avvio del sistema e ripristinando in base alle necessità), l'ID del processo di una determinata chiave può anche indicare quanto tempo è trascorso dall'avvio del sistema quella chiave generato. Se guardiamo al contrario, possiamo determinare quali chiavi usare 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 la scelta migliore per una forza bruta. Quando si attacca una chiave generata dall'utente, possiamo presupporre che la maggior parte delle chiavi utente valide siano state create con un ID processo maggiore di 500 e inferiore a 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 con chiave pubblica utilizzando una chiave vulnerabile. Le chiavi nei file di dati seguenti utilizzano la seguente convenzione di denominazione:
/ Algorithm / Bits / Fingerprint-ProcessID and / Algorithm / Bits / Fingerprint-ProcessID.pubPer ottenere il file della chiave privata per una determinata chiave pubblica, è necessario conoscere l'impronta digitale della chiave. Il modo più semplice per ottenere questa impronta digitale è 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.pubSe osserviamo 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-26670Nell'esempio precedente, l'impronta digitale è rappresentata in formato esadecimale con i due punti rimossi e l'ID del processo è indicato come "26670". Se vogliamo autenticarci su un sistema vulnerabile che utilizza questa chiave pubblica per l'autenticazione, eseguiremo il seguente comando:$ ssh -i rsa/2048/c67b14faaeb689e66717ee0417b0ec4e-26670 root@targetmachine
Utensili
- Libreria condivisa GetPID Faker (4.0K) - File system radice di Ubuntu (4,9 M) - Script di generazione delle chiavi (8,0 KB)Chiavi
- Chiavi DSA SSH a 1024 bit X86 (30,0 milioni) - Chiavi RSA SSH a 2048 bit X86 (48,0 milioni) - Chiavi RSA SSH a 4096 bit X86 (94,0 milioni)Domande frequenti
Q: Quanto tempo è stato necessario per generare queste chiavi? UN: circa due ore per le chiavi DSA a 1024 bit e RSA a 2048 bit per x86. Ho utilizzato 31 core Xeon con clock a 2,33 Ghz.Q: Condividerai il tuo codice per distribuire la generazione di chiavi su più processori? UN: No. Il codice è hardcoded per questo cluster specifico ed è scritto in modo troppo scadente perché valga la pena ripulirlo.
Q: Quanto tempo occorre per crackare un account utente SSH utilizzando queste chiavi? UN: Dipende dalla velocità della rete e dalla configurazione del server SSH. Dovrebbe essere possibile provare tutte le 32.767 chiavi di DSA-1024 e RSA-2048 entro un paio d'ore, ma fai attenzione agli script anti-forza bruta sul server di destinazione.
Q: Utilizzo chiavi RSA a 16384 bit, possono essere danneggiate? UN: Sì, è solo questione di tempo e potenza di elaborazione. Per i comuni mortali, le chiavi a 4096 bit sono già un po’ paranoiche. Tutte le possibili chiavi a 4096 bit dovrebbero essere disponibili entro il giorno successivo. È possibile generare tutte le combinazioni di chiavi a 8192 bit e 16384 bit, ma probabilmente ho usi migliori per i miei processori :-)
Tutto quello che posso dire è incredibile. Grave difetto, sì, ma i tempi di risposta dell'HD sono ridicoli... Penso che stia cercando di farsi nominare per un premio Pwnie. HD, però è un imbroglio se sei nel pannello di votazione!
-Nate.