This is a walkthrough on the Bulldog 1 vulnhub CTF by Nick Frichette After powering up the VM using VirtualBox or VMWare, you have to get the target’s IP:

Enumeration

To get familiar with the target services, I usually do an nmap scan on the top 1000 ports accessible:

And a UDP scan:

A complete nmap scan didn’t show any additional ports opened. At this point I could see the OpenSSH 7.2p2 daemon vulnerable to username enumeration Ports 80 and 8080 seem to have a web server, showing the following message an a picture of a bulldog on the front page:

Thank you for visiting Bulldog Industries' website, the world's number one purveyor of high quality English Bulldog photography! Unfortunately we are suspending business operations until further notice. On the first of this month, we were made aware of a breach of our technology systems. We are currently assessing the possibility that hackers may have gotten access to customer payment information. Do not be alarmed as we will be providing simple credit monitoring for all affected customers.

For more information on this, please see our public disclosure notice found below.

The public disclosure states that there was a breach in their systems and all of their staff was fired. The message is signed by Winston Churchy (CEO) (I usually write such stuff down in my notes to have on hand for a later use in a brute-force attack, and keeping in mind that the target seems to be vulnerable to a username enumeration this might be useful at a later stage) The first thing I go for is checking for a /robots.txt file and take a look at the source code. A robots.txt file exists on both web ports, with a message that they got owned. So far this is nothing useful. Going through the various pages on both ports didn’t seem to have anything useful so I it’s time to move to

Vulnerability Scan

I used the following commands to check for any vulnerabilities:

and on the second web server port (8080):

# dirb http://192.168.1.100:8080 (to disclose any hidden filders)

# nikto -h http://192.168.1.100:8080

as well as an additional nmap scan using the vuln NSE script.

A summary of the findings is as following: a /dev directory exists on both ports containning a link to a web shell, requiring some kind of authentication:

an /admin directory running the Django CMS:

So after reviewing all of the above pages source code, the following snippet can be noticed at the bottom of the http://192.168.1.100/dev/ page:

 

This seems like a nice list of password hashes, probably to be in use within the Django CMS system located at /admin. The first thing I did is to compare both the hashes from the source on both ports to avoid skipping any useful information. They were identical so I copied them to a file called “hashes” and removed the unnecessary data using the following sed expression:

 # sed -i -e 's/.*<!--\(.*\)-->.*/\1/' hashes

and then gave this list a shot using hashcat using the rockyou.txt wordlist (this is supposedly a Django hash, so you could issue the following command to see the required hashcat mode: hashcat -h | grep Django). In this case this happens to be a raw sha1 hash however (I used hash-identifier to and provided as an input one of the hashes to find this out), so the correct hashcat mode is 100 As a result two hashes were cracked:

# hashcat -m 100 hashes /usr/share/wordlists/rockyou.txt

At this point two passwords are cracked – the one for hash ddf45997a7e18a25ad5f5cf222da64814dd060d5 belonging to nick, and the one for hash d8b8dd5e7f000b8dea26ef8428caf38c04466b3e​ belonging to sarah, supposedly for database access. So credentials go as following: Back End: nick@bulldogindustries.com <! –ddf45997a7e18a25ad5f5cf222da64814dd060d5 –> Plain-text password: bulldog Database: sarah@bulldogindustries.com <! –d8b8dd5e7f000b8dea26ef8428caf38c04466b3e –> Plain-text password: bulldoglover A successful login using username “nick” : “bulldog”

As there isn’t anything useful within the admin panel, now checking back to the /dev/shell:

So we have a web shell with some command restrictions. Using a common command injection technique this can be easily bypassed in several ways:

• by appending a pipe “|” to an allowed command following another command:

by using the echo command, followed by a command execution interpreter like ` or $:

There may be other ways as well, but these are more than sufficient to try to get the webshell to a persistent one:

So what happens above is the connection gets closed due to the Ubuntu firewall. However, generating an msfvenom payload and executing it on the target seems to work:

Privilege Escalation

To escalate privileges* (remember the note on the web page about the company setting up a revolutionary AV?): *this is the easiest way, I believe there are a few more ways to do it on this box but I’ll be describing the most straight forward and obvious one below. After enumerating the cron jobs you’d notice an AVapplication.py python script configured to run as root each minute, having insecure permissions:

As shown below the file contents could be easily altered:

Then you just have to spawn a listener: