RE: Bypassing Personal Firewalls

["Drew Copley" <dcopley () eeye com>]

> -----Original Message-----
> From: Oliver Lavery [mailto:oliver.lavery () sympatico ca] 
> Sent: Friday, February 21, 2003 3:23 PM
> To: 'Drew Copley'; bugtraq () securityfocus com
> Subject: RE: Bypassing Personal Firewalls
>
>
> > (Sidenote: a number of previous apps used to test PFWs or Application
> Firewalls -- 
> > http://www.pcflank.com/art21.htm )
>
>       Yes, these are great tests. Most PFWs block them all now.

I believe TooLeaky and Firehole remain unfixed on some firewalls.

Too leaky apparently just runs IE with a url cmd argument.

Firewall uses the messy way of hooking: SetWindowsHookEx 



> > There are a number of ways to do this, you use the more 
> popular method 
> > of
> openprocess and 
> > writeprocess memory. However, there is a limit to the number of api 
> > calls
> which implement this. 
> > Ultimately, this kind of code needs to be blocked, first, at 
> the NT API
> level... Such blocking 
> > should use the same method as blocking the network calls, 
> ie, "Do you 
> > want
> to allow this 
> > application to ..."
>
>       Yes. Before we go prompting users ever time someone 
> calls CreateFile, though, there are much simpler measures. 
> One of them would make OpenProcess require a priviledge of 
> some sort (see below).
>
> > Most commonly, this would be used with writeprocess memory. 
> > Createremotethread would need to be blocked in this manner.
> Postremotethreadmessage. 
> > PostThreadMessage. Are some of the more dangerous calls, in this 
> > context.
>
>       You'll notice that all of these calls require a handle 
> returned by OpenProcess (hProcess in my code).
>
> > After that, you are probably talking about having to do somesort of
> signature analysis at the 
> > binary level.
>
>       MD5 of the binary memory image! This is probably 
> feasible, but good god it would resource intensive.

Any such method remains limited. You are in the openrange here. 

Here is a relevant and interesting paper:

http://www.cs.washington.edu/homes/saurabh/papers/oh.pdf

"Abstract. We describe a novel software verification primitive called
Oblivious Hashing. Unlike previous techniques that mainly verify the
static shape of code, this primitive allows implicit computation of a
hash value based on the actual execution (i.e., space-time history of
computation) of the code. We also describe its applications in local
software tamper resistance and remote code authentication."


> > OpenProcess does require seDebugPrivileges, I believe.
>
>       No, and this is very much the point. According to MS docs:
> SeDebugPrivilege:
> Determines which users can attach a debugger to any process. 
> This privilege provides powerful access to sensitive and 
> critical operating system components.
>
>       This only prevents users from using OpenProcess on 
> system processes (winlogon.exe etc.). There need to be 
> tighter restrictions on the use of OpenProcess.

Ah, that's right, remember now.

> Cheers,
> ~ol