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.
192.168.80.128 00:0c:29:ea:68:2f VMware, Inc.
[...snip...]
Our target is located at 192.168.80.128. Our next step is to determine what ports are open using nmap.
Nmap scan report for 192.168.80.128
Host is up (0.0021s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.2
22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 12:4e:f8:6e:7b:6c:c6:d8:7c:d8:29:77:d1:0b:eb:72 (DSA)
| 2048 72:c5:1c:5f:81:7b:dd:1a:fb:2e:59:67:fe:a6:91:2f (RSA)
| 256 06:77:0f:4b:96:0a:3a:2c:3b:f0:8c:2b:57:b5:97:bc (ECDSA)
|_ 256 28:e8:ed:7c:60:7f:19:6c:e3:24:79:31:ca:ab:5d:2d (EdDSA)
80/tcp open http Apache httpd 2.4.7 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 2 disallowed entries
|_/php/ /temporary/
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: DeRPnStiNK
[...snip...]
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:
==> DIRECTORY: http://192.168.80.128/weblog/
[...snip...]
==> DIRECTORY: http://192.168.80.128/php/phpmyadmin/
[...snip...]
==> DIRECTORY: http://192.168.80.128/weblog/wp-admin/
==> DIRECTORY: http://192.168.80.128/weblog/wp-content/
==> DIRECTORY: http://192.168.80.128/weblog/wp-includes/
[...snip...]
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):
[i] The remote host tried to redirect to: http://derpnstink.local/weblog/
[?] Do you want follow the redirection ? [Y]es [N]o [A]bort, default: [N]y
[+] URL: http://derpnstink.local/weblog/
[+] Started: Mon Mar 26 15:05:29 2018
[...snip...]
[!] Title: Slideshow Gallery < 1.4.7 Arbitrary File Upload
Reference: https://wpvulndb.com/vulnerabilities/7532
Reference: http://seclists.org/bugtraq/2014/Sep/1
Reference: http://packetstormsecurity.com/files/131526/
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5460
Reference: https://www.rapid7.com/db/modules/exploit/unix/webapp/wp_slideshowgallery_upload
Reference: https://www.exploit-db.com/exploits/34681/
Reference: https://www.exploit-db.com/exploits/34514/
[i] Fixed in: 1.4.7
[+] Enumerating usernames ...
[+] Identified the following 2 user/s:
+----+-------------+---------------------------------+
| Id | Login | Name |
+----+-------------+---------------------------------+
| 1 | unclestinky | 404 Not |
| 2 | admin | admin – DeRPnStiNK Professional |
+----+-------------+---------------------------------+
[...snip...]
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.
pwd
cd /var/www/html/weblog
cat wp-config.php
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.
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
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)