Bypassing HTTP to HTTPS memorizzato nella cache 301 reindirizza per utilizzare SSLstrip

26

Sto facendo una penna. prova su un server HTTPS (443) su cui non è implementata l'HSTS (nessun header HSTS sulla risposta e l'indirizzo non è presente nell'elenco precaricato di Chrome HSTS).

Il problema è che nel mio scenario l'utente ha visitato il sito web in precedenza, quindi ha la prima risposta di richiesta HTTP (80) memorizzata su Chrome.

Ora, quando l'utente digita targetaddress.com , il browser ottiene automaticamente il reindirizzamento memorizzato nella cache (301 - HTTP in HTTPS location=https://targetaddress.com ) rendendo inutilizzabile SSLstrip.

La mia soluzione per questo era bloccare la porta 443 sul lato client, in modo che l'utente, non essendo in grado di connettersi alla destinazione, andasse a cancellare manualmente la cache / cronologia del browser nel tentativo di ripristinare la connessione. Quindi SSLstrip sarà efficace poiché ora intercetterà / manometterà la risposta HTTP (reindirizzamento 301).

Esistono altri modi migliori per farlo, oltre al blocco della porta 443?

Ecco il reindirizzamento memorizzato nella cache:

http://targetaddress.com/
HTTP/1.1 301 Moved Permanently
Date: Wed, 23 Dec 2015 18:31:19 GMT
Server: Apache
Location: https://www.targetaddress.com/
Content-Length: 237
Content-Type: text/html; charset=iso-8859-1
    
posta Bruno 23.12.2015 - 19:38
fonte

3 risposte

2

Se puoi fare in modo che il browser faccia una richiesta a http://targetaddress.com/whatever . Il browser eseguirà automaticamente una semplice richiesta HTTP, non una HTTPS in quanto non vi è alcuna risposta memorizzata nella cache per /whatever , solo per / .

Questo può essere ottenuto in diversi modi. Un modo è quello di MITM tra il browser e il sito qualsiasi accessibile tramite semplice HTTP e inserire un tag <img> . Un altro modo è ingannare l'utente per inserire targetaddress.com/whatever nella barra degli indirizzi tramite social engineering.

Non appena il browser invia una richiesta di testo in chiaro al dominio di destinazione, il MITM ha vinto la partita.

HTTP consente a un client di eseguire azioni su entità . Quale azione viene eseguita dipende dal metodo HTTP specificato nella richiesta . Quale entità l'azione viene eseguita dipende dall'UR specificato nella richiesta.

Diversi URL possono fare riferimento alla stessa entità, ma il browser non lo sa. Quando un browser memorizza nella cache una risposta HTTP, lo fa per un determinato URL .

http://www.target.com/ è un URL . http://target.com/ è un altro. http://www.target.com/whatever è ancora un altro. Quindi è http://www.target.com/? .

Ora, supponiamo che ci sia una voce nella cache per http://www.target.com/ in un browser. Ciò implica che ce n'è uno per qualsiasi altro URL sopra elencato? No, non è così.

Quindi, tornando alla domanda, facendo in modo che il browser invii una richiesta di testo normale nel caso in cui un reindirizzamento permanente venga restituito da un'applicazione Web sulla porta HTTP si tratta di creare un URL che non corrisponde a una voce della cache e induce l'utente a visitare questo URL .

Prova questo funziona:

127.0.0.1 - - [13/Apr/2016:10:01:17 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:01:35 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:10 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:36 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:16 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:25 +0200] "GET /? HTTP/1.1" 301 227 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

Sono stato in grado di effettuare sei richieste di testo in chiaro (numero arbitrario) HTTP allo stesso sito Web con lo stesso browser, anche se un reindirizzamento permanente è configurato per tutto. (E no, ho non svuota la cache del browser!)

Altri modi ovvi per aggirare un reindirizzamento permanente includono l'ingannare l'utente nel passaggio alla modalità browser anonima (senza cache) o il passaggio a un altro browser ("Ho problemi con l'accesso all'applicazione con IE. Puoi dare un'occhiata?" ).

    
risposta data 11.03.2016 - 12:11
fonte
1

Esistono più di alcuni percorsi pratici per consentire agli utenti di destinazione di svuotare la cache per te, che potrebbe essere la soluzione più semplice. Questo potrebbe anche non essere sospetto, specialmente per obiettivi non tecnici, dal momento che è stato un suggerimento di risoluzione dei problemi IT da tutti per anni.

È più semplice se stai eseguendo / fingendo un hotspot Wi-Fi per l'intercettazione. Crea una pagina "Termini e condizioni" che devono accettare quando si connettono per la prima volta, quindi non fornire loro l'accesso e dire "Ciò potrebbe essere causato da problemi di memorizzazione nella cache. Svuota la cache eseguendo X, Y, Z". Nessuno pensa davvero al caching come a una caratteristica di sicurezza, se lo capiscono del tutto. La maggior parte delle persone lo cancellerà allegramente in cambio di internet gratis, e poi sarai d'oro.

    
risposta data 25.10.2016 - 14:44
fonte
0

Potresti provare a eseguire synflood sulla porta 443. Il client non sarebbe in grado di connettersi e potrebbe non riuscire a tornare alla porta 80.

Solo un disclaimer, ma non l'ho provato. Qualcuno vuole intervenire?

    
risposta data 23.04.2016 - 09:07
fonte

Leggi altre domande sui tag