RE: Bypassing Personal Firewalls

From: Drew Copley (dcopleyat_private)
Date: Fri Feb 21 2003 - 15:31:30 PST

  • Next message: Oliver Lavery: "RE: Bypassing Personal Firewalls"

    > -----Original Message-----
    > From: Oliver Lavery [mailto:oliver.laveryat_private] 
    > Sent: Friday, February 21, 2003 3:23 PM
    > To: 'Drew Copley'; bugtraqat_private
    > 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
    > 
    > 
    > 
    



    This archive was generated by hypermail 2b30 : Fri Feb 21 2003 - 16:09:49 PST