CMS is a beginner linux box from cyberseclabs.co.uk hosting a wordpress instance with a vulnerable plugin installed we can use to gain a shell, from there we’ll go back to the basics to elevate our shell to root. Let’s begin!

Recon

We’ll start off by firing off autoenum (found here) and giving it the IP of the box, we’ll then be prompted for a scan profile. (I default to aggr).

We’ll give it a few minutes to work its magic.

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 2a:da:3d:c8:51:73:2c:4e:f3:5e:95:4d:5c:b8:a0:7d (RSA)
|   256 8d:22:9a:44:8c:d4:89:f7:d9:e2:51:db:18:eb:f6:5b (ECDSA)
|_  256 78:8e:46:d3:64:6a:5a:68:d2:09:4d:9d:3b:27:9f:be (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-generator: WordPress 5.3.2
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: CMS
|_https-redirect: ERROR: Script execution failed (use -d to debug)

We have two ports open and it looks like we have wordpress running on the webserver. Let’s poke around the webserver and see where that gets us.

Enumerating WordPress

Taking a look at the landing page, it looks like a poorly built page with images missing. On the top right corner, we see a tab called blog, we may find something useful there.

The lastest blog post reveals an interesting bit of info.

From this, we’ve learned that that angel user has the same perms as www-data (For some info on this user, click here) and that there are ssh keys in angel’s home directory. Before we move on, let’s take a step back and figure out what an ssh key is and why are there three files in this dir?

SSH Keys?

As we already know, SSH is a service used to access a machine. When we think of SSH, we think of logging in with a username and password much like any other login. But as with any other login, this can be bruteforced. In this case we have two choices, we can either use a more secure password or we can generate what are called keys. This is a more secure method of logging into an SSH enabled machine as we won’t be supplying a password so there is no chance to run something like hydra against it in hopes we get the right password eventually. It is impossible to bruteforce these keys the way we can with a password…from the outside at least. But what actually are these keys and how do they replace a password?

These keys work using an asymmetric cryptographic system, basically meaning there is a private key and a public key. The way this system works is that there is a public key to encrypt and a private key to decrypt. The machine will hold the public key(this is the id_rsa.pub) and the one connecting to the machine via SSH will hold the private key(id_rsa). This way only the users who hold the private key will be able to gain access to the machine. This leaves the authorized_keys file. This file tells the server what private key is accepted. If you’d like to learn how to set these up yourself, click here.

I’m not going to delve into the inner workings of the cryptographic aspect as its beyond the scope of this write-up, all we need to know is the relationship between a private key and a public key. If you’d like a more detailed explanation, I found this.

Gaining an Initial Shell

We know what these keys are, but as we have learned, we can’t just bruteforce these like we can with a password. We’ll have to find a way to gain access to these keys if we want to get anywhere.

Discovering Vulnerable WP Plugins

WordPress is known to have vulnerable plugins so let’s see if we can find any plugins installed on this instance, we’ll use a WordPress automated scanner for this called wpscan. Because the feature we want requires an API key, head on over here and create an account with the free plan. I had to go through a few temp email sites but I finally found this one that worked. You’ll be sent a confirmation and have to log in. Once logged in, look for the API tab and scroll down to API Token and copy your API key.

Now that we have our API token, we can use wpscan to check if this webserver has any vulnerable plugins.

We’ll use four arguments for this. The --url will point wpscan to our webserver, -e ap will tell it to enumerate all the plugins, --plugin-detection will scan all plugins aggressively and finally we’ll use --api-token to supply the token we generated from before. This might take a bit, might as well go grab a cup of coffee while waiting.

We have two plugins installed, akismet and wp-with-spritz. Let’s see if we can dig up anything on em with searchsploit. According to wpscan, wp-with-spritz has something.

There are a few XSS vulns for akismet but that won’t get us any closer to grabbing the keys, though we do have an interesting find for spritz.

Fetching SSH Key

According to searchsploit, we have an RFI, we can use this. An RFI would allow us to fetch files from the server, more on RFIs here. We’ll pull down the exploit and take a look.

We have a PoC, let’s try it out! If we can fetch /etc/passwd, we should be able to fetch the private key too.

It worked! Great, now we can fetch the private key and use it to log into the machine as the user angel. We already know the location of the private key so let’s go and grab it (You can also go grab the user flag too)

We’ve successfully fetched the private key. Before we move it to our machine, copy-paste it here so ssh doesn’t throw a fit for the wrong format. Should look like this when copied over to our machine:

 

id_rsa to Shell

When we try to pass ssh the ssh key we get the following error:

This is because ssh demands the permissions for private keys to be read only for the owner of the file, which can be easily fixed by changing the permissions using chmod. The read perm is 4 and the format is owner-group-other, knowing this we can give the file a mode of 400. Let’s try this again.

We have a shell as the user angel!

Priv Esc

We’ll do some basic post-exploitation enumeration on the box and go from there. As this is a linux box, the first few things we want to do is check our user (we already know we are the user angel with the perms of the www-data account) and their perms, if they can run anything as the root user, and the architecture.

Looking at the output of sudo -l, we can see that all users can run anything as the root user.

You get Root, You get Root, We all get Root!

From our post-exploitation enumeration, we know that any user can run commands with root privs, meaning we can do something like this

We are root!