Attacco MITM con siti Web implementati HSTS

Aug 25 2020

Voglio eseguire un attacco Man-in-the-Middle contro la mia rete per scopi educativi. Voglio il seguente scenario: eseguire un attacco MITM con Bettercap, accedere a un sito Web e accettare l'avviso del certificato, il che significa accettare il certificato presentato da Bettercap (l'attaccante).

Domanda 1:

Voglio sapere se questo è possibile al giorno d'oggi con la politica di sicurezza HSTS implementata sui siti Web e l'elenco di precaricamento HSTS?

Domanda 2:

Le mie uniche possibilità sono i siti Web che non hanno implementato l'HSTS o esiste un modo per rimuovere HSTS ed eseguire l'attacco accettando il certificato?

Risposte

1 mti2935 Aug 25 2020 at 18:40

Domanda 1: Sì, è possibile. Il fatto che il sito sia nell'elenco di precaricamento HSTS indica solo al browser che dovrebbe sempre connettersi al sito tramite https e non http. L'elenco di precaricamento HSTS non contiene alcuna informazione sul certificato stesso.

Domanda 2: No, a causa della risposta alla domanda 1.

1 EsaJokinen Aug 26 2020 at 01:27

Anche se non normativo , i browser sono in genere seguendo le ben motivati- User Agent implementazione Consigli da RFC 6797, 12 per non lasciare che l'utente di bypass gli errori se c'è una nota politica di HSTS a posto.

12.1. Nessun ricorso da parte dell'utente

L'impossibilità di stabilire una connessione sicura su eventuali avvisi o errori (secondo la Sezione 8.4 ("Errori in Secure Transport Establishment")) deve essere eseguita senza "ricorso da parte dell'utente". Ciò significa che all'utente non dovrebbe essere presentata una finestra di dialogo che le dia la possibilità di procedere. Piuttosto, dovrebbe essere trattato in modo simile a un errore del server in cui non c'è nient'altro che l'utente può fare rispetto all'interazione con l'applicazione web di destinazione, a parte attendere e riprovare.

In sostanza, "eventuali avvisi o errori" indica tutto ciò che potrebbe indurre l'implementazione di UA ad annunciare all'utente che qualcosa non è del tutto corretto con la creazione della connessione.

Non farlo, ovvero consentire all'utente di ricorrere come "fare clic su finestre di dialogo di avviso / errore", è una ricetta per un attacco man-in-the-middle. Se un'applicazione web emette una politica HSTS, allora sta implicitamente optando per l'approccio "nessun ricorso da parte dell'utente", in base al quale tutti gli errori o gli avvisi del certificato causano la chiusura della connessione, senza alcuna possibilità di "ingannare" gli utenti facendogli prendere la decisione sbagliata e compromettersi .

Se è necessario essere in grado di MitM le proprie connessioni, ad esempio per scopi di test o debug, l'unico modo per aggirare HSTS è installare il certificato CA radice del proxy HTTPS come CA radice attendibile. In questo modo il certificato utilizzato dal proxy diventa un certificato valido e, quindi, HSTS non è un problema.

Secondo Fornisci un certificato CA di Bettercap da integrare nel browser # 536 , il certificato CA radice di Bettercap verrebbe memorizzato in /root/.bettercap-ca-cert.pem.