Qualche strumento MITM per forzare una suite di crittografia SSL debole?

9

Diciamo che sto cercando di invertire le comunicazioni di ingegneria tra un'app Android e un server Web che utilizza HTTPS.

All'inizio, ho provato a fare MITM usando webmitm e un falso certificato. Ma l'app non è stata avviata perché il falso cert utilizzato da webmitm non è considerato attendibile dall'app. (Supponiamo che l'app abbia il proprio modo di decidere quale certezza si fida e non posso importare il falso certificato su Android come certificato attendibile)

Quindi vengo ad un altro approccio. Ho notato che sia l'app che il server Web supportano cifre deboli (ad esempio TLS_RSA_EXPORT_WITH_RC4_40_MD5). Quindi sto pensando, invece di usare un falso cert come bridge, c'è uno strumento mitm che modifica solo il pacchetto Client Hello per applicare cifrari deboli e inoltra il cert originale del server senza decrittografia o crittografando qualcosa nel mezzo.

In un'altra parola, quando l'app invia "Hello Webserver, supporto le seguenti suite di crittografia: XXX YYY ZZZ. Scegli un supporto", lo strumento mitm intercetta questo pacchetto e lo modifica in "Hello Webserver, I only supportare TLS_RSA_EXPORT_WITH_RC4_40_MD5 "e inoltrarlo al server web. Dato che entrambi sostengono questa suite di crittografia, la useranno per il resto della comunicazione. E lo strumento mitm inoltra tutto tra loro e registra tutti i pacchetti. E poi provo a decodificare i pacchetti registrati offline.

Qualche idea?

    
posta user15580 13.01.2014 - 21:12
fonte

1 risposta

13

Quello che stai cercando di fare sarà ... difficile. Il punto principale è che alla fine della stretta di mano, client e server si scambiano messaggi di Finished , sotto la protezione degli algoritmi e delle chiavi appena negoziate; e i contenuti di questi messaggi sono valori hash calcolati su tutti i precedenti messaggi di handshake, inclusi ClientHello e ServerHello . Ciò che equivale a è che se il client e il server non vedono lo stesso ClientHello (perché lo hai modificato in transito), il contenuto del messaggio Finished non corrisponderà e l'handshake avrà esito negativo.

Per modificare correttamente ClientHello , devi interrompere la crittografia subito e non offline: devi recuperare le chiavi di crittografia alla fine dell'handshake e prima di inoltrare i messaggi di Finished , in modo da poter regolare i contenuti.

La crittografia a 40 bit rientra nel campo della tecnologicamente fattibile. Un primo problema è che con la suite cipher di esportazione, la chiave a 40 bit è solo una chiave intermedia; la chiave finale è espansa a 128 bit. La forza bruta è ancora fattibile, ma le tabelle precomputate (tabelle arcobaleno ...) non lo sono. Un problema più grande è che, dal momento che devi regolare il contenuto dei messaggi Finished , non devi solo rompere le chiavi di crittografia, ma anche i tasti MAC - e questi sono grandi (128 bit).

L'unica opzione rimanente, quindi, consiste nel suddividere la chiave RSA utilizzata dal server. Teoricamente, con TLS_RSA_EXPORT_WITH_RC4_40_MD5 , la chiave pubblica del server dovrebbe avere al massimo una dimensione di 512 bit. Una chiave RSA a 512 bit è irrintracciabile, ma è ancora abbastanza per un dilettante. È è stato segnalato che un singolo PC desktop può raggiungerlo in due mesi; più recentemente, un ragazzo ha preso in considerazione una chiave RSA a 512 bit per 75 dollari in tre giorni (75 dollari di CPU noleggiata). Se provi una connessione al server con un client (ad esempio lo strumento da riga di comando di OpenSSL: openssl s_client ) che afferma di supportare solo TLS_RSA_EXPORT_WITH_RC4_40_MD5 , vedrai il certificato inviato dal server. Se la chiave pubblica del server è solo a 512 bit, allora puoi immaginare di romperla. Si noti, tuttavia, che è del tutto possibile che il server non rispetti le restrizioni alle chiavi a 512 bit per "codici di esportazione" (dal momento che le suddette norme sull'esportazione sono state revocate più di dieci anni fa).

Se riesci a rompere la chiave RSA del server, puoi impersonare il server, ad esempio utilizzare il certificato del server (necessariamente valido agli occhi del cliente) per il tuo attacco Man-in-the-Middle. Se non puoi, e non c'è modo per te di costruire un certificato falso che il cliente accetterà, quindi non vedo alcun modo per ottenere ciò che vuoi fare.

    
risposta data 13.01.2014 - 21:44
fonte

Leggi altre domande sui tag