CTF Walkthrough – DerpNStink:1

Hi all! Welcome to another CTF Walkthrough guide, today we’re going to be tackling the DerpnStink:1 CTF available from Vulnhub created by Bryan Smith. This CTF isn’t too bad, it has examples of why you should keep plugins up to date and more. There’s 4 flags to capture and you need to get root in order to win. You also don’t need to decrypt the flags as they hold no value.  If you don’t want to read through this guide then feel free to watch my full video guide located at the bottom of this article. Also if you want to stalk me on social media feel free! My twitter is @Jackk1337 / @JackkTutorials, Instagram is Jackk1337, Facebook is JackkTutorials & finally my YouTube is JackkTutorials. Anyway… Lets begin…

To start with it’s a case of finding the IP Address of the target machine, luckily this isn’t difficult at all with a simple Nmap scan to find our target and running services. Issuing the command ‘nmap -sS 192.168.170.0/24′ scans my network and finds all devices and services. Considering Kali & this CTF is the only thing on the network this command is fine. Here are the results…

[email protected]:~# nmap -sS 192.168.170.0/24

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-28 17:49 BST
Nmap scan report for 192.168.170.2
Host is up (0.00013s latency).
All 1000 scanned ports on 192.168.170.2 are closed
MAC Address: 00:50:56:ED:84:CE (VMware)

Nmap scan report for 192.168.170.131
Host is up (0.00038s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
MAC Address: 00:0C:29:03:73:E9 (VMware)

Nice and easy, we have 3 services to play with… Lets take a look at the HTTP service first. So browsing to the 192.168.170.131 IP Address gives us this:

My general rule of thumb when it comes to CTF websites is that if the creator has designed some kind of webpage then I will inspect the source code and see if any flags are hidden there. If it is some kind of CRM then I don’t bother. So in this case I inspected the source code to see if I could find a flag. Hitting F12 brings up the Developer Console and I had a look through the simple source code and found the first flag hidden in a bunch of  nested <div> tags.

So we have our first flag:

flag1(52E37291AEDF6A46D7D0BB8A6312F4F9F1AA4975C248C3F0E008CBA09D6E9166)

 

So I also checked our the ‘robots.txt’ file but there was nothing of use there. So I loaded up Dirbuster and gave the URL a quick scan to find some folders and files. After a couple of seconds I had some results:

So I found some directories here. /webnotes had nothing of interest in it, however /weblog gave me a DNS error as it was trying to resolve derpnstink.local. Easy enough to sort by just adding the domain to my hosts file and trying again… And what do you know… WordPress!

After a quick look around I found nothing of interest, so it was time to start getting access to the webserver via wordpress. So I headed over to /wp-login.php and guessed the login credentials of admin:admin… But wait! The admin account isn’t an admin account! All I have access to is the slideshow… But why would I only have access to the slideshow… Lets load up wpscan and see if there is an issue here.

You can see from the screenshot that there is a Arbitrary File Upload vulnerability which is going to allow me to upload a file to server… Like a webshell… Let’s do it. So I researched the vulnerability on exploit-db and found a python script that can upload a webshell to the webserver with just the admin credentials. So I downloaded that and gave it a go (The script is here and details about the vulnerability is here).

There’s a lot going on in the above screenshot so I’ll explain. On the left I have a msfconsole session running waiting for the connection from the webserver. Top right I’ve generated a php shell using msfvenom and on the bottom right I am using the script from exploit-db to upload that shell to the webserver. If you look at the msfconsole terminal you can see that browsing to that link has given me shell access. So that’s good!

So now that I have shell access it’s time to have a look around. What I’ve found is that in the /home directory there are two other directories called /mrderp & /stinky. But www-data cannot access these. Also there is now privilege issues after checking with unix-privesc-check. Also the /root dir is off limits. So I decided to go back to the /var/www/html folder and take a look in the wp-config.php file (The configuration file for WordPress). My plan was to check the database and bruteforce the true WordPress admin account.

So the above screenshot shows that I have taken the login details from the wp-config.php file and used them to view the data in the wp_users table where wordpress users are stored. My plan is to bruteforce the hash with hashcat to get the password and see if that password can get me anywhere else. So I take the hash, load it into hashcat and proceed to crack it.

[email protected]:~# hashcat -a 0 -m 400 hash.hash /usr/share/wordlists/rockyou.txt

This command specifies to do a wordlist attack on the hash file in ‘hash.hash’ using the ‘rockyou.txt’ wordlist. The hash type is 400, also known as phppass(WordPress)

After not too long I found the password to be ‘wedgie57’. So lets go find some user accounts on this linux box by downloading the /etc/passwd file and taking a peak. Inside there we find…

stinky:x:1001:1001:Uncle Stinky,,,:/home/stinky:/bin/bash
ftp:x:118:126:ftp daemon,,,:/srv/ftp:/bin/false
mrderp:x:1000:1000:Mr. Derp,,,:/home/mrderp:/bin/bash

Alright so we go two user accounts here. Stinky & MrDerp. The true admin account of the WordPress site was a user called ‘unclestinky’ (Refer to table dump screenshot) so maybe the same password was used twice. Lets try SSH…

Alright so we’re not allowed in at all. Cool… What about mrderp’s account?

Mrderp accounts allows us to use a password but I couldn’t guess it or bruteforce it. What about ftp? We haven’t looked at that yet…

That worked! The credentials stinky:wedgie57 worked to login to this account. So I had a look around and found some files of value. That was a conversation about a network packet capture that could be saved somewhere on this linux box, and also a RSA private key.. Probably for the SSH account. Nothing else on this box, so I took the key.txt file and left the FTP account and returned to the terminal to try attempt another login with the [email protected] account but passing in the key file.

And there we go, we have SSH access to stinky’s account. So I had another look around here and found the network capture that mrderp & stinky were talking about. Opening it up in wireshark I filtered the traffic to HTTP and only looked at the wp-login POST data to see what login attempt was made.

The first login is by unclestinky into wordpress. We already knew his credentials…

The second login is mrderp, assuming that he’s used the same password on his account for SSH we can probably login. So I gave it a go…

With that password I was able to login.

The next bit took a bit of digging, but essentially there is a helpdesk log that has a pastebin url in it. Visiting the pastebin link gave this result:

mrderp ALL=(ALL) /home/mrderp/binaries/derpy*

What this shows is the commands that run as root using mrderp’s account. So I created a .sh file in a new directory called binaries with the following:

!#bin/bash

bash-i

And when I run the command

sudo /binaries/derpy.sh

it escalates us to root!

And there we go, we are root! Not too bad… Let’s talk about the flags.

 

flag1(52E37291AEDF6A46D7D0BB8A6312F4F9F1AA4975C248C3F0E008CBA09D6E9166)

This was found a nested <div> tag on the main webpage.

flag2(a7d355b26bda6bf1196ccffead0b2cf2b81f0a9de5b4876b44407f1dc07e51e6)

This was found on the true admin control panel on wordpress when logging in as unclestinky

flag3(07f62b021771d3cf67e2e1faf18769cc5e5c119ad7d4d1847a11e11d6d5a7ecb)

This was found on the Desktop of stinky’s user account

flag4(49dca65f362fee401292ed7ada96f96295eab1e589c52e4e66bf4aedda715fdd)

This was found on the Desktop of root’s account.

 

So there you go! 4 flags and root on this CTF. I hope you enjoyed the walkthrough! More to come… Below is my video of the walkthrough!

CTF Walkthrough – Basic Pentesting:1

Hey! It’s been a while since I’ve played around with any pentesting tools or capture-the-flags so I thought I might as well jump straight back in with a super basic CTF just to get used to the methodology again.

This CTF is named “Basic Pentesting:1″ by Josiah Pierce. It’s a super easy boot2root and wont take very long to solve. It involves a bit of service discovery, bruteforce, reverse shells and privilege escalation.

If you don’t want to read this post, skip to the bottom where you’ll find the video 🙂 Don’t forget you can stalk me on social media: Twitter: @Jackk1337/@JackkTutorials Instagram: @Jackk1337 YouTube: JackkTutorials 

Lets begin….

 

To start with I booted up the machine and got the IP Address from the home screen (thanks Ubuntu).

And then I can launch a simple nmap scan just to identify some services that are running on the target machine

nmap -sS 192.168.110.135

Which gave these 3 results:

[email protected]:~# nmap -sS 192.168.110.135

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-04 12:08 GMT
Nmap scan report for vtcsec (192.168.110.135)
Host is up (0.000079s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
MAC Address: 00:0C:2Upload Files9:AE:35:F3 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

So what this tells me (at a glance) is that there is 3 services running on this machine: FTP, SSH & HTTP. So with this information I headed over to http://192.168.110.135 which gave me this page:

So from here I checked to see if there was a /admin dir or /login.php file or /robots.txt but there wasn’t. There also wasn’t anything hidden in the ‘view source’ so I loaded up dibuster to find some more folders for us.

Here I’m just using a dirbuster attack with a small wordlist to find some more folders & files.

After not very long, I discovered what looks like a wordpress installation in a dir called “Secret”.

 

 

You can see that when it’s loaded, things don’t look right… Upon inspection it looks like content is coming from a domain called “http://vtcsec” so I added this to my hosts file (sudo nano /etc/hosts) and mapped vtcsec to 192.168.110.135. When I refresh to page things start to load much better.

From here I went to the 192.168.110.135/secret/wp-login.php and attempted to login. I used the username “admin” and a random password and I got the following message:

ERROR: The password you entered for thhe username admin is incorrect.

What this tells me is that ‘admin’ is a valid user in this database. So then I just tried the credentials “admin:admin” and what do you know… It worked.

So now that we have admin access to the wordpress control panel we can upload a reverse_tcp payload via the plugin manager. The payload I’m using is “malicious-wordpress-plugin” which is here 

This uses meterpreter to create a simple php file that can be uploaded to the wordpress site and a connection to be established.

So here I have my “malicious.zip” file which will be uploaded to the wordpress site, and the terminal is showing meterpreter waiting for a connection. So I upload that zip file to the wordpress site, activate the plugin and then navigate to “http://vtcsec/secret/wp-content/plugins/malicous/wetw0rk_maybe.php” which initiates a connection to my kali box.

So now we are in the system as “www-data”. Now all we need to do is escalate our privileges to root. So I’m going to use a script called “unix-privesc-check” from pentestmonkey which is a really powerful script that can check for simple privilege escalation vectors on a Unix system. You can get that here

So I simply upload that file to the box using meterpreter upload function. Then I just drop into a proper shell using this command

python -c ‘import pty; pty.spawn(“/bin/bash”)’

And then I can make it executable with this command:

chmod +x unix-privesc-check

And then run it

./unix-privesc-check standard > output.txt

Once that’s ran I’m going to download the output and then analyze it to see what it hides. Inside the file is the following entry:

Checking if anyone except root can change /etc/passwd
WARNING: /etc/passwd is a critical config file. World write is set for /etc/passwd

What this tells me is that I can modify roots password without being root. So I download the passwd file to my kali machine and change the password like so…

By default, the etc/passwd file contains this entry:

root:x:0:0:root:/root:/bin/bash

Using a command called openssl I can generate a new password hash and enter it in place of ‘x’.

[email protected]:~# openssl passwd -1
Password:
Verifying – Password:
$1$K9K.WsMy$yic9pqsNFKaxIQePGI9oV1

And then I enter that hash into the passwd file and re-upload it. Then simply login as root:

[email protected]:/var/www/html/secret/wp-content/plugins/malicous$ su root -l
su root -l
Password: pass

[email protected]:~#

And there you go… boot2root success!

Also bonus points… in the /var/www/html/secret/wp-config.php file contains the root credentials for the wordpress mysql database, which could of been another attack vector.

So I hope you liked this writeup, the video is just below! A very simple boot2root which can be completed pretty quickly with no nasty tricks, perfect for if you’re just starting out or just coming back like I am.