Pagina 1 di 1
Applicare contromisure per attacco BREACH su TurboLab.it
Inviato: mer ago 27, 2014 6:53 pm
da hashcat
Questo post è un appunto mnemonico che descrive due modalità di mitigazione dell'exploit BREACH utilizzando il file .htaccess di Apache.
1° // Da testare, potenzialmente inefficace per via del mod_pagespeed
Codice: Seleziona tutto
SetOutputFilter DEFLATE
SetEnvIfNoCase Referer .* self_referer=no
SetEnvIfNoCase Referer ^https://turbolab\.it self_referer=yes
SetEnvIfNoCase Referer ^https://bug\.turbolab\.it self_referer=yes
SetEnvIf self_referer ^no$ no-gzip
Header append Vary User-Agent env=!dont-vary
Codice: Seleziona tutto
SetEnvIfNoCase Referer ^https://turbolab\.it keep_cookies
SetEnvIfNoCase Referer ^https://bug\.turbolab\.it keep_cookies
RequestHeader unset Cookie env=!keep_cookies
P.S.: Ho posizionato il messaggio in questa discussione solo in via provvisoria, lo sposterò appena ultimato.
Re: Aggiornamento configurazione mod_ssl
Inviato: dom ott 12, 2014 7:50 pm
da hashcat
Ho rivisto le due possibili configurazioni indicate nel precedente messaggio e confermo che dovrebbero essere ultimate. Se la 1° funziona senza interferire con il mod_pagespeed converrebbe provare ad adottarla.
Re: Aggiornamento configurazione mod_ssl
Inviato: dom ott 12, 2014 10:58 pm
da Zane
Apri bug per favore.
Re: Aggiornamento configurazione mod_ssl
Inviato: lun ott 13, 2014 8:02 pm
da hashcat
Zane ha scritto:Apri bug per favore.
#139 (Bug)
Re: Aggiornamento configurazione mod_ssl
Inviato: dom gen 04, 2015 3:32 am
da Zane
Finalmente ho avuto il tempo necessario per informarmi per bene e valutare BREACH più nel dettaglio (letture principali: presentazione originale, Qualys, Ars Technica, InfoSec).
Sono stato abbastanza dubbioso se introdurre la contromisura o meno: lanciare un attacco BREACH non è per nulla banale (bisogna preparare un sito-trappola e convincere la vittima a visitarlo) e non è sfruttabile via Internet, ma solo da qualcuno nella stessa LAN o Wi-Fi della vittima che sia in grado di catturare il traffico HTTPS in transito.
Ciò premesso, ho comunque deciso di introdurre la contromisura. L'effetto collaterale è che da domani pomeriggio (05/01/2015) in avanti, il nostro server disattiva la compressione HTTP della pagina se il browser dell'utente non indica che la l'URL dal quale proviene è interna a TurboLab.it (HTTP referer).
Questo si verifica quando il visitatore apre TurboLab.it:
- partendo dal Preferito che si era salvato nel browser
- seguendo un link su un altro sito che non sia in questo elenco: google.com, google.it, mail.google.com, facebook.com, m.facebook.com, feedly.com, bing.com
- scrivendo direttamente il nostro URL nella barra degli indirizzi del browser
- utilizzando un PC sul quale è installata una suite di sicurezza che blocca HTTP referer a prescindere (spero non ne esistano più in circolazione, ma non ne sono sicuro)
La misura è attiva su TurboLab.it ma non su cdn.phporn.net, dato che lì non viene gestito input-utente e quindi è immune a priori.
@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
Re: Aggiornamento configurazione mod_ssl
Inviato: dom gen 04, 2015 11:21 am
da hashcat
Zane ha scritto:Ciò premesso, ho comunque deciso di introdurre la contromisura. L'effetto collaterale è che da domani pomeriggio (05/01/2015) in avanti, il nostro server
disattiva la compressione HTTP della pagina se il browser dell'utente non indica che la l'URL dal quale proviene è interna a TurboLab.it (
HTTP referer).
La prima delle due possibili mitigazioni che ho proposto precedentemente opera proprio sulla compressione HTTP in base al referer; la seconda invece, sempre in base al referer, evita di trasmettere i cookie (che possono consentire l'accesso ad una sessione autenticata).
Nel primo caso, dopo aver visitato almeno un link all'interno di TurboLab.it (compreso bug), la situazione ritorna normale (compressione abilitata). Questa mitigazione non impatta realmente l'utente ma piuttosto il carico del server (in termini di banda utilizzata). In realtà il carico non dovrebbe incrementare in maniera sensibile.
Nel secondo caso, l'utente con referer esterno a TLI, anche se precedentemente autenticato, risulterà come visitatore rispetto alla prima visita, dopo aver visitato almeno un link all'interno di TurboLab.it (compreso bug), la situazione dovrebbe tornare normale (trasmissione dei cookie abilitata). Questa misura provoca un piccolo disagio all'utente ma, in termini di prestazioni e complessità è forse la migliore.
Zane ha scritto:@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
OK. Speriamo che questa modifica non si scontri con il mod_pagespeed vanificandone l'efficacia.
Re: Aggiornamento configurazione mod_ssl
Inviato: dom gen 04, 2015 11:57 am
da hashcat
Ora che ci penso phpBB permette di autenticarsi e gestire sessioni anche in assenza dei cookie (utilizza dei parametri nell'url) quindi è possibile che l'unica soluzione che garantisca un livello di sicurezza consistente è rappresentato dalla prima mitigazione.
Re: Aggiornamento configurazione mod_ssl
Inviato: dom gen 04, 2015 12:11 pm
da Zane
La soluzione scarta-cookie non è applicabile: considerate le circostanze necessarie per sfruttare la vulnerabilità, reputo che non valga la pena sacrificare l'auto-login e tante altre cosine che dipendono dai cookie per gestirlo. Inoltre, se ricordo correttamente (sono effettivamente alcuni anni che non ci guardo), l'accesso senza cookie a phpBB usa un session-ID via querystring che non fa altro che sostituire un punto d'attacco con un altro... ma, soprattutto, è una schifezza che non voglio nell'URL.
La soluzione disattiva-compressione è completamente efficace e la penalizzazione ragionevole: questo il motivo per cui ho preferito quella.
Re: Aggiornamento configurazione mod_ssl
Inviato: dom gen 04, 2015 7:15 pm
da hashcat
Zane ha scritto:Inoltre, se ricordo correttamente (sono effettivamente alcuni anni che non ci guardo), l'accesso senza cookie a phpBB usa un session-ID via querystring che non fa altro che sostituire un punto d'attacco con un altro... ma, soprattutto, è una schifezza che non voglio nell'URL.
Ho espresso una simile perplessità nel mio precedente messaggio.
Zane ha scritto:La soluzione disattiva-compressione è completamente efficace e la penalizzazione ragionevole: questo il motivo per cui ho preferito quella.
La penso allo stesso modo.
Re: Aggiornamento configurazione mod_ssl
Inviato: mar gen 06, 2015 11:15 am
da hashcat
Zane ha scritto:@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
Ho appena verificato e sembra funzionare ma... sbaglio o hai inserito nella whitelist anche alcuni host esterni a TLI (ad esempio Google, Bing): è il comportamento desiderato (o si tratta di un bug) ?
Re: Applicare contromisure per attacco BREACH su TurboLab.it
Inviato: mar gen 06, 2015 11:56 am
da Zane
sì vedi sopra per la lista
Re: Applicare contromisure per attacco BREACH su TurboLab.it
Inviato: mar gen 06, 2015 5:35 pm
da hashcat
Zane ha scritto:sì vedi sopra per la lista
Me ne ero totalmente dimenticato.
