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.

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.

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:

We can search for exploits for these two plugins.

There was only this to exploit, so let's try it. This exploit works by accessing this link for an RFI:

We can grab a PHP reverse shell from PentestMonkey and rename it to wp-load.php and use this RFI to execute it.

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:

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.

From GTFOBins, we can use this command to get a shell as the user:

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:

There's a program backuperer being run by root periodically. This was actually a bash script, and here's its contents:

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:

Afterwards, we can compile this and make it an SUID binary.

Then, move this into /tmp/var/www/html and tar the entire folder.

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.

Then, we can view the /var/tmp/check/var/www/html folder to find our SUID binary:

Then just execute it and it we would get a root shell. Rooted!

PreviousStreamIONextTenet

Last updated