CMS from CyberSecLabs is a beginner level box hosting a WordPress installation. Using a file inclusion vulnerability we’ll gain access to the target, and exploit weak sudo permissions to escalate to root.
Let’s get started.
The IP Address for CMS is 172.31.1.8
Scanning and Enumeration
As always we run our Nmap scan against the target with -sC for default scripts, -sV for enable service enumeration, -p- to scan all TCP ports.
Only two open ports on the target. Port 22 running SSH and port 80 hosting a HTTP web server. When we see this on a pentest or capture the flag, port 80 is almost always the initial entry point.
Next, I’ll run Nitko against the target to scan the web server.
Nothing actionable here other than confirming a WordPress installation. Let’s move on to directory busting.
Again, we don’t find anything interesting, other than a couple WordPress pages.
Nikto and Gobuster didn’t provide us with any actionable information. We need to dig deeper and enumerate the web server. Which happens to be a WordPress site, let’s use….
WPScan is a WordPress vulnerability scanner that helps enumerate plugins, themes, and other information about WordPress installations. Let’s run this against the target web server.
WPScan with default options will generate a list of theme’s, and plugins to enumerate. It also points out which versions are out of date.
Here we see a plugin identified. I’m not familiar with this specific plugin, so I’ll do a quick Searchsploit to see if it has any known vulnerabilities.
Searchsploit will search the local Exploit-DB repository on your Linux box. Provided you’ve updated the Searchsploit database, what you see here are the same results you’ll find on the Exploit-DB website.
We find an exploit for the WP with Spritz plugin. Our version also matches, so now we have a vulnerability to exploit.
We have a vulnerable WordPress plugin named WP-with-Spritz. Our exploit is a Remote File Inclusion vulnerability as stated in the title. However, if you look at the code we have two working POC’s. One Remote file inclusion, and one for Local file inclusion. Which one do we use to exploit?
File Inclusion Vulnerabilities
LFI or Local File Inclusion vulnerabilities allow the attacker to read and sometimes execute files on the target machine.
RFI or Remote File Inclusion vulnerabilities are easier to exploit but less common. Instead of accessing a file on the target system, the attacker is able to execute code hosted on their own machine.
Now we’ve got a primer on file inclusion vulnerabilities so let’s continue. Essentially, we’re manipulating the URL address into displaying local files on the target. The POC provided in the exploit will grab the /etc/passwd file. Since this file is readable by all users on a Linux system, this is a great way to test the vulnerability.
I navigate to the following URL and then right click and select “View Source”. This will provide the formatting associated with the file.
Pause for a moment and think back to our initial Nmap scan. Two ports open. One is the web server, and the other is SSH. That means we could probably find a user with a private key that might allow us to connect to the target over SSH.
On a Linux system private SSH keys are stored in the user’s home folder under .ssh. If we peak at the /etc/passwd file you notice the only other user account besides root is the “angel” account. That’s our user.
Modify our URL address path to /home/angel/.ssh/id_rsa in your browser and go. Again to format the file, right click and select “View Source”.
Copy the private key into a file named id_rsa. Then chmod on the file to allow us to execute it.
Now we’ll use the private key inside the id_rsa file to connect to the target over SSH as the angel user.
Success! We are now logged into the target as Angel.
You’ve gained access to a Linux system as a low privileged user. What’s the first thing you do?
Check Sudo Permissions. The easiest and quickest win on a Linux system can be found by running Sudo -L.
This will show you what commands can be run under the Root account without a password, by the current user.
This is the holy grail for Sudo permissions. If you ever find a user who can run (ALL : ALL) NOPASSWD: ALL, you can immediately own that box and become root.
Again, whatever command we run will be run under the Root account. All we have to do is spawn a bin/bash shell as the root user. Boom. Done. It’s that easy.
Capture the flags!
Don’t forget to capture your flags and complete the box.
That is CMS from CyberSecLabs. An excellent beginner box that demonstrates how to exploit a file inclusion vulnerability to gain initial access to the target. Once we got our low privileged user, we used a simple Sudo command to spawn a root shell. Always, always, always check those Sudo permissions. That is easiest and quickest way to score a win on Linux.