Blog 1 - Windows Vulnerability Research – Debugging, intro Secure Channel

Disclaimer: This blog series won't be very technical. It is intended to be easy to understand and follow. Like most of my blogs, I have no reason to be peacocking with technical jargon like all the infosec losers.

Overview and donation information: https://weirdquadratic.blogspot.com/p/blog-overview.html

To the reader: Feel free to share anything I write with those who need it. And be sure to make local copies as I am sure it is a matter of time until this blog will be taken down as well.

In the previous blog, we set up two Virtual Machines in Hyper-V and created a domain. Next, we need introspection. We need to be able to see what happens inside these machines.

A large majority of cryptographic components is handled in lsass.exe (Local Authority Subsystem Service). These components also tend to be full of complexity and are especially interesting to an attacker.

The lsass.exe process runs at SYSTEM-level privileges. Meaning any take-over of this process results in the take-over of the machine, and possibly even the entire domain depending on the target.

There is two ways we can debug lsass.exe, one is through a kernel debugger, and another one is through a remote process server.

Disabling exploit mitigations

For debugging userland code, a userland debugger is almost always preferred. However, lsass.exe has a lot of exploit protections as it is a very popular target for privilege escalation which can make attaching a userland debugger troublesome.

To get a userland debugger attached, we must first disable all of the exploit mitigations for lsass.exe. We can enable them later when developing an exploit.

In the windows search bar, type “exploit protection” and open the exploit protection menu. Next go to “program settings” and select “Add program to customize” and then “Add program by name” and enter “lsass.exe”.

Once that is done, enable “override system settings” for each exploit protection and make sure they are indicated as “off”.

Once that is done, reboot the machine.

Downloading a debugger

Download Windbg on your host and on the Windows Server virtual machine.

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/

Alternatively from an elevated terminal run:

winget install Microsoft.WinDbg

Launching a process server and connecting

From an elevated terminal in the Windows Server virtual machine (after installing Windbg)

Navigate to the following folder:

C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps\Microsoft.WinDbg_8wekyb3d8bbwe

Then run the following command:

dbgsrvX64.exe -t tcp:port=1234

On your host computer open Windbg and go to “connect to process server” and enter the following connection string: tcp:server=<ip>,port=1234 (where the ip is the ip of your Windows Server virtual machine)

If that doesn't work you may have to disable firewall.

After connecting you should see the following:

Next select “Attach to process” and go ahead and attach to lsass.exe. The PID (Process ID) should match the PID of lass.exe on your Windows Server virtual machine if the above steps completed succesfully.

If all went well we will be greeted by the following:

Cheers, we now have achieved introspection into lass.exe.

Press the "Go" button or type g to continue execution.

Intro to Secure Channel

Secure Channel, located in schannel.dll, is Microsoft's implementation for the TLS protocol. While Microsoft Edge (browser) uses a modified version of OpenSsl to handle TLS connections from the client side, a lot of enterprise features use Secure Channel instead.

Of-course, this is a lot of fancy words, but what does it do?

There are two types of cryptography, symmetric cryptography and asymmetric cryptography.

Symmetric cryptography is by far the fastest. However it relies on the fact that both parties communicating with each other have knowledge of the same secret key to encrypt and decrypt traffic.

To make sure both parties have the same secret key, asymmetric cryptography was invented. As we cannot simply share a secret key over plain text since anything that gets transmitted over a network, or the internet, can be intercepted by an adversary.

Asymmetric cryptography basically establishes a “secure channel” over which we can transmit symmetric keys safely.

Encrypting and decrypting using symmetric keys is usually referred to as “bulk encryption/decryption”, and this is the preferred method as it is by far the fastest. Hence to achieve this, we must always leverage some form of asymmetric cryptography first to distribute shared keys. And that is what schannel.dll (literally called Secure Channel) is for.

While the actual details are far more complex, you should always make simple abstractions mentally. Details you can always read up about later when needed, as long as you understand things abstractly at a high-level. Abstractions are the mind's greatest tool.

Setting up IIS with TLS support

A simply way to gain access to the Secure Channel component is by installing IIS and enabling TLS support.

From an elevated powershell terminal enter:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Next in search bar type “internet information services” and open the IIS manager.

On the left-hand pane go to <computer name> and select Server Certificates. Then on the right-hand pane, select “Create Self-signed certificate”

Follow the instructions to create a self-signed certificate and select “web hosting” as the certificate store.

On the left-hand pane go to <computer name>->sites ->Default Web Site and then in the right-hand pane select “bindings”.

Next select “Add...” and as type select “https” and set the SSL certificate to the one we just created.

Installing wireshark

To debug network traffic, wireshark is a great tool. If we end up handcrafting packets this lets us verify easily if they are crafted correctly and are correctly arriving at the intended target.

Download and install Wireshark on the Windows Server Virtual Machine.

https://www.wireshark.org/download.html

Triggering Secure Channel from an attacker machine

On the windows 10 Enterprise machine which we domain joined in Blog 0. Login to the domain (Note: Not required, will work without domain joining as well) by preceding the username by your domain name, in my case: BEAR\Administrator.

Download the following python script: https://github.com/BigPolarBear1/Blog/blob/main/Blog%201/tls_test.py

And change the ip at the top of the script to the ip of the Windows Server Virtual Machine.

In addition, grab python v3 from the Microsoft store (I'm using v3.13) so that we can actually execute the script.

Next on the Windows Server machine open Wireshark and begin recording traffic on your main network adapter and filter by src ip using the following filter: ip.src == 172.29.229.175, where the source ip is the ip of the windows enterprise machine (client) on which we just downloaded the python script

Run the python script on the Windows Enterprise machine:

python tls_test.py

In wireshark you should see a bunch of “TLS client hellos” appearing.

Placing a breakpoint in Secure Channel

In future blogs we will try to use the free version of Binary Ninja to figure entry points in our code.

First break into the debugger and type “ld *” to make sure we load all the symbols.

Next type “lm” this will show all the available modules in lsass.exe. This is very useful for piecing together what code we may be able to attack in a certain process. Find "Schannel" in the list.

Alternatively type “lmDvmschannel”

Once you found schannel, select "functions" to display all available functions for which we have public symbols. Or use the following command “x /D /f schannel!*”

One of the function names will be: schannel!CSsl3TlsServerContext::ProcessHandshake

For TLS 1.2 traffic, this will be responsible for routing TLS 1.2 handshake messages to the correct functions, depending on the stage we are at in the handshake process.

Place a breakpoint:

bp schannel!CSsl3TlsServerContext::ProcessHandshake

If we then re-run our python script and all is set-up correctly up until this point, we should get a hit on the breakpoint.

Together with blog 0, this covers all the basics. In the next blog we will begin to focus on finding bugs and exploring all the code we can reach in lsass.exe.