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/
This archive was generated by hypermail 2b30 : Fri Feb 21 2003 - 12:16:13 PST