Expressway – Hack The Box [Write Up]

La máquina Expressway es una máquina fácil de HTB.

Si es tu primera máquina en Hack The Box y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento cómo introducirte en esta plataforma.

A continuación, para conectarte a la máquina, tendrás que establecer la conexión con la máquina víctima de HTB conectándote a la VPN desde la carpeta donde la tengas descargada, y desde ahí ejecutarás el comando «sudo openvpn».

ENUMERACIÓN DE PUERTOS

Comenzamos con la enumeración de puertos y conocimiento de versiones y servicios que corren sobre los mismos.

Antes, a mi me gusta asegurarme que efectivamente la máquina víctima está activa y ante qué sistema operativo (OS) nos enfrentamos. Para ello:

¿Está la máquina víctima activa y nos podemos comunicar con ella?

Aquí lo que haremos es ejecutar el siguiente comando y ver si el «host is up»:

El TTL es de 64 (63 en HTB por el nodo intermediario) por lo que estamos antes una máquina Linux.

Ahora que sabemos que la máquina víctima está activa, procedemos escanear la red lanzando un nmap para detectar qué puertos están abiertos con el siguiente comando:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.10.11.87 -oG Escaneo

En este caso por TCP sólo nos saca el puerto 22 ssh y el resto aparecen cerrados o filtrados.

Eso confirma que la máquina no expone muchos puertos TCP pero sí tiene servicios UDP relevantes.

  • 22/tcp (SSH): único puerto TCP abierto — sin credenciales, es un muro por ahora.
  • 68/udp open|filtered (dhcpc): puerto cliente DHCP; normalmente no es un servicio que explotar desde el exterior (es más bien prueba de que hay stack DHCP). No suele ser útil en CTFs salvo casos raros.
  • 69/udp open|filtered (TFTP): TFTP puede exponer ficheros si está mal configurado.
  • 500/udp open (isakmp / IKE): lo más relevante. IKEv1 con Aggressive Mode puede filtrar la identidad y dejarnos el hash para ataque offline.
  • 4500/udp open|filtered (nat-t-ike): NAT-Traversal de IPsec; suele acompañar al IKE y confirma presencia de VPN.

El puerto 500/udp abierto se asocia al servicio ISAKMP/IKE utilizado por VPNs IPsec. Este servicio será el objetivo principal.

Enumeración del servicio IKE

El protocolo IKE (Internet Key Exchange) establece túneles seguros para VPNs IPsec. La versión 1 (IKEv1) tiene dos modos de negociación: Main Mode (protegido) y Aggressive Mode (más rápido pero filtra identidades).

Utilizamos ike‑scan para identificar parámetros del servicio. De esta forma se usa el Main Mode:

sudo ike-scan 10.10.11.87

Pero no tenemos una respuesta deseada, por lo que pasamos al modo Aggressive Mode:

sudo ike-scan -A 10.10.11.87

El parámetro -A (o --aggressive) activa Aggressive Mode. El servidor devuelve un paquete que incluye ID(Type=ID_USER_FQDN, Value=ike@expressway.htb). Esto revela que existe un usuario llamado ike.

Capturar el hash PSK

Con el usuario identificado se repite el escaneo agresivo para capturar el hash del PSK. Además, se guarda el material necesario para el crackeo con -P:

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

Vemos como el IKE PSK nos devuelve una cadena con el hash de autenticación.

Creamos con nano ike.psk un fichero donde pegaremos toda la cadena anterior, y así poder usar psk‑crack en modo diccionario para crackearlo:

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

Y obtenemos la contraseña: freakingrockstarontheroad . Esta será la contraseña que usaremos para entrar por el puerto ssh con el usuario ike.

Estamos dentro y ya podemos acceder a la primera flag de user.

ESCALADA DE PRIVILEGIOS A ROOT

Ahora continuamos con la escalada para tener la flag de root y control de la máquina.

Para ello lo que hacemos primero es identificar a qué grupos pertenece ese usuario y permisos.

  • id – muestra que el usuario ike pertenece al grupo proxy.
  • which sudo – indica que la máquina utiliza un binario de sudo en /usr/local/bin/sudo, no el estándar /usr/bin/sudo.
  • sudo -l – devuelve un mensaje de denegación personalizado en lugar del típico “user is not in the sudoers file”. Esto sugiere que el binario de sudo ha sido modificado.

El grupo proxy suele tener permisos sobre servicios como Squid, un proxy HTTP que registra las peticiones.

Aprovechando que el usuario pertenece al grupo proxy, se tienen permisos de lectura sobre los registros de Squid. Visualizamos el directorio y el contenido:

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

Entre las muchas líneas de log, una entrada denegada muestra un intento de acceso a http://offramp.expressway.htb.

Esto nos indice un hostname interno (offramp.expressway.htb) que no aparece en resoluciones DNS externas y sugiere que el sistema diferencia acciones según el nombre de host.

Comprender el binario sudo personalizado

Al ejecutar sudo -l se observa que el binario reacciona de forma distinta dependiendo del nombre de la máquina.

sudo tiene un parámetro -h que permite especificar un hostname remoto. La hipótesis es que el binario solo permite ejecutar comandos como root cuando el hostname coincide con un valor permitido.

Si se puede engañar al programa para que crea que se está ejecutando en el host offramp.expressway.htb, podría omitirse la restricción.

Para ello, se ejecuta sudo indicando el hostname descubierto y se solicita una shell de Bash:

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

Esta escalada se debe a un error en la lógica del binario personalizado: confía en el nombre de host suministrado sin realizar comprobaciones serias, lo que permite ejecutar comandos privilegiados en cualquier circunstancia.

RESUMEN DE LA MÁQUINA EXPRESSWAY

Primero hicimos enumeración: un escaneo TCP mostró solo SSH abierto, así que ampliamos la búsqueda a UDP y encontramos el servicio IKE/IPsec (puerto 500).

Al inspeccionar ese servicio descubrimos que estaba usando IKEv1 en modo agresivo, lo que permitió obtener una identidad asociada al usuario y capturar material criptográfico que, tras un ataque offline, reveló la clave compartida (PSK). Esa clave se reutilizaba como contraseña de usuario, con lo que entramos al sistema como el usuario ike y recogimos la flag de usuario.

Una vez dentro, hicimos enumeración local: comprobamos grupos y permisos y vimos que ike pertenecía al grupo del proxy, lo que nos dio acceso a logs legibles de Squid. Esos logs contenían un hostname interno (offramp.expressway.htb) y además detectamos un sudo personalizado ubicado en /usr/local/bin/sudo.

Al entender la l ógica del sudo (que permitía especificar un host), usamos esa condición de hostname para activar la política insegura y ejecutar una shell con privilegios de root, y obtuvimos la flag de root.

TÉCNICAS APLICADAS

Enumeración (TCP & UDP) — Búsqueda de servicios y puertos abiertos; al principio solo apareció SSH por TCP, así que se amplió la búsqueda a UDP para no dejar huecos en la detección.

Escaneo de servicios UDP — Identificación de servicios UDP (notablemente IKE/IPsec) que no aparecen en un escaneo TCP normal y que indicaron la presencia de una VPN.

Fingerprinting de IKE (ISAKMP) — Inspección del protocolo IKE para ver cómo está configurado y detectar si revela identidades (p. ej. Aggressive Mode).

Ataque de diccionario/recuperación de PSK — Prueba de contraseñas conocidas para verificar si la PSK es adivinable debido a baja reutilización.

Acceso inicial por SSH (post-enumeración) — Uso de las credenciales obtenidas para iniciar sesión como usuario con permisos limitados y comenzar la enumeración local.

Enumeración local y análisis de registros — Revisión de grupos de usuario, permisos y logs (por ejemplo logs de proxy) para encontrar información interna (hostnames, rutas, errores) que no es visible externamente.

Detectar binarios SUID/personalizados — Localizar un sudo ubicado fuera del binario estándar (indicio de binario personalizado con lógica insegura) como posible vector de escalada.

Bypass de política basada en contexto (hostname-based bypass) — Explotación de una lógica de control que dependía del hostname (contexto) para ejecutar comandos con privilegios más altos; al cambiar la condición de contexto se consiguió elevación de privilegios hasta root.

Otros posts relacionados