DLL injection

In computer programming, DLL injection is a technique used for running code within the address space of another process by forcing it to load a dynamic-link library.[1] DLL injection is often used by external programs to influence the behavior of another program in a way its authors did not anticipate or intend.[1][2][3] For example, the injected code could hook system function calls,[4][5] or read the contents of password textboxes, which cannot be done the usual way.[6] A program used to inject arbitrary code into arbitrary processes is called a DLL injector.

Approaches on Microsoft Windows

There are multiple ways on Microsoft Windows to force a process to load and execute code in a DLL that the authors did not intend:

  • DLLs listed in the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs are loaded into every process that loads User32.dll during the initial call of that DLL.[7][8][9] Beginning with Windows Vista, AppInit_DLLs are disabled by default.[10] Beginning with Windows 7, the AppInit_DLL infrastructure supports code signing. Starting with Windows 8, the entire AppInit_DLL functionality is disabled when Secure Boot is enabled, regardless of code signing or registry settings.[11]
  • DLLs listed under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDLLs are loaded into every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW and WinExec. That is the right way to use legal DLL injection on current version of Windows - Windows 10. DLL must be signed by a valid certificate.
  • Process manipulation functions such as CreateRemoteThread or code injection techniques such as AtomBombing,[12] can be used to inject a DLL into a program after it has started.[5][6][13][14][15][16]
    1. Open a handle to the target process. This can be done by spawning the process[17][18] or by keying off something created by that process that is known to exist – for instance, a window with a predictable title,[19] or by obtaining a list of running processes[20] and scanning for the target executable's filename.[21]
    2. Allocate some memory in the target process,[22] and the name of the DLL to be injected is written to it.[13][23]
      This step can be skipped if a suitable DLL name is already available in the target process. For example, if a process links to ‘User32.dll’, ‘GDI32.dll’, ‘Kernel32.dll’ or any other library whose name ends in ‘32.dll’, it would be possible to load a library named ‘32.dll’. This technique has in the past been demonstrated to be effective against a method of guarding processes against DLL injection.[24]
    3. Create a new thread in the target process[25] with the thread's start address set to be the address of LoadLibrary and the argument set to the address of the string just uploaded into the target.[13][26]
      Instead of writing the name of a DLL-to-load to the target and starting the new thread at LoadLibrary, one can write the code-to-be-executed to the target and start the thread at that code.[6]
    4. The operating system then calls the initialization routine of the injected DLL.[13][27]
    Note that without precautions, this approach can be detected by the target process due to the DLL_THREAD_ATTACH notifications sent to every loaded module as a thread starts.[27]
  • Windows hooking calls such as SetWindowsHookEx.[2][5][6][28][29][30]
  • Use the SuspendThread or NtSuspendThread function to suspend all threads, and then use SetThreadContext or NtSetContextThread function to modify an existing thread's context in the application to execute injected code, that in turn could load a DLL.[4][31][32]
  • Exploit design limitations in Windows and applications that call the LoadLibrary or LoadLibraryEx function without specifying a full-qualified path to the DLL being loaded.[33][34][35]
  • Operating system-level shims.
  • Substituting an application-specific DLL with a rogue replacement that implements the same function exports as the original.[36]

Approaches on Unix-like systems

On Unix-like operating systems with the dynamic linker based on ld.so (on BSD) and ld-linux.so (on Linux), arbitrary libraries can be linked to a new process by giving the library's pathname in the LD PRELOAD environment variable, that can be set globally or individually for a single process.[37]

For example, on a Linux system, this command launches the command "prog" with the shared library from file "test.so" linked into it at the launchtime:

LD_PRELOAD="./test.so" prog

Such a library can be created in the same way as other shared objects. With GCC, this involves compiling the source file containing the new globals to be linked, with the -fpic or -fPIC option,[38] and linking with the -shared option.[39] The library has access to external symbols declared in the program like any other library.

On macOS, the following command launches the command "prog" with the shared library from file "test.dylib" linked into it at the launchtime:[40]

DYLD_INSERT_LIBRARIES="./test.dylib" DYLD_FORCE_FLAT_NAMESPACE=1 prog

It is also possible to use debugger-based techniques on Unix-like systems.[41]

Sample Code

Using the LoadLibrary API function

The sample function below uses a method of DLL injection that exploits the fact that kernel32.dll is mapped to the same address in almost all processes. Therefore LoadLibrary (which is a function of kernel32.dll) is mapped to the same address as well. LoadLibrary also happens to fit the thread start routine required by CreateRemoteThread.

#include <windows.h>

HANDLE inject_DLL(const char* file_name, int PID)
{
    HANDLE h_process = OpenProcess(PROCESS_ALL_ACCESS, FALSE, PID);                   //retrieving a handle to the target process

    char fullDLLPath[_MAX_PATH];                                                      //getting the full path of the dll file
    GetFullPathName(file_name, _MAX_PATH, fullDLLPath, NULL);

    LPVOID DLLPath_addr = VirtualAllocEx(h_process, NULL, _MAX_PATH,
                          MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);                  //allocating memory in the target process
    WriteProcessMemory(h_process, DLLPath_addr, fullDLLPath,
                       strlen(fullDLLPath), NULL);                                    //writing the dll path into that memory

    LPVOID LoadLib_addr = GetProcAddress(GetModuleHandle("Kernel32"),                 //getting LoadLibraryA address (same across
                                         "LoadLibraryA");                             //  all processes) to start execution at it

    HANDLE h_rThread = CreateRemoteThread(h_process, NULL, 0,                         //starting a remote execution thread at LoadLibraryA
                       (LPTHREAD_START_ROUTINE)LoadLib_addr, DLLPath_addr, 0, NULL);  //  and passing the dll path as an argument

    WaitForSingleObject(h_rThread, INFINITE);                                         //waiting for it to be finished

    DWORD exit_code;
    GetExitCodeThread(h_rThread, &exit_code);                                         //retrieving the return value, i.e., the module
                                                                                      //  handle returned by LoadLibraryA

    CloseHandle(h_rThread);                                                           //freeing the injected thread handle,
    VirtualFreeEx(h_process, DLLPath_addr, 0, MEM_RELEASE);                           //... and the memory allocated for the DLL path,
    CloseHandle(h_process);                                                           //... and the handle for the target process

    return (HANDLE)exit_code;
}

References
  1. James Shewmaker (2006). "Analyzing DLL Injection" (PDF). GSM Presentation. Bluenotch. Archived from the original (PDF) on December 3, 2008. Retrieved August 31, 2008.
  2. Iczelion (August 2002). "Tutorial 24: Windows Hooks". Iczelion's Win32 Assembly Homepage. Archived from the original on August 1, 2008. Retrieved August 31, 2008.
  3. Rocky Pulley (May 19, 2005). "Extending Task Manager with DLL Injection". CodeProject. CodeProject. Archived from the original on February 6, 2009. Retrieved September 1, 2008.
  4. Nasser R. Rowhani (October 23, 2003). "DLL Injection and function interception tutorial". CodeProject. CodeProject. Retrieved August 31, 2008.
  5. Ivo Ivanov (December 2, 2002). "API hooking revealed". CodeProject. CodeProject. Retrieved August 31, 2008.
  6. Robert Kuster (August 20, 2003). "Three Ways to Inject Your Code into Another Process". CodeProject. CodeProject. Retrieved August 31, 2008.
  7. "Working with the AppInit_DLLs registry value". Microsoft Help and Support. Microsoft. November 21, 2006. Retrieved August 31, 2008.
  8. Raymond Chen (December 13, 2007). "AppInit_DLLs should be renamed Deadlock_Or_Crash_Randomly_DLLs". The Old New Thing. Microsoft. Retrieved August 31, 2008.
  9. "dllmain.c". ReactOS. ReactOS Foundation. July 8, 2008. Retrieved August 31, 2008.
  10. AppInit_DLLs in Windows 7 and Windows Server 2008 R2
  11. "AppInit DLLs and Secure Boot". MSDN. Retrieved March 29, 2016.
  12. "'AtomBombing' Microsoft Windows Via Code Injection". Dark Reading. Retrieved April 20, 2017.
  13. Trent Waddington. "InjectDLL". Retrieved August 31, 2008.
  14. "Dll Injection". DreamInCode.net. MediaGroup1. May 4, 2006. Archived from the original on September 2, 2008. Retrieved August 31, 2008.
  15. Greg Jenkins (November 2007). "DLL Injection Framework". Ring3 Circus. WordPress. Retrieved August 31, 2008.
  16. Drew Benton (August 17, 2007). "A More Complete DLL Injection Solution Using CreateRemoteThread". CodeProject. CodeProject. Retrieved September 1, 2008.
  17. "CreateProcess". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  18. "PROCESS_INFORMATION". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  19. "GetWindowThreadProcessId Function". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  20. "EnumProcesses". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  21. "GetModuleBaseName". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  22. "VirtualAllocEx". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  23. "WriteProcessMemory". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  24. "Outpost Bypassing Self-Protection via Advanced DLL injection with handle stealing Vulnerability". Matousec. December 1, 2006. Retrieved August 31, 2008.
  25. "CreateRemoteThread". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  26. "LoadLibrary". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  27. "DllMain". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  28. "SetWindowsHookEx Function". Platform SDK for Windows XP SP2. Microsoft. Retrieved August 31, 2008.
  29. "AppInit_DLLs Registry Value and Windows 95". Microsoft Help and Support. Microsoft. March 1, 2005. Retrieved August 31, 2008.
  30. "Dll Injection using SetWindowsHookEx() Method". Game Reversal. April 3, 2008. Retrieved September 1, 2008.
  31. "SetThreadContext DLL Injection". January 16, 2007. Retrieved September 1, 2008.
  32. Ben Botto (September 6, 2008). "DLL Injector". Archived from the original on February 7, 2009. Retrieved September 1, 2008.
  33. "Insecure Library Loading Could Allow Remote Code Execution". Microsoft. June 10, 2011. Retrieved April 20, 2016.
  34. "Secure loading of libraries to prevent DLL preloading attacks". Microsoft. June 10, 2011. Retrieved August 8, 2012.
  35. "Microsoft Security Advisory: Insecure library loading could allow remote code execution". Microsoft. June 10, 2011. Retrieved April 20, 2016.
  36. Nicolas Falliere (September 26, 2010). "Stuxnet Infection of Step 7 Projects". Symantec.
  37. Linus Torvalds; David Engel; Eric Youngdale; Peter MacDonald; Hongjiu Lu; Lars Wirzenius; Mitch D'Souza (March 14, 1998). "ld.so/ld-linux.so – dynamic linker/loader". UNIX man pages. Archived from the original on February 6, 2009. Retrieved August 31, 2008.
  38. "Code Gen Options". Using the GNU Compiler Collection (GCC). Free Software Foundation. Retrieved August 31, 2008. -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. sqq.
  39. "Link Options". Using the GNU Compiler Collection (GCC). Free Software Foundation. Retrieved August 31, 2008. -shared Produce a shared object which can then be linked with other objects to form an executable. sqq.
  40. "The LD_PRELOAD trick". Peter Goldsborough. Retrieved May 17, 2017.
  41. Gregory Shpitalnik (February 12, 2009). "Code Injection into Running Linux Application". Code Project. Retrieved November 18, 2010.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.