DLL injection - detection and prevention

Dynamically Loaded Libraries (DLL) are used in almost any project, because of their unique properties: modularity, ease to support, updatability. Unfortunately, this can be easily exploited and all it takes is for the attacker to simply replace the original DLL file with the malicious one (especially if project is no longer being maintained and does not have hashing to verify that the valid DLL is being loaded). Moreover attacker can load their DLL into a remote process (usually done to stay hidden, since after DLL is injected you can run malicious code "from within" a target process).

To make is easier to visualize, here is a small diagram:

For example, we have a program that displays number of seconds passed since it started (not to over complicate things):
An attacker can create a malicious DLL that logs pressed keys, but in this case it simply displays a message box:
And attacker also has an injector that will load their DLL into the target process:

The way an injector works is it allocates memory in the target process and writes a path to the DLL there (if you want to know more about writing to process memory check out my previous post). Then an attacker remotely calls 'LoadLibrary' function using 'CreateRemoteThread' and passes previously mentioned address as a parameter. Resulting in a target process loading a malicious DLL.
As we can see, it is relatively easy for an attacker to implement and stay hidden from users and it is up to the software developers and anti-malware services to ensure integrity of the programs.
One of the ways to do so is by overwriting 'LoadLibrary' function to do nothing (after we loaded all our libraries), this way an attacker will not be able to inject a DLL after program has started.
One security hole is fixed, but what if an attacker decides to load a DLL before we overwrote 'LoadLibrary'? A potential solution for this would be to check what DLLs are currently loaded (after overwriting 'LoadLibrary').
References and useful links:
https://msdn.microsoft.com/en-us/library/dtba4t8b.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx
http://www.rohitab.com/discuss/topic/29440-anti-dll-injection/
https://github.com/fortiguard-lion/anti-dll-hijacking/tree/master/ReflectiveDLLInjection
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682621(v=vs.85).aspx
https://en.wikipedia.org/wiki/DLL_injection

Comments

Post a Comment

Popular Posts

Process memory exploitation and protection in runtime

Image
To begin understanding why process memory patching is a serious issue we need to understand what it is and how it works. So, without further ado let's answer these questions. Memory patching is modification of process memory in runtime (in this post I am not going to talk about patching binary files). To help you better understand, let's imagine the following scenario: you created a game that has a high score system, user's score is stored in a variable in memory and at game over it is sent to the server. Now, imagine if someone changes the variable in memory right before it is sent. Sounds unfair to other honest players, doesn't it? To better demonstrate how it works I wrote a simple demo in c++ (which you can compile and test on your system). It this post I will be only talking about how it's done in user mode . Target program: Attacker program: First we compile and run a target program, it will display it's process identifier (PID) and a memory loca...
Read more

Function Hooking

Image
Function hooking is a technique attackers use to modify/block/monitor original function calls and their intended purpose. There are a few ways to perform such an attack: Virtual Method Table hooking, Event hooks (ex: keyboard, implemented by Windows), Interception (by overwriting first bytes of the function with a jump) and Import Address Table (IAT) hooking (can be global or internal). This list in not comprehensive, but these methods are the most popular. Let's start with the relatively easy method: interception. To make it visual and simple to follow, let's apply this method to a small program which sums two numbers together and multiplies the result by 2: Once we compiled the program, we want to find magicSum function in the debugger: Here we can see, that after original setup, mathematical calculation is being performed and then we return back to the where this function was called from. In order to intercept this function we will allocate a memory block in the prog...
Read more