RE: Bypassing Personal Firewalls

["Oliver Lavery" <oliver.lavery () sympatico ca>]

Howdy,

> Just for clarification...I'm trying to understand what
> you mean...you say "without the need for a DLL", but
> the code relys on three DLLs.

        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
> differ from similar code that accesses IE as a COM
> server, and makes the same request?  

        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
> a system.  For this to execute, thermite.exe will have
> to execute on the system...so once you get the code on
> the system, in many cases, it's all over with at that
> point.  Perhaps that's the larger issue here.

        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
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/