mKingdom
Beginner-friendly box inspired by a certain mustache man.
Last updated
Beginner-friendly box inspired by a certain mustache man.
Last updated
This work by Manav G Krishna is licensed under
Machine IP: 10.10.54.202
Hosts file entry: echo '10.10.54.202 mkingdom.thm' | sudo tee -a /etc/hosts
Nmap Scan:
The scan results shows that we have only one open port, that is port 85, running an Apache web server.
Checking out port 85:
There was nothing interesting in the source code of the page.
We can download the image on this page and can extract the metadata from it using exiftool , to see if we get any good information:
Commands:
The Creator field set to b0w53r shows that the image was created by b0w53r.
Now we can do some directory busting:
Command:
There is a path named /app. We can check this out:
The source code says that, upon clicking on JUMP we will be redirected to a castle page:
Doing the same:
We are now at /app/castle page.
Exploring the page:
We can see what Wappalyzer tells us:
The CMS (Content management system) being used is Concrete CMS - 8.5.2.
The same information can be fetched by using a tool called cmseek and also by checking out the source code of the page:
Command:
Towards the bottom of the page we find this:
A Log In option. There was nothing of interest in the page's source code other than the CMS version.
Since we know the CMS being used, we can try to find if there any default credentials:
The default username is admin, but there is no default password.
Now we can try out a few possible default passwords such as admin, password, password123 etc. The correct password turned out to be password itself.
Logging in:
We are now logged in as admin. The name that we got previously from the image on the root of the website, not sure what that was for. Now we can try to find some exploits for the version 8.5.2 of Concrete CMS.
Finding exploits:
Exploitation steps:
Following the same:
Visiting Allowed File Types:
Adding php extension and Saving:
Visiting File Manager:
Fetching a PHP payload and Uploading:
In the POC, an msfvenom payload is what is being used. Instead we can use the PHP PentestMonkey one from revshells.com:
Have saved it as shell.php:
Click on Close.
The moment we close it we get this window saying - Upload Complete:
Setting up a listener on port 4444:
Now upon clicking on the URL to File / Tracked URL link the PHP shell must get triggered and we should be getting a connection on our listener.
We indeed have got the shell as www-data:
Stabilizing the shell:
Enumeration:
We have two users other than root having a console, that is toad and mario:
Checking for binaries that have the SUID bit set:
Command:
The cat binary has the SUID bit set:
This means the cat command will only run as the owner as far as the SUID bit is set, in this case, toad.
So a direct root flag fetching is not possible as even after becoming toad, toad simply can't traverse inside /root directory even if the root flag had read permissions for others (toad in this case) due to fully restrictive default permissions of the /root directory (drwx------). This also applies even if cat didn't have the SUID bit set. The same permission restriction is there by default on the /home/[user] directories too.
All other users who are neither the owner nor members of the group for the file falls under others. The root flag could have been fetched if the owner of cat was set to root along with the SUID bit set.
Removing the SUID bit eases restrictions as once the bit is removed, cat command when run, runs as the user running the command itself. So if we are using cat after becoming mario, cat command runs as mario, if we are using cat after becoming root, cat command runs as root. The owner of the binary doesn't have any effect at all.
Checking out common directories:
This leads us to a database.php file within the directory - /var/www/html/app/castle/application/config:
The file had MySQL credentials. The username being toad. The first thing that comes to our mind is that we could try to get in as toad using the found password. But before this, let us see if we have MySQL running and if we could possibly connect to the database that might contain some information about the other user, mario.
Checking out active network connections:
Command:
And we indeed notice port 3306 running & listening for connections on the machine's localhost.
Connecting to the database:
Command:
The only thing that we find is the admin's hashed password (password), the Concrete CMS login password that we had used initially.
We can confirm it is the same post cracking it:
Nothing of interest in the database.
Now we try to get in as toad using su:
As expected we are the user toad.
Now we can remove the SUID bit being set on cat:
Command:
Now the s is replaced with w. The SUID bit has been removed.
We don't have the user flag in toad's home directory. Let us now do some more enumeration.
Enumeration:
We can't run sudo:
The .bashrc files gives us a base64 encoded password token:
The same can be found out by fetching the environment variables too:
Decoding the PWD_TOKEN:
Command:
We get the password. This might be mario's password. We can try to get in as mario using su:
We are now the user mario.
Enumeration:
We have the user flag in mario's home directory:
Firstly we are able to use cat as we had removed the SUID bit when we were toad. So as mentioned before now cat when used runs as mario itself. Secondly the user flag's file owner and group is root and due to this mario falls under others. The main reason why we are able to still read the flag is because, others have read permissions on the file (r--).
If we hadn't removed the SUID bit before, upon trying to cat the user flag we would be getting this:
This is because even though toad too falls under others itself in the context of the user flag and since others can read it even with the SUID bit set, it just doesn't work due to the permissions (drwx------) on mario's home directory (/home/mario). So toad can't even traverse it in the first place to fetch the user flag.
But we can still read the flag using other utilities as only cat is what can't be used (without removing the bit):
Privilege Escalation:
Checking for sudo rights/privs:
The id command can be run with sudo rights:
But this obviously seems to be something kept to derail us, a rabbit hole. There are no methods available to make use of id to privilege escalate.
We also have pwfeedback option enabled in the sudoers entry. pwfeedback is a display feature to show an asterisk when an user writes a character of its password.
To confirm if it is enabled we can see if asterisks are coming up when we enter mario's password:
We indeed see it. This leads us to, CVE-2019-18634.
CVE-2019-18634:
It is a sudo LPE vulnerability that needs pwfeedback to be enabled for it to work. It is a BOF exploit.
But the sudo version must be lesser than 1.8.26 for it to work.
Checking out the sudo version:
The version running on the machine is 1.8.9p5. So the exploit won't work.
Now let us see if we have any cron jobs running. For this pspy can be used:
The machine is 64-bit:
So we have to use 64-bit compatible pspy:
Sending it to the target machine post setting up a python server:
Command:
Running it:
This cron job running as root (UID=0) stands out to us:
A curl request is being sent to mkingdom.thm on port 85 to access and execute a counter.sh script located at /app/castle/application/.
Checking out the scripts permissions:
Only root has write access to it, we as the user mario has only read permissions. So editing this file to place a reverse shell is now out of the picture.
But the curl request is being sent to the host mkingdom.thm. So let us check out the /etc/hosts file as this is used to map hostnames to IP addresses.
Here we are able to cat the hosts file out as the file has read permissions for others and mainly because the /etc directory has execute permissions for others. So it doesn't matter even if the SUID bit is set on cat with toad being the owner as when we run: cat /etc/hosts it will still run as toad and toad falls into others and due to the execute permission on /etc, toad will be able to traverse this directory.
The hosts file's group is mario and we as mario have write permissions on the file.
Thought process:
Based on the cron job command, what we could do is edit the hosts file entry to point mkingdom.thm to our IP (tun0) and we could place a counter.sh file containing the reverse shell within app/castle/application/, post creating this exact directory structure on our attacker machine. We would also have to set up a python server on port 85. When the cron job runs, the curl request hits our IP and the /app/castle/application/counter.sh will be served via port 85 and we would get a root shell on the listener that we set up.
Editing the file:
Creating the directory:
Command:
The counter.sh file contents:
Setting up the python server:
Setting up a listener on port 445:
Now we just wait for the cron job to run.
After a few seconds we can see that the counter.sh file got served from our machine:
Now let us check out the listener:
We indeed have got a connection as root.
The root flag can be cat ed out as we had removed the SUID bit from it when we were toad itself:
Now if the bit was still set, we would get this:
So we can use the methods that we did before to read the flag (more, less, head, tail).
Default /root directory permissions:
Only read, write & execute for the owner, that is root.
We can also change the /root directories permissions, so that cat with the bit set which is running as toad can traverse (execute permission) the /root directory when cat /root/root.txt is run and will be able to read the flag as it has read permissions (r--) for others, under which toad falls:
Command:
Room solved!!
