Concerning the publication of HD Moore (creator of Metasploit) on the implementation of code through DLL Hijacking. Virtually all security blogs have mentioned the subject and already got over 20 exploits Exploit Database for applications such as Power Point, Firefox, Visio, Groove, Winamp, Google Earth, Photoshop and many more! 's it about DLL Hijacking and which affects so many applications? It really is very simple. DLL Hijacking takes advantage of the way it is looking for dynamic libraries (DLL) in the filesystem when a program tries to load using LoadLibrary function. What makes an attacker to create a dynamic library itself, which is equal to call any of the given loading a program when you try to open a certain file type. As at the time of opening the file (eg pps) the working directory is the file, if the attacker plant your library there, the program will load that instead of the original ... Guala! This attack makes sense when we have shared files. Suppose we have a file server based on CIFS (or SMB, the classic Windows shares) where different people can read and write. Now suppose Malicious creates a pps on the server and tells Josesito "look the presentation I put in that directory." Turn, creates a dynamic library Malicious knows that PowerPoint will attempt to load when opening pps. If Josesito not suspicious and curious enough, open the presentation directly from the file server (from experience, everyone does it, nobody copy to your hard things). By doing this, the charge Josesito PowerPoint Seller created by Malicious instead of the original, allowing Malicious run whatever you want with Josesito permits? For playing around, download any of the exploits contained in the Local section Exploit Exploit Database. Many bring the explanation of how to compile the libraries, but tell them they can do it with gcc for Windows as follows: gcc-shared-o <nombre-libreria-hijack>. <CODE> dll. c then a problem Windows? nop, this time Windows is saved. The problem is that applications do not correctly specify the path to your libraries. As you can see in the manual of the Load Library, it takes as a parameter the name of a library and loads it into memory. If you do not specify path to it, the function performs a standard search, ie it searches the library in default directories. The search order depends on whether "Safe DLL search mode" is active or not. The registry key to enable / disable safe mode is in HKLM \ System \ CurrentControlSet \ Control \ Session Manager \ SafeDllSearchMode (in XP and 2000 SP 4 comes disabled by default). SafeDllSearchMode If enabled, the search order is the follows: 1. The directory where the application is loaded. 2. The system directory. 3. The directory 16-bit system. 4. The Windows directory 6. The directories that are listed in the PATH environment variable. SafeDllSearchMode If disabled, the order is as follows: 1. The directory where the application is loaded. 2. The current directory. 3. The system directory. 4. The directory 16-bit system. 5. The Windows directory 6. The directories that are listed in the PATH environment variable. This standard search order can be altered by using the LoadLibraryEx or with SetDllDirectory, with which specify where to look first. As you will notice, this vulnerability affects any application that does not explicit the path to your libraries, and that is why there must be hundreds or thousands of applications affected. now, if it's so simple, how come nobody discovered it before? Well, if they did, at F-Secure say that this vulnerability was published about 10 years ago, but now came the stir because HD Moore published a kit that allows you to quickly find vulnerable applications. You can read and download the kit Exploiting DLL Hijacking Flaws and Better, Faster, Stronger: DLLHijaAuditKit v2. mentioned While the exploit makes sense from Windows shares, other forms of use is from archives, pen-drives, and WebDav ( extension to HTTP MS IIS). MS published a few days ago an advisory for administrators where they explain some steps to take to minimize the risks. Among the proposed workarounds: - Disable loading of libraries from WebDAV and remote shares. - Disable the WebClient service. - Block the ports 139 and 445 using firewall. Of course this will deprive the shares ... Of course we must be alert to the patches to publish the various suppliers to solve this problem. They also published a guide for programmers on what they can do to protect their applications against DLL Hijacking. Basically the recommendations are: - Specify the full path to the library whenever possible. - Using Redirection DLL or manifest to make sure you are using the correct DLL. - Ensure that "safe DLL search mode" is enabled. - Delete the current directory search path SetDllDirectory calling function with an empty string (""). - Do not use the SearchPath function to get the path of a library unless "safe process search mode" is enabled. - Do not assume version based operating system as returned by LoadLibrary.
