API POODLE e REST

Il barboncino è, come presentato, un attacco a testo normale prescelto , anche se non di molto.

Alla base, la vulnerabilità su cui si basa Poodle consente a un utente malintenzionato attivo di provare a indovinare un singolo byte di dati in chiaro. Le condizioni sono le seguenti:

• Lo stream utilizza SSL 3.0 con crittografia eseguita con un codice a blocchi in modalità CBC.
• Il valore di byte a cui l'utente malintenzionato è interessato fa parte dello stream e si verifica alla fine di un blocco (i blocchi hanno una lunghezza di 8 byte con 3DES o RC2, 16 byte con AES).
• Un record successivo nello stream (nella stessa direzione) ha una lunghezza che implica un riempimento completo.
• L'ipotesi ha probabilità 1/256 di funzionare. In caso di errore, il flusso SSL è rotto e sia il client che il server lo sanno.

Quindi, in pratica, la situazione deve essere tale che l'attaccante possa attivare silenziosamente le connessioni SSL e sistemare le cose in modo che un "segreto interessante" venga inviato attraverso la connessione in un luogo prevedibile, e l'attaccante deve anche essere in grado di modificare la dimensione dei dati inviati in modo che ogni "byte interessante" si verifichi alla fine di un blocco e si verifichi anche un record con riempimento completo. Vale la pena notare che l'attaccante deve scegliere la lunghezza di alcuni elementi del messaggio, ma non ha bisogno di controllarne il contenuto (questo è il motivo per cui è un CPA honoris causa ). Inoltre, ogni connessione interrotta non deve attivare avvisi troppo visibili.

Un browser Web che esegue Javascript ostile e connesso a Internet tramite punti di accesso WiFi controllati dagli aggressori soddisfa tutte queste condizioni. Le probabilità sono che l'applicazione non-browser non lo fa.

Tuttavia, dovresti usare veramente TLS 1.0 (o, meglio ancora, TLS 1.1 o 1.2). Ora il lato positivo è che l'handshake SSL / TLS è protetto dagli attacchi di downgrade del protocollo: se client e server seguono gli standard , quindi gli attaccanti non possono forzare un client e un server che sanno TLS 1.0 a fallback su SSL 3.0. Sfortunatamente i browser Web si sono insinuati nell'abitudine spiacevole di aggirare gli standard proprio per utilizzare SSL 3.0 in caso di errore con TLS 1.0. A tale riguardo, i browser sono deboli a Barboncino perché insistono sull'essere deboli; favoriscono il supporto continuo di una manciata di server antichi che non sono stati aggiornati dal secolo scorso, semplicemente impedendo all'utente di essere hackerato al di là di ogni riconoscimento.

Il vero problema, tuttavia, è che client e server accettano ancora di usare SSL 3.0 anche se entrambi sanno che è debole. Maggiori informazioni su questo argomento qui . Disabilitare il supporto SSL 3.0 e concentrarsi su TLS 1.0 (che già usi in pratica) non è qualcosa che dovresti fare a causa di Poodle; è qualcosa che dovresti fare perché è giunto il momento di passare dagli strumenti di pietra al metallo. Abbraccia l'età del bronzo prima che sia troppo tardi!

POODLE è l'ultimo chiodo nella bara di SSLv3. Questo problema è un difetto di progettazione e non un bug di implementazione, come lo era Heartbleed. Poiché si tratta di un difetto di progettazione, è fondamentalmente un protocollo morto, non sarà mai "corretto". Passare a TLS è l'unica opzione per non essere vulnerabili a POODLE.

Quindi sì, la tua applicazione non-browser è vulnerabile anche a POODLE. Tuttavia, un utente malintenzionato deve trovarsi nella stessa rete dell'applicazione o del client per eseguire l'attacco MiTM richiesto e deve essere in grado di attivare molte richieste dal client al server per poter effettivamente sfruttare la vulnerabilità di POODLE. A seconda della situazione esatta che può o non può rendere molto improbabile lo sfruttamento.

Detto ciò, è ora di passare da SSLv3: pianifica di disabilitarlo e passare a TLSv1.2.