Hi there,
many processes can be forced to load a library by using a remote CreateRemoveThread-call on LoadLibrary, some cannot.
In order to run such a take-over the attacking source has to write to the victim process memory and therefore get a process handle (OpenProcess).
I would like to prevent my self-coded asm processes from that one ... so what do I have to do in order to make a remote OpenProcess-call fail?

Regards,
Dom
Posted on 2005-09-05 15:47:17 by Dom
i don't know of such way to protect your program, but there are definitely ways to circumvent it

you can inject DLL into a running process that is already running for a while, or you can load it before it even does anything
CreateProcess(yourprgoram, CREATE_SUSPENDED) <-- loads your program, giving it no chance to install any protection
CreateRemoteThread(pi.hProcess, kernel32.LoadLibrary, "hacker.dll") <-- inject library, with no protection activated yet

if your program can be hacked by loading some DLL there and doing shit, then u should redesign it so its secure even with some hacker dll loaded
Posted on 2005-09-05 15:52:25 by comrade
what exactly are u trying to protect?
Posted on 2005-09-05 15:52:33 by comrade
There are ways to protect yourself against OpenProcess, which requires adjusting your programs security tokens... this can, however, be circumvented too, without too much bother.
Posted on 2005-09-05 16:15:12 by f0dder
A quick solution might be to just have your process hook loadlibrary (its own) and then filter the calls to it so that only authorized dll's can be loaded. Would still be easy to circumvent though.
Posted on 2005-09-05 21:28:19 by Lollie
to comrade: it's a common problem, not especially one of my self-written programs...
just try it on your own programs: OpenProcess, VirtualAllocEx for the library's name
in the remote memory, copy the library's name using WriteProcessMemory and
finally run a CreateRemoteThread on the process handle using the fixed address
of LoadLibrary and as parameter the remote memory pointer to the library's name ...
The tricky thing is that both Threads and LoadLibrary take one parameter ...


to f0dder: yes you are right, I have a source to OpenProcess a process that runs
with specific token adjustments...you just have to re-set the token values...

to Lollie: that seems to be the best solution as the whole "attack" is based on
the fact that LoadLibrary has the same address in every process. But how
could someone circumvent a patched/hooked procedure? Overwrite the hook?

Actually I think the best would be to prevent remote CreateRemoteThread calls, but
I got now idea if such a thing could be done ...

btw thanks for your replys...
Dominik
Posted on 2005-09-06 05:34:00 by Dom
Dom, if you patch the LoadLibrary function in the system DLL file (in memory using a trampoline, like Microsoft detours), it would probably be possible to have an okay prevention on DLL injection. Just patching the IAT won't be enough, though.
Posted on 2005-09-06 05:39:11 by f0dder
sure, i ment such a trampoline. As the attacking process thakes
his own LoadLibrary address the iat wouldn't be such a great solution...
Dom
Posted on 2005-09-06 05:42:25 by Dom
if your program can be hacked by loading some DLL there and doing shit, then u should redesign it so its secure even with some hacker dll loaded

to Comrade again: you don't want to re-design every source so that it is secure when everything that's process-specific cannot be trusted...really hard work...
Posted on 2005-09-06 05:48:46 by Dom
Dom, what i mean is if your program's security depends on the disability of someone to be able to inject malicious code in to your program, then you should do it differentely, like encrypt code using public-key encryption n' shit, so the security depends on ability to factor large number, u know what i am sayin?
Posted on 2005-09-06 09:48:13 by comrade

Dom, what i mean is if your program's security depends on the disability of someone to be able to inject malicious code in to your program, then you should do it differentely, like encrypt code using public-key encryption n' shit, so the security depends on ability to factor large number, u know what i am sayin?

What would that accomplish? Once decrypted in memory the code would behave the same way.

IMHO if you really want your program to be secure you can put all the sensitive parts in a system service and make the GUI just interface with it. That way if the attacker can still inject code into your program then you have bigger problems anyway. ;)
Posted on 2005-09-06 10:21:54 by QvasiModo
Yes, but decryption key is sold on the Internet for $10000
Posted on 2005-09-06 10:39:06 by comrade

Yes, but decryption key is sold on the Internet for $10000

I'm sorry, you lost me there.  :?:
Posted on 2005-09-06 10:48:57 by QvasiModo
He's trying to say that actually finding the correct key is almost impossible
Posted on 2005-09-06 11:25:02 by shism2
But the program has to be run... encrypting the code itself does no good. Encrypting the data is another story of course.
Posted on 2005-09-06 11:26:42 by QvasiModo
Ok well encrypted the code would work as a 1 time thing.....After it's decrypted ya it would be dumped.
Posted on 2005-09-06 14:19:50 by shism2
Comrade, you are right with the program's security, this should not rely on such things. But from my point of view there are always
situations when sensitive data is stored in a normal usermode process' memory (QvasiModo,  i have no practice on service programming).
So if a program aims on using such a situation in a specific victim application  it just has to know where the memory is placed.

Regards,
Dom
Posted on 2005-09-06 19:30:05 by Dom
Service programming won't help, that's still usermode. Kernelmode is usually overkill, and unless you do very tricky stuff, not too bad either. Won't be as easy to trace, but can still be disassembled.
Posted on 2005-09-06 20:07:18 by f0dder