Granny
01 Nov 2020As always I start by running my nmap scripts to find open ports and general information about them.
Only port 80 is open. I run a quick gobuster and get no hits. Visiting the ip itself just shows the defualt “Under Construction” page for IIS.
Looking back at my nmap scan I see this is a webdav server. Immedietly I use davtest to see what files I can put and execute on the server.
Turns out theres quite a bit. Just to verify I check davtests text file path to make sure the file really was placed.
So now I know I can put and run files on the server. Only problem is this is a Microsoft Server so I’m only interested in placing .aspx files which, according to
davtest, can’t be placed. However refering back to my nmap scan once again I see in the Public Options field for webdav includes the MOVE option. Using move I
could potentially MOVE a .txt file to a .aspx file.
Working under this assumption I first create a .aspx shell using msfvenom.
Then I’ll PUT the file on the server as a text file.\
After verifying that the file was placed correctly and exists on the server I use the MOVE option to change the .txt file to a .aspx file.
Using curl once again to run the shell.
Checking my netcat listener shows I recieved a shell as the network service account.
Now I’m on the box and the first thing I always do is run a systeminfo to get basic information of the machine.
The machine is running Windows Server 2003, a very old server. Becuase of this I’ll run the systeminfo results through windows-exploit-suggester and see if any potential kernel exploits come up.
And here I have a whole list of them to try! I’m interested in privelege escalation exploits with the critical flag as these have the best chance of working.
I’ll start with MS14-058
Now I have an kernel exploit executible to try against this machine. Only problme is getting this exe over to the victim.
Since this is an older box it doesn’t have wget or powershell installed, my two favorite methods for transferring files. However we can still use smb
to transfer files.
First I’ll spin up an smb share on my kali machine using the python module ‘smbserver.py’ from impacket.
Now I can copy my exe to the victim machine. But first I need to find an appropiate spot to write to on the machine. Since my account is ‘network service’ it’s a pretty safe bet that I can write to “C:\Inetpub\wwwroot” but I’ll create a new file anyway to verify that.
Congrats, now I have a place to copy my exe too.
Using copy to grab the file from my smb share I save it to the directory.
Unfortunately this is a dud.
After repeating this process for several more kernel exploits I realized I needed to go back and rethink my strategy.
Heading back to the box I enurmerated further and one thing caught my eye after checking user privs.
This user had the SEImpersonatePrivilege enabled. This could possibly allow the churrasco exploit to work.
churrasco here.
The churrasco exploit performs token kidnapping to impersonate the system accounts token. The exploit requires netcat to be on the victims machine as well
since it will use netcat to connect back to my machine as a system session using a kidnapped system token.
Churrasco is an old and patched exploit but it works on older Windows OS’s… perfect for Granny.\
Once again I’ll use my smb server to send both churrasco.exe and nc.exe to the victim.
Now we run churrasco using -d to specify the command, giving the absolute path to nc.exe, specifying nc to send cmd.exe and giving the ip and port to connect too.
Finally I have recieved a system shell on my listener.