TartarSauce
Reconnaissance: NMAP
┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.88
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Landing Page
| http-robots.txt: 5 disallowed entries
| /webservices/tar/tar/source/
| /webservices/monstra-3.0.4/ /webservices/easy-file-uploader/
|_/webservices/developmental/ /webservices/phpmyadmin/
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=1/5%OT=80%CT=1%CU=34230%PV=Y%DS=2%DC=I%G=Y%TM=6598C
OS:780%P=x86_64-pc-linux-gnu)SEQ(SP=100%GCD=1%ISR=10D%TI=Z%CI=I%II=I%TS=A)S
OS:EQ(SP=FF%GCD=1%ISR=10D%TI=Z%II=I%TS=A)SEQ(SP=FF%GCD=1%ISR=10D%TI=Z%CI=I%
OS:II=I%TS=A)OPS(O1=M53AST11NW7%O2=M53AST11NW7%O3=M53ANNT11NW7%O4=M53AST11N
OS:W7%O5=M53AST11NW7%O6=M53AST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=712
OS:0%W6=7120)ECN(R=Y%DF=Y%T=40%W=7210%O=M53ANNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40
OS:%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=
OS:%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%
OS:W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=
OS:)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%
OS:DFI=N%T=40%CD=S) Enumeration: HTTP Port 80 TCP
SERVER Apache httpd 2.4.18
http://10.10.10.88/ view-source:http://10.10.10.88/
robots.txt http://10.10.10.88/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/
http://10.10.10.88/webservices/monstra-3.0.4/
Gobuster:
Nikto:
It gives us a list of URLs that web robots are instructed not to visit. Only one of these links are valid.
The application is using a Content Management System (CMS) called Monstra and the version is available at the footer of the site (3.0.4). Let’s see if it has any known exploits.
The version being used is vulnerable to an authenticated RCE exploit. So we first need to find credentials.
Click on the “logged in” link and try the default credentials admin/admin.
http://10.10.10.88/webservices/monstra-3.0.4/admin/
admin:admin
It worked! Copy the RCE exploit into the current directory.
View the exploit. It seems like there’s insufficient input validation on the upload files functionality that allows a malicious attacker to upload a PHP script. Let’s try doing that.
I tried a bunch of valid extensions, however, I kept getting a “File was not uploaded error”. The upload functionality does not seem to be working at all. So this is a dead end.
We need to enumerate more. Run gobuster on the webservices directory.
dir: directory mode -w: wordlist -l: include the length of the body in the output -t: thread count -e: expanded mode, print full URLs -u: URL -o: output file
This is a WordPress site, so let’s run wpscan on it to determine the version used and enumerate any installed plugins.
— url: the URL of the blog to scan -e ap: enumerate all plugins — plugins-detection aggressive: use the aggressive mode — api-token: personal token for using wpscan
The WordPress version identified is 4.9.4. It has two plugins installed: akismet and gwolle-gb. Let’s check if the gwolle-gb plugin has any vulnerabilities.
It is vulnerable to a remote file inclusion (RFI). Copy the exploit to the current directory.
View the exploit.
The “abspath” input parameter being used in the PHP require() function is not properly validated and therefore, a malicious attacker can upload and run a malicious PHP script withe filename wp-load.php.
Shell as www-data
Get a PHP reverse shell from pentestmonkey and rename it to wp-load.php.
Start up a simple server where the shell is located.
Set up a netcat listener on the attack machine to receive the reverse shell.
Visit the following link with the correct URL to the simple server.
Let’s upgrade it to a better shell.
Privesc: www-data –> onuma
Run the following command to view the list of allowed commands the user can run using sudo without a password.
As can be seen above, we have the right to run the binary /bin/tar with onuma’s privileges.
Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.
Perfect! Run the following command to get a shell running with onuma’s privileges.
Partial Privesc: onuma –> File Read as root
To view the root.txt flag, we need to escalate our privileges to root. Let’s transfer the LinEnum script from our attack machine to the target machine. In the attack machine, start up a server in the same directory that the script resides in.
I’ve never seen a service called backuperer.service before, so this must be a custom service. Let’s see if it is being run as a scheduled task. Download pspy32 and view results.
It is being run on a consistent basis. Locate the backuperer file on the target system.
View the backuperer.timer file.
Let’s breakdown what the script is doing. First, the following variables are being initialized in the script.
Then the script performs the following actions.
Recursively deletes the files/directories: /var/tmp/.* and /var/tmp/check.
Creates a gzip file of the directory /var/www/html and saves it in the file /var/tmp/.[random-sha1-value].
Sleeps for 30 seconds.
Creates the directory /var/tmp/check.
Changes to the directory /var/tmp/check and extract the gzip /var/tmp/.[random-sha1-value].
If the files in /var/www/html are different from the files in the backup it created /var/tmp/check/var/www/html, then report error. Otherwise, move file /var/tmp/.[random-sha1-value] to /var/backups/onuma-wwww-dev.bak and remove everything in the check directory and any files that start with the character “.”. Those would be the backup .[random-sha1-value] files it created.
The exploit for this is not very intuitive so bear with me as I try to explain it. When the backup is being created, the script sleeps 30 seconds before it executes the rest of the commands. We can use these 30 seconds to replace the backup tar file that the script created with our own malicious file.
After the 30 seconds pass, it will create a directory called “check” and decompress our malicious backup tar file there. Then it will go through the integrity check and fail, thereby giving us 5 minutes before the next scheduled task is run, to escalate privileges. Once the 5 minutes are up, the backuperer program is run again and our files get deleted.
The way we’re going to escalate privileges is by creating our own compressed file that contains an SUID executable. Hopefully that makes some sense. Let’s start our attack.
First, create the directory var/www/html in our attack machine. Then place the following program file in the directory.
Exploiting backeruperer
To exploit this script, I’ll take advantage of two things: the sleep, and the recursive diff. During the sleep, I’ll unpack the archive, replace one of the files with a link to /root/root.txt, and re-archive it. Then when the script opens the archive and runs the diff, the resulting file will be different, and the contents of both files will end up in the log file.
I originally did this with a long bash one-liner, but it is easier to follow with a script:
Now, upload this to target and run it. I’ll name it .b.sh for opsec:
Last updated