RE: Bypassing Personal Firewalls

From: Drew Copley (dcopleyat_private)
Date: Fri Feb 21 2003 - 15:09:54 PST

  • Next message: Drew Copley: "RE: Bypassing Personal Firewalls"

    > -----Original Message-----
    > From: xenophi1e [mailto:oliver.laveryat_private]
    > Sent: Friday, February 21, 2003 1:34 PM
    > To: bugtraqat_private
    > Subject: Bypassing Personal Firewalls
    > 
    > 
    <snip>
    
    > Here's a code snippet that injects code directly into a
    > running process 
    > 
    > without the need for a DLL etc. I believe that it demonstrates that
    > 
    > process boundaries under NT mean very little within the context of a
    > 
    > given UID.
    
    <snip>
    
    
    > I think it
    > illustrates 
    > 
    > that OpenProcess, ptrace, and the like should really enforce
    > filesystem 
    > 
    > priviledges on the processes they can modify. I think that this is
    > 
    > something that needs to be done proactively.
    > 
    > 
    > 
    > The implication of allowing processes to modify each other
    > this way is 
    > 
    > that PFWs can not be easily made secure, but also that
    > malicious code has 
    > 
    > nice support from windows for doing some very bad things. For
    > instance it 
    > 
    > would be a simple addition to intercept syscalls made by any
    > process into 
    > 
    > which code can be injected, and in so doing hide the presence of
    > 
    > malicious activity from all local processes a user runs.
    <snip>
    
    (Sidenote: a number of previous apps used to test PFWs or Application
    Firewalls --
    http://www.pcflank.com/art21.htm )
    
    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 ..." 
    
    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.
    
    After that, you are probably talking about having to do somesort of
    signature analysis at the binary level.
    
    It is always an arms race.
    
    OpenProcess does require seDebugPrivileges, I believe.
    
    [An interesting "arms race" to follow in this regards is between GearBox
    software and HL cheaters, btw.]
    
    Drew
    
    Research Engineer
    eEye Digital Security
    



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