Attack Method: Leaktests
Description: Leaktests are programs that are designed to test the security and rule configuration of firewall programs. Typically this is achieved by connecting to a remote website and transmitting a simple "hello" message - if the message gets out, then leaktest was successful in proving that the firewall isn't protecting against that attack.

SOLUTION: While it is typically up to firewalls to protect themselves, the added security layer that Process Guard provides actually blocks six of the thirteen available leaktests (including some that affect ALL personal firewalls, and that's just with Process Guard's default configuration plus the four general protection options turned on) - not bad for a program that wasn't designed for leaktest blocking! This is just one of the additional benefits that Process Guard offers.

CASE EXAMPLES
All leaktests were executed on a Windows XP workstation with Internet Explorer running, no firewalls, and Process Guard with just the default wizard-generated configuration.
All leaktests were obtained from Firewall Leaktester.com

Name: Copycat
Description: One of the most successful leaktests, Copycat is one of only two leaktests that are known to defeat ALL personal firewalls. Copycat uses direct code injection (without creating an additional thread) into a web browser to prevent it being detected by a firewall.

Process Guard is easily able to block Copycat by preventing it from obtaining the required WRITE and SET INFO access privileges, which it needs for code injection. We can see here that when we run Copycat on a system protected by Process Guard it simply says "Process memory is not accessible":


Examining the Process Guard window we can clearly see the leaktest attack being blocked:

Name: Thermite
Description: Also a very successful leaktest, there is only one personal firewall (Look'n'Stop) that Thermite doesn't work against - all other firewalls remain vulnerable. Unlike other code-injecting leaktests that inject code into other processes via a DLL, Thermite actually injects code directly into the target process and creates a new thread in that process to activate the newly-injected code, making it extremely difficult for firewalls to detect (which is the reason why currently only one firewall can prevent this attack).

Process Guard is easily able to block Thermite by preventing it from obtaining the required WRITE and SET INFO access privileges, which it needs for code injection. We can see here that when we run Thermite on a system protected by Process Guard it simply displays two error messages:


Examining the Process Guard window we can clearly see the leaktest attack being blocked:

Name: Atelier Web Firewall Tester v3.0
Description: This program has six different leak tests, three of which (#2, #3, and #4) are all blocked by Process Guard.

These three tests are:
#2 - Creates a thread on a loaded copy of the default browser. Old trick, but most firewalls still fail.
#3 - Creates a thread on Windows Explorer. Another old trick, but most firewalls still fail.
#4 - Attempts to load a copy of the default browser from within Windows Explorer and patch it in memory before execution. Defeats firewalls which require authorization for an application to load another one, where Windows Explorer is normal authorized.

Examining the Process Guard window we can clearly see the three leaktest attacks being blocked:

Name: Firehole
Description: Firehole uses the default web browser to transmit data to a remote host. To do this, it calls the SetWindowsHookEx function to load a DLL file (with interception capabilities) into all processes that have the user32.dll library loaded (the majority of processes on your system will have this library loaded). When the DLL detects that it has been injected into the Internet Explorer process, it attempts to connect out to the Internet. Because most people have a rule in their firewalls that allows Internet Explorer internet access, Firehole is often successful in accessing the Internet to "leak data".

Process Guard is able to easily block this attack by blocking the creation of the hook (as Process Guard essentially secures the SetWindowsHookEx function). Because the hook creation fails, Firehole is unable to load its DLL into any processes, as can be seen by the failure message:


Examining the Process Guard window we can clearly see the leaktest attack being blocked:

Name: PCAudit
Description: PCAudit uses DLL injection courtesy of the SetWindowsHookEx function in a similar way to the Firehole program, to load its DLL into other processes that use user32.dll.

When we try to run PCAudit on a system being protected by Process Guard we see the following error message from PCAudit:


Examining the Process Guard window we can clearly see the leaktest attack being blocked:

Name: PCAudit v2
Description: PCAudit v2 is very similar to the original PCAudit, but uses a slightly different method to load its DLL.

Again, when we try to run PCAudit 2 on a system being protected by Process Guard we see the following error message from PCAudit 2:

Examining the Process Guard window we can clearly see the leaktest attack being blocked:

Related websites:
 TooLeaky: Why your firewall sucks :-)
 Robin Keir: Firehole
 Firewall Leaktester.com