Attacchi padding oracle nel dettaglio

In modalità CBC (Cipher Block Chaining), la decifratura di ogni blocco consiste nel decifrare il blocco di testo cifrato con il cifrario a blocchi e poi nell'eseguire uno XOR del risultato con il blocco di testo cifrato precedente. Questa operazione XOR introduce una proprietà critica: modificando i bit di un blocco di testo cifrato, un attaccante può influenzare in modo prevedibile bit specifici del testo in chiaro decifrato del blocco successivo. Questa proprietà rende possibile l'attacco padding oracle.

I cifrari a blocchi richiedono input suddivisi in blocchi di dimensione fissa. Il padding PKCS#7 completa l'ultimo blocco: se sono necessari 3 byte di padding, vengono aggiunti tre byte, ciascuno con valore 0x03. Se il blocco è già completo, viene aggiunto un intero blocco di padding in cui tutti i 16 byte hanno valore 0x10. Durante la decifratura, i byte di padding vengono verificati per accertare che siano coerenti (tutti gli N byte hanno valore N) e poi rimossi. Se il padding non è valido, la decifratura dovrebbe fallire.

Un padding oracle è qualsiasi sistema che rivela se un testo cifrato decifrato contiene un padding PKCS#7 valido. L'oracolo può essere un messaggio di errore esplicito (padding non valido), un codice di stato HTTP diverso (500 invece di 403), un corpo della risposta di errore diverso o persino una differenza nei tempi di risposta (la decifratura con padding valido è leggermente più veloce). All'attaccante non serve conoscere la chiave: gli basta questo segnale binario, cioè padding valido o non valido.

L'attaccante prende di mira uno specifico blocco di testo cifrato. Per recuperare l'ultimo byte del testo in chiaro, modifica l'ultimo byte del blocco di testo cifrato precedente e invia il testo cifrato modificato all'oracolo. Prova in sequenza 256 valori possibili finché l'oracolo segnala un padding valido. Per il valore che produce un padding valido (0x01), il valore intermedio della decifratura è noto: sottoposto a XOR con il byte modificato, produce 0x01. Eseguendo lo XOR con il byte originale del testo cifrato si rivela il byte del testo in chiaro.

Una volta recuperato l'ultimo byte, si prende di mira il penultimo. Il valore intermedio dell'ultimo byte è già noto, quindi il byte precedente può essere modificato in modo da forzare il risultato a 0x02. Si provano quindi 256 valori per il penultimo byte finché il padding 0x02 0x02 non risulta valido. Il processo si ripete per ogni byte, recuperando un blocco completo di 16 byte con 256 * 16 = 4.096 query all'oracolo in media per blocco. Con un oracolo rapido, l'operazione può essere completata in pochi secondi.

Il processo viene ripetuto per ogni blocco di testo cifrato (eccetto l'IV, che non può essere recuperato senza il blocco precedente). Un testo cifrato di 128 byte (8 blocchi AES) richiede in media circa 32.000 interrogazioni dell'oracolo per essere decifrato completamente. Su un server web che gestisce centinaia di richieste al secondo, l'operazione richiede pochi minuti. L'attaccante recupera l'intero testo in chiaro senza mai conoscere la chiave di cifratura.

POODLE (Padding Oracle On Downgraded Legacy Encryption) sfruttava la convalida del padding CBC di SSL 3.0. SSL 3.0 utilizzava uno schema di padding diverso da PKCS#7, ma l'attacco adattava il concetto di oracolo. Un attaccante in grado di iniettare contenuti in una sessione SSL 3.0 e di forzare i client a eseguire il downgrade a SSL 3.0 poteva recuperare i cookie di sessione usando la tecnica dell'oracolo di padding. POODLE ha portato alla dismissione di SSL 3.0.

Lucky Thirteen (2013) sfruttava un canale laterale basato sui tempi nello schema MAC-then-encrypt del CBC di TLS. Il tempo di verifica del MAC differiva di alcuni nanosecondi a seconda della validità del padding, creando un oracolo temporale. BEAST (2011) sfruttava l'IV prevedibile della modalità CBC di TLS 1.0 per eseguire un attacco a testo in chiaro scelto contro i cookie di sessione. Entrambi gli attacchi hanno dimostrato che la modalità CBC in TLS era fondamentalmente difficile da implementare correttamente.

La difesa definitiva contro gli attacchi con oracolo di padding consiste nell'usare modalità AEAD (Authenticated Encryption with Associated Data) invece di CBC. Le modalità AEAD come AES-256-GCM e ChaCha20-Poly1305 verificano l'autenticazione prima che avvenga qualsiasi decifratura o controllo del padding. Se il tag di autenticazione non è valido, la decifratura non viene mai eseguita e non viene divulgata alcuna informazione sul padding. TLS 1.3 impone AEAD e rimuove completamente CBC.

Se AEAD non è disponibile, la costruzione Encrypt-then-MAC aggiunge un MAC al testo cifrato (non al testo in chiaro). Il MAC viene verificato prima della decifratura o del controllo del padding. Se il MAC non è valido, l'operazione viene interrotta immediatamente senza rivelare alcuna informazione sul padding. Questa verifica deve essere eseguita in tempo costante per impedire gli oracoli temporali. Il fallimento della verifica del MAC non rivela nulla sull'eventuale validità del padding.

Per verificare la presenza di vulnerabilità da oracolo di padding: cifrate un messaggio noto, quindi inviate all'applicazione un testo cifrato modificato e osservatene la risposta. Se il padding valido e quello non valido producono risposte osservabilmente diverse (messaggio di errore, codice di stato o tempo di risposta), esiste un oracolo di padding. Strumenti automatizzati come padbuster e PadBuster verificano specificamente la presenza di oracoli di padding nelle applicazioni web, modificando sistematicamente i testi cifrati e analizzando le risposte.

Che cosa deve fornire il sistema di destinazione affinché un attacco con oracolo di padding possa decifrare il testo cifrato senza la chiave?

Riepilogo dell'oracolo di padding: la proprietà XOR della decifratura CBC consente di manipolare il testo in chiaro in modo controllato; la convalida del padding PKCS#7 rivela un oracolo binario; l'attaccante prova iterativamente i valori dei byte e osserva le risposte valide o non valide per recuperare il testo in chiaro un byte alla volta; gli exploit reali includono POODLE, Lucky Thirteen e BEAST; la difesa consiste nel passare ad AEAD (GCM, ChaCha20-Poly1305), che verifica l'autenticazione prima della decifratura.