CVE-2013-2566 è un attacco pratico contro RC4 o ancora concettuale?

Come Matthew Green lo mette , l'attacco "è solo al limite della fattibilità". Concettualmente si applica a qualsiasi protocollo che utilizza RC4, sebbene alcuni siano più vulnerabili di altri.

La debolezza di RC4 è un pregiudizio nei primi byte di output. Dalla chiave, RC4 genera un lungo flusso di byte pseudocasuali e la crittografia è solo un XOR byte per byte dei dati da crittografare con quel flusso. Pertanto, quando gli stessi dati vengono crittografati più volte (con una chiave distinta ogni volta), il bias nell'output RC4 si traduce in un recupero dei dati segreti. Ad esempio, supponiamo che il 17 ° byte di output abbia valore 0x42 più spesso dei 255 altri possibili valori di byte (un numero illustrativo fittizio). Poiché lo stesso messaggio viene ripetutamente crittografato, il suo 17esimo byte (chiamiamolo x ) sarà XORed con il 17 ° byte dell'uscita RC4. L'attaccante, osservando tutti i messaggi crittografati, potrebbe notare che il 17 ° byte di output è, per esempio, più spesso 0x7C di qualsiasi altro valore. L'utente malintenzionato dedurrà quindi che il valore osservato 0x7C corrisponde ai casi in cui il 17 ° byte dell'uscita RC4 è 0x42. Quindi concluderà che x XOR 0x42 = 0x7C, cioè che x = 0x3E. L'autore dell'attacco ha appena recuperato un byte di testo in chiaro.

Il punto importante è che solo i primi byte dell'output di RC4 hanno bias che possono essere sfruttati in un tempo "ragionevole". I pregiudizi sono ancora lievi; ci vogliono milioni di crittografie osservate, tutte con gli stessi dati segreti, per osservare in modo affidabile tali pregiudizi.

In una configurazione Web (con HTTPS), l'attacco sarebbe simile a questo:

• Il browser della vittima conosce un cookie che sblocca una sessione su un sito (chiamiamola www.example.com . L'utente malintenzionato vuole quel cookie.
• L'utente malintenzionato controlla il contesto di rete della vittima. Realisticamente, l'attaccante gestisce un punto di accesso WiFi in un luogo pubblico e la vittima si è connessa ad esso, ritenendo che l'AP debba essere fornito dal ristorante o dalla biblioteca che ha deciso di trascorrere qualche ora.
• L'utente malintenzionato inietta alcuni Javascript ostili nella risposta a una richiesta HTTP (non HTTPS) dal browser a un sito (non www.example.com ). Che Javascript attiverà ripetutamente una chiamata HTTP GET a https://www.example.com , ad es. creando un tag <img> nascosto nella pagina Web.
• Ogni chiamata innescata dal male Javascript implica una connessione SSL / TLS, con il cookie in esso, in un luogo prevedibile. L'utente malintenzionato inietta inoltre nella connessione un pacchetto RST subito dopo la chiamata, per forzare una connessione chiusa e quindi una nuova connessione con un nuovo handshake e una nuova chiave RC4 ogni volta.

Realisticamente, l'attaccante non può davvero sperare più di, diciamo, dieci connessioni al secondo o giù di lì, quindi un milione di chiamate richiederà più di un giorno intero e una notte. Inoltre, tutte queste connessioni raggiungono il sito di destinazione ( www.example.com ), che potrebbe generare alcuni avvisi. Se l'attaccante può proseguire l'attacco a tutta velocità per 30 ore circa, allora sarà in grado di indovinare uno o alcuni byte di cookie (i byte che appaiono nel flusso in una posizione in cui i bias RC4 sono più importanti). / p>

La conclusione è che l'attacco è, in effetti, al limite della fattibilità: può essere dimostrato in condizioni di laboratorio, ma non è stato individuato in natura. Eppure.

Per WPA / TKIP, gli stessi principi possono essere applicati, ma è più pratico perché in quel protocollo, ogni singolo pacchetto ha il proprio stream RC4, avviato di nuovo con una chiave specifica del pacchetto. La raccolta di un milione di pacchetti è sicuramente più semplice che osservare un milione di connessioni TCP con un handshake TLS . Tuttavia, la debolezza non è in alcun modo limitata a quel singolo protocollo; è consustanziale a RC4 e lo seguirà in qualsiasi protocollo che usi RC4.

Potrebbe essere indicato che quando SSH usa RC4, di solito lo fa con il nome "arcfour128" o "arcfour256"; in entrambi i casi, questo è RC4, ma con i primi 1536 byte di output abbandonati. Questi sono byte con i maggiori pregiudizi. Quindi, queste varianti di RC4 sono molto più forti del semplice RC4 (noto come "arcfour" nella terminologia SSH).

Per i nuovi progetti di protocollo, non usare RC4. Se hai davvero bisogno di andare oltre un "normale" AES / GCM, considera i flussi di codice dal portfolio di eSTREAM : sono entrambi più sicuri e veloci di RC4. Ma ricorda che il design del protocollo è difficile .