DeRPnStiNK is a boot2root aimed at beginners. It contains 4 different flags in the following format: flag1(AB0BFD73DAAEC7912DCDCA1BA0BA3D05). The author tells us not to bother cracking the flag hashes as they have nothing to do with the challenge. You can download it from vulnhub here.

Scanning

First step is to find our target’s IP address. We’ll accomplish this with arp-scan.

Our target is located at 192.168.80.128. Our next step is to determine what ports are open using nmap.

Port :21

There is an FTP server running at port 21. nmap informs us that it is likely a version 3.0.2 vsftpd server, and connecting to the service with the ftp command confirms this. Unfortunately, it seems that the anonymous user has been disabled.

Port :22

OpenSSH 6.6.1p1 is running on port 22. nmap tells us that it is an Ubuntu version, providing a pretty good hint as to what OS our target is using.

Port :80

There is a web server running at port 80, powered by Apacher version 2.4.7.

Vulnerability Analysis

FTP

Searchsploit doesn’t return anything in terms of vulnerabilities for vsftpd 3.0.2.

SSH

The SSH service does not appear to be vulnerable to anything, either. Attempting to connect to the server shows that it password login is disabled in favor of private/public key pairs. Not going to be brute-forcing that.

HTTP

There do not appear to be any exploits for our version of Apache. Visiting the site yields a page without any links.

If we take a look at the source for the page, we find our first flag!

flag1(52E37291AEDF6A46D7D0BB8A6312F4F9F1AA4975C248C3F0E008CBA09D6E9166)

Let’s root around the web server a bit more before pulling out some tools. Robots.txt tends to yield interesting results:

Unfortunately, neither of these directories yield anything, at first.

/php/ doesn’t directly resolve to anything

and /temporary/ provides some OSCP-style trolling. Time to use some tools. I generally run both dirb and nikto against any boot2root web server that I meet:

Some interesting findings here. First, /php/ contains a phpmyadmin installation. This might yield some great information if we can log in. The second is that there is another directory at /weblog/ that contains a wordpress installation.

Nikto didn’t yield much of interest, the command that I used follows:

Let’s investigate this wordpress site. Attempting to navigate to it provides some difficulties:

The site is attempting to redirect to derpnstink.local. In order to resolve this domain, let’s add it to our /etc/hosts file:

Navigating to 192.168.80.128/weblog/ should now be successful

Now that we can access the site, let’s use wpscan to gather some information about it (note that after the scan has started, we divert from the default by telling it to follow redirection):

Not only were we able to enumerate some users, but we’ve identified an arbitrary file upload vulnerability in one of the installed plugins! It’s an authenticated vulnerability, meaning that we will need some working credentials in order to exploit it.

Exploitation

WordPress Login

We know two users for WordPress: unclestinky and admin. admin sure sounds like a default user, so let’s start there. Guessing that the password might be the same as the username, we attempt to log in and find that we are successful!

File Upload Exploit To Get Shell

We have login credentials for what appears to be a limited account. This means that we can now use our authenticated arbitrary file upload vulnerability. There is a metasploit module for this vulnerability, which means that it should be pretty easy to execute.

Set the appropriate settings and then run the exploit. It may take a little bit to finish, but eventually we will be awarded with a meterpreter session.

Opening a shell on our target, let’s see if we can find some database credentials. WordPress installations tend to contain a set of credentials for the website’s database in the wp-config.php file. Let’s upgrade our basic shell into a TTY session and dump the contents of that file.

Success! We have another set of creds, these for MySQL.

phpMyAdmin

phpMyAdmin is a web interface for MySQL installations. Let’s see if our creds work here.

We’re in.

Let’s take a look around. The table wp_posts contains all of the posts, published and draft, for the web site. In this case, it also contains our second flag!

flag2(a7d355b26bda6bf1196ccffead0b2cf2b81f0a9de5b4876b44407f1dc07e51e6)

The WordPress database keeps users and password hashes in the wp_users table. Opening this table, we can get a hash for the unclestinky user.

Let’s see if we can use john and rockyou.txt to crack that hash.

After a bit, we have our password.

Escalation

The password for unclestinky is wedgie57. Moving back to our meterpreter shell, let’s see if we can escalate our privileges from a service account to a full user. Users often make the mistake of reusing the same passwords. Our target machine has a user named stinky, let’s see if his password is also wedgie57.

Another reminder of why good password practices are so important. We cracked stinky’s password in minutes and have now seized control of all of his accounts. Stinky’s home directory contains a lot of different directories and files. One of note is his ssh key. We can use this key to transition to a far more stable SSH session.

(Loving the South Park theme)

Let’s run a quick check to see if stinky is authorized to run sudo with sudo -l. This tells us all (if any) commands that the user is allowed to run via sudo.

That’s too bad. Looking in stinky’s Desktop folder, we find our third flag!

flag3(07f62b021771d3cf67e2e1faf18769cc5e5c119ad7d4d1847a11e11d6d5a7ecb)

Investigating the ftp directory, we find an interesting text file. It seems that there is a pcap file that captures another user’s account creation and login! Based on our experiences so far, there’s a good chance that this user reused his password on the target machine as well. This pcap is located in stinky’s Documents folder. Let’s transfer it to our machine so that we can open it with wireshark

Hunting through the pcap, eventually we stumble across TCP stream 37 which contains mrderp’s account creation.

It contains his password (twice, just to be safe) in plain text: derpderpderpderpderpderpderp.

Lateral Movement

Moving back to our SSH session, let’s try out those new creds and see if we can transfer to another user account.

Privilege Escalation

We’ve taken another user account. Let’s run that same sudo check, there’s no sense in trying complicated privilege escalations if our user account already has the requisite privileges.

Our user can run any command that is contained within the directory /home/mrderp/binaries/ and starts with the string derpy. Let’s make that directory and create a file in it.

In that file we’ll just put a simple command to open a new bash session. This session will be opened as the super user, meaning it should have root privileges.

Make it executable

We have root! Let’s check out the /root/ directory.

And we have our final flag and have completed the box!
flag4(49dca65f362fee401292ed7ada96f96295eab1e589c52e4e66bf4aedda715fdd)