I hope that everybody is doing fine! :)
I was working in this PoC on my free time and now I could get enough time to bring the technical of it. It take a while because I first wanted to bring some introductory posts before writing the technical stuff. So let's do it!
First of all I hope that you had read my last posts to a better understanding of what I will show here, because I will not explain in details everything. So the prerequisites for this post is:
What I utilized to do this ?
I have been studying more in-depth the PEB hooking (this post is not about PEB hooking) to learn more thoroughly how Windows Internals works. My way to learn is coding, practicing. I like to brush bits :). Basically the PEB hooking stole a module from some process, changing addresses in the LdrModules located in the PEB. But for this I needed a DLL that exports the same functions that the original do.
To export all functions from a DLL I coded the "DLL Exporter" tool to extract the functions exported by some DLL. It access the export directory and generate 2 files for NASM. I included the code generated in the main code of the fake image DLL ASM. Of course for this example it doesn't matter, because I only exported 1 function, anyway it worth to take a look on it to see how it works.
In this example I coded a program that simulate a message exchange, there is no socket connecting to keep it simple. But you got point right ? The program passes the message to a DLL that encodes it and hypothetically would send encoded message to somewhere.
To do this PoC I made a fake DLL that exports the same function of the original. This fake DLL grabs the message, log it in a file before encoding it and send the execution to the original one, without injecting any code neither in the executable nor original DLL, just rewrites the IAT of fake DLL. I just named the fake image file as the same name of the original image, so when the Windows Loader searches for the DLL it will load the fake one.
Problems
Theoretically I just have to leave the windows load the fake DLL and inside of the fake image I load the original DLL, then I can call all functions that belongs to it. I could do this just with LoadLibrary and GetProcAddress, right ? But imagine a DLL with a LOT of functions, the work I would to do to make everything callable would be huge and painful.
So what I did was to link the original DLL to my fake DLL and there is where I found the problem. When the program loads the fake DLL consequently the original DLL is loaded, since the fake image has the same name as the original image, windows loader will end up linking fake image to itself and a Deadlock is set. So when the fake image is called by the process it can't jump to the original image and keeps calling itself forever. To set everything in the right place I had to alter the IAT (Import Address Table) of the fake DLL.
Solution
As a solution to this problem I had to rewrite the IAT with the original function addresses and I did it with NASM. At this point if you don't know what is a IAT, please read my previous topics and all the references I gave there. The solution is to load the original DLL image, save the AddressOfFunctions (Export Directory), save the IAT (FirstThunk - Import Directory), change the IAT memory protection (protection against writing), then I just iterated through the AddressOfFunction rewriting the addresses to the IAT by the addresses of AddressOfFunctions. Now all my imported functions in the fake image DLL will call the original image DLL functions.
Spliting the Project
I will give a brief explanation about the source code. I left comments in the source to help in the reading, but the code itself is self explanatory. Anyway any doubt or question just contact me. In the next posts I will bring CMake files to make easy to compile, for now I just make some PowerShell scripts to do it in each folder.
- Folders
- dll
- This folder have the code of the dllsend.dll.
- dll-consume
- This folder contains the code of the program to consume the dllsend.dll.
- dll-exporter
- This folder contains the program that receives a DLL in the command and generate two files. dll_parameter.dll.ext and dll_parameter.dll.subs.
- dll_parameter.dll.ext contains the "extern" code of all exported functions to append in the ASM code.
- dll_parameter.dll.subs contains the function declaration to append in the ASM code.
- dll-fake-asm
- This folder contains the body of the fake DLL image. I coded all the process using NASM and GoLink to link the compiled object with the original DLL image.
- make.ps1 has the logic to link the fake DLL image.
- In the GoLink you have to inform all the exported functions. In this case you can adapt the DLL Exporter to generate this part easily.
Walking through the process
I will assume that you have compiled everything and I will just walk to the main parts of the process. The dll-consume is very straight forward, you type your message, then it back to you with the encoded string and the it's hex dump.
dll-consume compiled
So as I mentioned before I just renamed the original DLL adding a "2" in the end. So let's see what happen inside of this process. You will see that since the fake DLL is pure ASM code it's size is tinier than the original image DLL compiled with GCC.
List of files
So I already mentioned before how to find the OEP (Original Entry Point) of the programs compiled in GCC. You can find the pattern that GCC uses to do this or you can go directly in the inter-modular calls made by this module m.exe. This is the main function:
Main function of m.exe
As I always said, take a moment to walk-through the program, it's important to train your eyes with assembly code. In the image above you will see the IAT of the m.exe module in the line that calls the send function where you see a jump to imported function. At this point in debugging you can see all the modules loaded in the memory tab. Since original DLL was loaded in the entry function of my fake image DLL it is already loaded in the memory tab.
Memory mapping
The main/entry code of the fake image DLL already was executed when the Windows Loader loaded the fake image. To step through this part in the debugger you can check Dll Entry option in the preferences.
Dll Entry - Debugging
I already set a breakpoint in the send call, then I stepped into until I get the fake send function.
As you can see it's pretty straight forward. I imported some C functions to save the message in the file log.bin. Opened a handle to the file, wrote to it and closed the handle. After the log process, I restored the register context and jumped to the original send function.
I could enhanced this fake send function more to make the log better, but it useless. To practice ASM, try to enhance it inside the fake DLL code. Make a breakline in each message and save it to the log.bin, if you analyze the code you will see that is easy.
Fake function 'send' disassembled
I will not step-by-step through the IAT rewriting, I leave to you to debug it. Open the DLL on CFF Explorer and debug the entry function of fake DLL. The code itself has a lot of comments. Any help that you may need just contact me, I would be glad to help. ☺
Countermeasures ?
There are some countermeasure against it, you just have to be creative about it. For this you could check the MD5 of the DLL before call it or you could count how many modules are loaded in the process memory space. As you saw in the walk-through there is a exceeding module dllsend2.dll and with this information you can define if your application has been compromised or not.
Anyway it's hard to fight against these things. In RE world, programmers have to do all they can to make the work of reversers as hard as possible in order to avoid the RE itself.
Conclusion
In computer world everything is possible it's just a time to understand how to do it. I did this PoC for learning purposes and a better understand the Windows Internals. I hope that with this technical example you can learn a little with it too. Thanks for reading.
I didn't walked through the loading process of fake image DLL because I think my comments in the code are pretty self explanatory. Anyway any questions feel free to contact me.
No comments:
Post a Comment