RE: Bypassing Personal Firewalls

Howdy,

>Just for clarification...I'm trying to understand what

        Meaning the new code does not rely on a DLL. I haven't seen this demonstrated anywhere, but I'm sure it's been done elsewhere. All of the code injection I've seen to date involves injecting a DLL into a process, using AppInit_DLLs, or DLL injection. This code differs from those moethods in that it's a lot harder to detect, it simply allocates a new code page into a process's image, and then starts a thread in it.

>How does this code conceptually and significantly

        Per above. Conceptually it's the same (as are almost all ways of beating a PFW, you exploit the fact that some apps are trusted), how ever it is significantly different in two respects:

1. There does not need to be a predefined interface to permit it (unlike COM). Any application can be zombified.
2. There are no new DLLs loaded into the process, at least none that wouldn't normally be there (i.e. wsock32.dll may load if it's not already loaded, but that's quite normal).

        Because there are no 'visible modifications' to the process PFW software does not notice that the process images have changed, and permits the connection to occur.

        The issue is that it would be pretty darn difficult to detect this sort of modification to a running process.

>I think we're back to the old adage of running code on

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

        Well, the malicious code would have to run on a system. Obviously this doesn't necessarily mean double-clicking an .exe.

        That is entirely the "larger issue here". Outbound protection in a PFW can never really work because they ignore the fact that once I can run code on your system, I 0wn j00. A major selling point for the vendors here is an outbound protection scheme that gives users nothing more than a false sense of security.

        Well that and windows really shouldn't make it this easy to take control of a process. Sure you can only do this to your own processes ... But it just doesn't make sense. Allowing radical changes to a program like this is asking for trouble, imo. If you combine this code with syscall interception, which is also dead easy on NT, you can undermine a whole of functionality.

Cheers,
~ol