Come sconfiggere CRIME, BREACH, TIME ecc. lato server (senza sacrificare la compressione)

Question

Come sconfiggere CRIME, BREACH, TIME ecc. lato server (senza sacrificare la compressione)

#1 da (5 voti)
#2 da (0 voti)

5

Sto scrivendo un software server side-stack completo e sto conducendo ricerche sugli attacchi CRIME e sulla relazione con la compressione dell'intestazione SPDY mentre sto implementando i codec lato server per il momento.

La conclusione sembra essere che la compressione e la crittografia non dovrebbero mescolarsi.

Dopo aver esaminato sia CRIME che BREAK. Mi chiedo se i seguenti metodi siano validi per disabilitare TUTTI i tipi di attacchi "congettura lavoro" in flussi di dati compressi e crittografati (sul lato server)

1) Limitazione della velocità - come suggerito sul sito di BREACH. Qualsiasi client che bombardi un server con oltre 100 richieste al secondo è destinato a essere malintenzionato quando le pagine dei tuoi siti servono solo un massimo di risorse X (singola / bassa doppia cifra) per richiesta.

2) Dati dinamici: sia CRIME che BREACH (e le loro derivate) sembrano fare affidamento su ripetuti sondaggi e presuppongono che la posizione dei dati non cambi. Cosa succede se sia le intestazioni HTTP che il corpo vengono mescolati per risposta dal server? Combinato con dati fittizi casuali di piccola lunghezza variabile iniettati sia nel corpo sia nell'intestazione? Questo può efficacemente disabilitare tutti questi attacchi con le caratteristiche di CRIME e BREACH?

Grazie per il tuo tempo.

EDIT 1: vorrei sottolineare che mi riferisco specificamente ai flussi di dati all'interno del protocollo HTTP (cioè compressione HTTP e compressione dell'intestazione SPDY) e non alla compressione SSL / TLS.

EDIT 2: La soluzione di mitigazione degli attacchi che sto cercando di ottenere / suggerire è su tutti i possibili attacchi di perdita di informazioni "compression + encryption", CRIME e BREACH possono essere solo esempi recenti.

MODIFICA 3: la presentazione BREACH sembra suggerire una lunghezza variabile il padding non è una valida attenuazione. Tuttavia non sembra considerare la combinazione di una struttura di messaggio randomizzata + padding randomizzato in grado di creare una combinazione infinita di output inaffidabili ( in teoria ) rimuovendo quindi qualsiasi correlazione tra la lunghezza di output compresso e crittografato significato del messaggio effettivo.

http encryption compression

posta 03.10.2013 - 13:08

fonte

2 risposte

Leggi altre domande sui tag http encryption compression

Il recupero del certificato client utilizzando Tcpdump produce un certificato di lunghezza zero Quali sono i pro e i contro dell'uso di yubikey con la crittografia hardware SSD?

score 5 · Answer 1

CRIME e BREACH sono attacchi sul client . La loro configurazione è che nel client è in esecuzione un codice ostile con funzionalità limitate (ad esempio, è Javascript in una pagina Web). L'attaccante controlla anche il traffico esterno della vittima: può ispezionarlo, ma anche bloccarlo. Ciò limita ciò che il server effettivamente vede.

In entrambi i casi, il Javascript ostile attiverà diverse (molte) richieste indirizzate al server per il quale il segreto (il valore del cookie) deve essere recuperato. L'attaccante deve solo vedere cosa esce dal client; non è assolutamente necessario che la richiesta raggiunga il server. Infatti, i client HTTPS usano HTTP : inviano regolarmente più richieste di fila su un singolo canale e non importa che non ricevano una risposta immediatamente. In questo modo, il codice ostile fa sì che il browser della vittima invii molte richieste che gli hacker vedono, ma non il server.

In queste condizioni, c'è pochissimo che il server può fare per proteggere il client, eccetto per non lasciare credere che le caratteristiche del protocollo vulnerabile (CBC non protetto, compressione ...) possano essere usate del tutto. In questo caso le limitazioni di frequenza non faranno molto.

Iniettare un riempimento casuale è una possibile difesa, ma deve essere fatto nel client, non nel server. Anche in questo caso, il server non può fare nulla. Un'intestazione personalizzata, con contenuti casuali e che si verificano prima del cookie nell'intestazione, impedirebbe BREAK. Per CRIME, questo è più complesso; hai bisogno di un'intestazione personalizzata con una lunghezza casuale con una distribuzione ben scelta (non è immediatamente evidente quale distribuzione dovrebbe essere utilizzata). Ovviamente, questo padding aggiuntivo implica più byte da inviare, il che può benissimo annullare i vantaggi dell'utilizzo della compressione in primo luogo.

score 0 · Answer 2

@ Tom, è un attacco a TLS, quindi coinvolge sia il client che il server. Parte dell'exploit viene eseguita sul client, ma l'attacco è sugli organismi di risposta del server con BREACH. Le intestazioni non sono compresse con la compressione HTTP. Penso che tu abbia confuso BREACH e CRIME nel tuo quarto paragrafo.

1) La limitazione della velocità rallenterà l'attacco, ma non lo fermerà. Questo tipo di rilevamento bloccherà una buona quantità di attacchi, ma credo sia stato difficile da implementare.

2) Anche se il tuo padding è completamente casuale, o la distribuzione è sfalsata, puoi comunque prendere un certo numero di richieste e fare una media per ottenere un risultato. Questo rende l'attacco più costoso ma non impossibile.

Non farei nessuno di questi, a meno che tu non stia bene con la mitigazione, non con la riparazione.

Perché non basta mettere un token CSRF casuale su ogni richiesta e costruire il framework intorno a questo, quindi un utente malintenzionato non sa mai quale sia l'aspetto di una richiesta valida in modo che non possano forzarti a farlo?