1. GOT overwrites and IAT hooks

2. What is this?  The GOT hijack was a key exploit technique for me, it was the first time I internalized that we are overwriting pointers to point to our code.  It also has a great introductory paper by C0ntex, “How to hijack the Global Offset Table with pointers for root shells”.  If you wrap your head around GOT overwrites, you are a stones throw away from internalizing IAT hooks.  I’m not going to re-step through C0ntex’s lab, you can do that on your own. But we should explore libraries a bit more.

3. Lets review how an OS works.

4. So, How does the GOT work?

5. In words ● At compile time the function call (literally a call in asm) points to the PLT (procedure linkage table). The PLT points to the GOT. At runtime the runtime linker (rtld) populates the GOT table with the address that the function in the library loaded with.

6. So, the trick to c0ntex’s paper is… ● Why are there two vulnerabilities used? – First, clobber the pointer and point it to the GOT table entry for printf(). – Second, use that clobbered pointer and clobber the location it points to. – Since it points to the GOT, we clobber the address in the GOT. This is the address that will get called next time printf() is called.

7. The GOT pointer was altered ● In the C0ntex paper, he points it towards a system command, ret2libc style. ● The key to understand is that we overwrote a pointer and had it point to code we controlled.

8. So, start to get it, we are clobbering pointers ● We clobbered the GOT pointer. ● But we could clobber any pointer that’s going to execute: – Function pointers are practical targets – Ctors (constructor table) pointers – Dtors (destructor table) pointers – Vtable (C++ virtual table) pointers

9. That’s for exploitation, what about other uses ● The IAT hook isn’t that different than the GOT table hijack (to me, others may disagree). ● Import Address Table ● It’s a go-between on a Windows box between a loaded executable and the DLL’s that hold its functions. ● Lets do a lab on IAT for Windows XP. (someday I’ll do this again on Windows 7 and see how different it is, but I know my immediate audience is using XP)

10. Step 1 – build a bad dll. ● You need a.dll to hook into. This would be your “malware”. ● We can build this with free tools, like Cygwin and the free compiler mingw. Use the simple build.sh to make the DLL. ● When a DLL is loaded, the Dllmain function runs first, even before the program that called it. ● This is where we set our hook.

11. It depends ● DependencyWalker is a tool that can show you all the dll’s a program uses. ● It can also show you all the functions a dll offers. ● Run dependencyWalker on your new dll.

12. Still depends

13. Still Depending ● Notice a few key points about the previous slide. – In the previous picture, our badDll.dll only offers one function. We know it as “evilf”. The computer, and programs, knows it by ordinal number 0x1. – We can see it being offered. – Any function offered by a DLL can be used. – It’s a program we made in Cygwin, but the cygwin.dll is missing. This is from the –mno-cygwin or by using the targeted cross compile mingw, depending on how recent your cygwin is. – This is important or your code will only run on hosts that have Cygwin installed. – While Cygwin lets you use the “standard” Linux API, because we aren’t linking to that DLL you can’t use any of that. You can only use the Windows API.

14. Still Depending We aren't going to do anything more with DependencyWalker, I just think its a useful tool to help you understand how a DLL works.

15. Building our DLL ● So, we analyze the exe to determine the functions we want to hook. ● There are many tools, but lets just stick with lordPE to make the lab simple.

16. fputs ● So we see this simple program opens a file and writes 01234 to the file, then closes it. ● It uses fputs(const char* string, FILE *stream) ● We are going to hook that in the IAT. ● So, we need a DLL with a function that is exactly the same (evilfputs(const char* string, FILE *stream) )

17. Set the hooks ● Build our DLL called pub-badDll.dll and the executable thepig.exe. ● For this lab, we will use lordPE to add our pub-badDll.dll to the import table of our executable. ● So, open up the binary of our demo executable with lordPE and choose PE Editor. ● Inside Directories you should see an option to open the import table. (actually, just click around in lordPE and learn a bit here) ● You will add pub-badDll.dll to the import list with efputs as an API addition (pub-badDLL.dll might need to be in your system32 directory)

18. The badDll.dll ● I have stripped this DLL down to its very very basics and commented what each line does so that non-programmers can easily read it. Look through it. ● Once you have added the DLL to the import table, run the executable. ● The main function should set up the hook and when the program tries to call fputs, it will actually call our function efputs.

19. The badDll.dll continued ● Our efputs function ignores the string they actually sent to us and replaces it with the word evil!! ● Even though the program thepig.exe called fputs, once our hook occurred it was our code that was running. We could have had it do anything.

20. If it doesn't work. ● It was tested on Win XPsp3. ● Its probably the wrong thunk address. Read the comments in the DLL, look at lordPE carefully. ● Just get the right one from lordPE and change it in the DLL source code. ● Rebuild it. ● Re-import the DLL, and re-run the executable.

21. The badDll.dll continued ● So, brainstorm for a minute on how we could use this. We could hook lots of functions, have our code do whatever we wanted. ● How could we use this to hide malware? ● Sometimes, our goal might not even be evil. What if we were testing software in a development shop? We could hook some functions that are not done, or not working and fake the return values to test our software.

22. Questions? mistakes? ● I can be reached at jhind@hick.org