Quartz 4

MITM

6 min read

tags: MITM burpsuite BurpSuite_MITM session_hijack manipolazione_sessione

Cosa copre questa nota Il workflow completo per intercettare e modificare il traffico di una vittima con un proxy intercettante (Caido nella guida CEH, Burp come alternativa), l'esempio classico dello swap di due siti (moviescope.com ⇄ goodshopping.com), e — soprattutto — tutti i tranelli reali che bloccano l'esercizio: binding del listener, certificato CA, store di Firefox, CSS che si rompe, e il perché del warning TLS. Chiude con il quadro concettuale su TLS/MITM.

0. Modello mentale

Un intercepting proxy si mette in mezzo tra il browser della vittima e Internet: tutto il traffico passa da lì, così tu puoi leggerlo e modificarlo prima che arrivi a destinazione.

Analogia Sei un postino disonesto. La vittima ti consegna tutte le lettere (il traffico) perché ti ha nominato suo intermediario (il proxy). Tu le apri, magari ne cambi il contenuto, e le inoltri. Per le lettere "sigillate" (HTTPS) serve un trucco in più: convincere la vittima a fidarsi del tuo sigillo (la tua CA), altrimenti si accorge della manomissione.

Due ingredienti rendono possibile il MITM su HTTPS nel lab:

  1. La vittima usa te come proxy (per HTTP e HTTPS).
  2. La vittima si fida della tua CA (l’hai installata nel suo browser). Togli uno dei due e l’attacco non funziona — ed è esattamente lì che nascono gli errori.

1. Setup del proxy — il listener deve ascoltare sulla rete

Tranello #1: loopback vs all interfaces Di default il proxy ascolta solo su loopback (127.0.0.1:8080) → raggiungibile solo dalla macchina attaccante. Dalla vittima http://<attaccante>:8080 risulterà "pagina inesistente".

Fix:

  • Caido: menu accanto a Start → Edit → seleziona All interfaces (0.0.0.0) → Save → Start.
  • Burp: Proxy → Proxy settings → Proxy listeners → seleziona 127.0.0.1:8080 → Edit → scheda Binding → Bind to address: All interfaces → OK. Nella colonna Interface deve comparire *:8080, con Running spuntato.

Scope "All interfaces" espone il proxy sulla rete: solo in lab/rete autorizzata.

2. Certificato CA sulla vittima

  • Caido: dalla vittima vai a http://<attaccante>:8080/ca.crt → scarica in automatico.
  • Burp: il percorso /ca.crt non esiste. Vai su http://<attaccante>:8080 e clicca CA Certificate (in alto a destra): scarica cacert.der (formato DER, non .crt).

Importarlo nel posto GIUSTO

Tranello #2: Authorities, non "Your Certificates" In Firefox il certificato va in Settings → Certificates → View Certificates → scheda **Authorities** → Import, spuntando "Trust this CA to identify websites".

3. Configurare il proxy sulla vittima — la chiave per non rompere le pagine

Sulla vittima, in Firefox: Settings → cerca "proxy" → Manual proxy configuration:

  • HTTP Proxy = IP dell’attaccante, Port = 8080
  • spunta “Also use this proxy for HTTPS”

Perché questo passo è decisivo Solo se la vittima instrada tutto (HTTP e HTTPS) attraverso il proxy, allora anche le sotto-risorse (CSS, JS, immagini) passano da te. È esattamente ciò che nel lab fa caricare le pagine con la grafica intatta. Se l'HTTPS non passa dal proxy, o lo scope di Burp è ristretto a un solo host, le risorse "sfuggono al tunnel" → pagina senza stile (vedi §4).

4. Modificare il traffico

4a. Metodo manuale (quello che la guida mostra)

Intercept ON → per ogni richiesta GET, modifichi l’host (es. moviescope.com → goodshopping.com) nell’header Host e nel Referer → Forward → ripeti finché la vittima non vede il sito diverso.

È volutamente laborioso: la guida te lo fa fare a mano per mostrarti il concetto, non perché si lavori così.

4b. Metodo automatico: Match & Replace (quello che si usa davvero)

Intercept OFF + una regola che riscrive il traffico al volo, valida per tutta la sessione:

Burp: Proxy → Proxy settings → Match and replace rules → Add

Definisci il tipo (header di richiesta, header/body di risposta…), la stringa da cercare e quella con cui sostituirla. La imposti una volta e copre la prima richiesta come le successive 200.

4c. Lo swap di due siti e il tranello del CSS

Tranello #5: HTML sostituito ma CSS rotto (pagina blu/nuda) Se cambi solo l' header Host della richiesta, l'HTML viene servito dal sito bersaglio, ma i link assoluti alle risorse dentro l'HTML (es. http://www.goodshopping.com/style.css) restano invariati: il browser li richiede all'host originale, la richiesta esce dal tunnel e fallisce → niente CSS.

Soluzione — coppia di regole che lavorano insieme (esempio: la vittima naviga moviescope, vuoi mostrarle goodshopping):

  • Request header: moviescope.com → goodshopping.com (dirotta le richieste verso GoodShopping)
  • Response body: goodshopping.com → moviescope.com (riscrive i link assoluti nell’HTML, così anche le risorse ripassano dal proxy)

Nota onesta La causa "risorse con URL assoluto fuori dal proxy" è la spiegazione più probabile del CSS rotto, ma non è garantita in ogni caso: la controprova la fai nella HTTP history, guardando come sono scritti i <link href=...> dei CSS nella risposta e a quale host il browser li richiede. La condizione necessaria resta comunque il proxy per tutto del §3.

4d. Il risultato È l’obiettivo

Quando la barra degli indirizzi mostra un sito ma il contenuto ne mostra un altro, hai vinto: “la vittima ha navigato su moviescope.com, ma vede goodshopping.com”. È la dimostrazione della manomissione del traffico — anche se la resa è grezza, il concetto è provato.

5. HTTPS e MITM — il quadro concettuale

Perché scatta il warning “certificato pericoloso”

TLS è progettato apposta per impedire a un estraneo di mettersi in mezzo. Il proxy presenta alla vittima un certificato firmato dalla tua CA; il browser controlla se quella CA è tra le sue autorità fidate: se no, blocca. Nel lab funziona solo perché controlli la vittima e le installi la tua CA — cioè bari, per scopo didattico.

È obsoleto?

Risposta sfumata

  • Come attacco puramente di rete contro l’HTTPS moderno di un sito ben configurato: sì, ampiamente neutralizzato (HTTPS ovunque, HSTS, preload, certificate pinning). Il warning che vedi È questa difesa che funziona.
  • Come strumento di test di web app (il suo uso principale): per niente obsoleto — installi la CA sul tuo browser per ispezionare il tuo traffico. È lo strumento base della sicurezza web.
  • Come attacco quando riesci a far fidare la CA: vivissimo. Scenari reali: TLS inspection aziendale (CA installata su tutti i dispositivi), post-compromissione (malware che installa una root CA), social engineering (finto certificato “richiesto”), client che non validano (molte app mobile, IoT, thick client), e il semplice HTTP in chiaro che non richiede alcun certificato.

Il passo “installa la CA sulla vittima” — quello che ti ha dato battaglia — è precisamente ciò che nella realtà protegge gli utenti: un attaccante quel passo non può darlo per scontato.

Una volta fidata la CA, HTTPS = HTTP

Dopo l’handshake, il proxy decifra il traffico e tu lavori sul contenuto in chiaro: richieste e risposte modificabili come in HTTP. Il “molte pagine, molte richieste” non è un problema di HTTPS, è un limite del metodo manuale — e Match & Replace lo annulla.

Graph View