Qualsiasi browser non totalmente insicuro vulnerabile a BEAST?

6

Le persone si preoccupano ancora molto di BEAST quando configurano i server Web al punto di preferire RC4 su AES-CBC. Ma la maggior parte dei browser mitiga BEAST anche durante l'utilizzo di TLS 1.0.

C'è un browser che:

  1. È vulnerabile a BEAST o a Lucky Tredici
  2. Non ha vulnerabilità note che sono molto peggiori, come l'esecuzione di codice in modalità remota
  3. Ha una base di utenti non trascurabile

BEAST è ancora un motivo per evitare CBC? Che mi dici di Lucky Thirteen?

    
posta CodesInChaos 10.09.2013 - 18:42
fonte

1 risposta

3

Va notato che BEAST richiede un codice ostile che viene eseguito sul browser della vittima, codice che è in grado di inviare richieste arbitrarie al sito Web di destinazione, con un "controllo" sufficiente sui byte inviati per estrarre la CBC correlata calcoli. In particolare, questo non può essere "solo testo". Gli autori di BEAST hanno per trovare una sorta di canale che eluda la Politica Same-Origin . Ne hanno trovati due:

  • uno in Java, che è stato corretto poco dopo (e i plugin Java non fissati hanno altri fori più grandi);
  • uno in una bozza di versione di WebSocket , che non è mai stato diffuso (in fase di bozza) ed è stato corretto; in realtà, era già stato riparato quando è stato pubblicato l'attacco, sebbene la correzione fosse fortuita (si trattava di un cambiamento pensato per proteggere da qualcos'altro).

Probabilmente, BEAST non può essere sfruttato oggigiorno a meno che non venga trovato un altro buco SOP. Inoltre, anche se tale buco SOP viene trovato, i browser correnti allo 1 / n-1 split che anche impedisce a BEAST di essere applicabile. Questo metodo è stato applicato nei principali browser Web più di un anno fa (vedi questo ) e non credo che nell'ultimo anno non sia stato riscontrato alcun errore di esecuzione remota in questi browser. Ciò significherebbe che, in effetti, non c'è motivo di preoccuparsi più di BEAST . Passare a TLS 1.2 sarebbe comunque buono.

L'attacco Lucky Thirteen non è, probabilmente, un attacco a browser ma sul server . Richiede che il browser invii molte richieste al server (in una configurazione simile a BEAST), ma la perdita proviene dal server: il server elabora un record in entrata e la verifica MAC fallirà, ma qualche misura temporanea sottile potrebbe rivelare se il riempimento del PKCS # 5 fosse corretto o meno. È rivendicato che quasi tutti i fornitori (almeno quelli open source) hanno risolto il loro codice evitare la perdita di cui Lucky Thirteen fa affidamento.

Il marchio e la versione del browser Web hanno poca rilevanza per Lucky Thirteen. In teoria , si potrebbe invertire l'impostazione e attaccare l'elaborazione dei record inviati dal server al client, ma richiederebbe che l'autore dell'attacco disponga di un controllo sufficiente sulle risposte del server per fai in modo che l'attacco funzioni, e sembra abbastanza difficile.

    
risposta data 10.09.2013 - 19:13
fonte

Leggi altre domande sui tag