exploitation of windows kernel vulnerabilities (3): stealing access credentials

Recently, I just started to learn how to exploit windows kernel vulnerability, so I decided to share some of my learning experience in the form of blog.

In the previous part, I introduced how to build an environment:

Learning how to exploit windows kernel vulnerability (2): familiar with hevd

Learning how to exploit windows kernel vulnerability (2): familiar with hevd

The exploitation of windows kernel vulnerabilities (1): building an experimental environment

The exploitation of windows kernel vulnerabilities (1): building an experimental environment

Now we will be familiar with the payload used for privilege escalation.

The tool environment I used in this part is as follows:

The environment described in (1) and (2);

The environment described in (1) and (2);

NASM tools (download website: http://www.nasm.us/);

NASM tools (download website: http://www.nasm.us/);

HXD tools (https://mh-nexus.de/en/hxd/).

HXD tools (https://mh-nexus.de/en/hxd/).

In retrospect, our target is a vulnerable driver, to which we will submit a piece of buffer data from the user layer. In the previous part, we successfully triggered some crash scenarios by submitting malformed input data; however, our goal is not to destroy the execution process, but to control the execution process to redirect to our code by elaborately constructing input.

Generally, the transport payload is used to enhance the privileges of the attacker's application; this can be achieved by stealing the access credentials of the application with higher privileges (for the specific meaning of the access credentials, please refer to the relevant Wikipedia, https://en.wikipedia.org/wiki/access_token).

View access credentials

Each process running in the system has its own eprocess data structure, which encapsulates all the relevant data. For a complete definition of this structure, please refer to https://www.nirsoft.net/kernel'struct/vista/eprocess.html (eprocess data structure will have subtle differences between different versions of Windows operating system. For more information, please refer to https://www.geoffchappell.com/students/windows/km/ntoskrnl/structures/eprocess/index.htm). Some members of the eprocess structure, such as PEB (process environment block, process environment block, for specific meaning, please refer to Wikipedia, website: https://en.wikipedia.org/wiki/process-u environment block), can be accessed in user mode; others, such as the access credentials mentioned, can only be accessed in kernel mode. We can use the WinDbg debugger to view all domain members of the eprocess structure with the following command, and the result is shown in the following figure.

dt nt!_EPROCESS

It can be seen that the offset from the structure start position to the domain member token is 0xf8.

By using the following command, let's look at the details of the types contained in the credentials, as shown in the following figure.

dt nt!_EX_FAST_REF

Credentials are stored in a federation structure, ex fast ref, which has two domain members: refcnt (reference count) and value. We're only interested in substituting value; for application stability, it's best not to change the reference count.

Now, let's look at the credentials for some of the applications running on the debugged host. We can use the following command to list processes:

Dml_proc!

Example

The results are shown in the figure below.

The first column shown in the figure is the first address of the eprocess structure corresponding to a specific process.

Now, using the address in the figure, we can find more details about the selected process through the following command:

!process [address of EPROCESS]

Among the domain members shown in the figure below, we can see the access credentials.

We can also view the specific content of the voucher at a lower level by the following command:

dt nt!_EX_FAST_REF [address of EPROCESS] + [offset to the Token field]

The command execution results are shown in the following figure.

Or use the following command:

dd [address of EPROCESS] + [offset to the Token field]

The results are shown in the figure below.

From the above results, we can see that the! Process command will automatically apply the mask and filter the reference count from the display information; we can manually achieve the same function by using the mask with the right 3 bits set to zero, and with the help of the following expression evaluation:

?[token] & 0xFFFFFFF8

The results are shown in the figure below.

Stealing access credentials through the WinDbg debugger

As an exercise, we will run cmd.exe on the debugged host and use the WinDbg debugger on the debugged host to enhance its permissions.

First, list all processes; then, display and view the access credentials of the selected process system and CMD; then, copy the access credentials of the system process to the CMD process, in order to keep the reference count unchanged in this process, we need to use the corresponding mask; finally, cmd.exe is successfully authorized.

Load of stealing certificate

Now we need to inject code to reproduce the above process; of course, this is not easy, because we can no longer use the WinDbg debugger.

In the official hevd knowledge base, there are some complete examples of the payload used to steal credentials as part of the exploit code (https://github.com/hacksysteam/hacksysextreme vulnerabledriver / blob / Master / exploit / payloads. C).

The purpose of all the payloads contained in the code is the same, that is, to steal access credentials; however, we can see that there is a little difference between them in order to adapt to specific vulnerabilities. Their code is mostly the same, with only different endings (this part is called the "kernel recovery picker"); this part of the code is used for necessary cleanup so that the application will not crash after the load part is executed and returned.

Next, let's look at a general version (https://github.com/hacksysteam/hacksysextreme vulnerabledriver/blob/master/expand/payloads.cාl186). The specific code is shown in the figure below.

First, we have to find the beginning of the eprocess structure. It's easy to use the WinDbg debugger, a command can display this information; now, we need to find the starting position of this structure by ourselves from other domains.

We use the kpcr (kernel processor control region) structure as the starting point, and the FS register on the 32-bit windows operating system (GS register on the 64 bit system) points to the structure.

The code described in the figure above takes advantage of the relationship between the following structures:

KPCR（PrcbData）->KPRCB（CurrentThread）->KTHREAD（ApcState）->KAPC_STATE（Process）->KPROCESS

Kprocess structure is the first domain of eprocess structure, as shown in the figure below; therefore, by finding it, we finally find the starting position of eprocess structure.

After the eprocess structure of the current process is found, we will use another domain to find the eprocess structure of the system process, as shown in the following figure.

List? Entry is a member type of a two-way linked list that connects all running processes together. The specific definition of this structure is shown in the figure below.

Its domain member Flink points to the list entry domain of another process; therefore, by indexing and replacing the offset of the domain member, we can get a pointer to the eprocess structure of another process.

Then, we need to obtain the PID value (corresponding to the uniqueprocessid of the domain member) and compare it with the unique PID of the system process; the position of the PID value in the eprocess structure is shown in the figure.

The code fragment corresponding to the above process in vulnerability exploitation is shown in the following figure.

After obtaining the eprocess structure of our process and system process, we can copy the credentials from one party to the other. In the following code, the reference count is not preserved (as shown in the following figure).

It is very convenient to use the WinDbg debugger to view the offset of a specific domain member. We can use the following command to display the specific definition of the specified structure:

dt nt!<structure name>

For example:

DT NT! _KPCR

The results are shown in the figure below.

Then execute the following command:

dt nt!_KPRCB

The results are shown in the figure below.

Therefore, it can be calculated that the offset of_kthread is 0x120 + 0x004 = 0x124.

The above offsets are shown in the code snippet, as shown in the following figure.

Writing load

As demonstrated by the exploit code in hevd (https://github.com/hacksysteam/hacksysextremulvalenabledriver/blob/master/exploit/payloads.cාl63), we can use embedded assembly (encapsulated in C / C + + code) to write load code.

In this case, however, the compiler will process our code; as shown in the figure below, extra prefixes and suffixes are added before and after the code.

This is the reason why we remove redundant DWORD type data from the stack by adding 12 (0xc) bytes to the stack pointer (ESP). The specific code (https://github.com/hacksysteam/hacksysextremullevulnerabledriver / blob / Master / expand / payloads. C × L94) is shown in the following figure.

If you want to avoid trouble, you can declare the function as a naked code type (for more details, please refer to the website: https://msdn.microsoft.com/en-us/library/5ekezyy2.aspx); this can be achieved by adding a special declaration before the function, such as the following code (website: https://github.com/hashezade/wke_exceptions / blob / Master / stackoverflow_expl / payload. H#l16 ):

__declspec(naked) VOID TokenStealingPayloadWin7()

Another option is to compile its assembly code externally, such as using the NASM compiler; after that, we can export the contents of the compilation buffer to a hexadecimal string.

As an exercise, we will also slightly modify the above load code to keep the reference times unchanged. The specific code (https://github.com/hashezade/wke'exercises/blob/master/stackeoverflow'expl / shellc. ASM) is shown in the following figure.

Compile the code using the following command:

nasm.exe shellc.asm

Then, we use the hex editor to open the compilation results and copy the bytes; some hex editors (such as HXD) even support copying the data in the array format of a specific programming language, as shown in the following figure.

In my example of stack overflow vulnerability exploitation for hevd, you can find embedded and externally compiled load codes. The specific code address is https://github.com/hashezade/wke'exceptions/tree/master/stackoverflow'expl. The compiled code address is https://drive.google.com/open? Id = 0bzb5kqfoxkiswtjos2vzz0jiu3c.

The details of exploiting this vulnerability will be covered in the next section, as well as the osanda and Sam articles mentioned in the appendix.

This article is compiled by kanxue translation group, from hasherzade's 1001 nights

Reprint please indicate from the snow watching Forum

If you like it, don't forget to like it!

Hacking Book | Free Online Hacking Learning