Microsoft has released a security advisory on a class of attacks called “DLL hijacking”, “DLL preloading” or “binary planting” attacks.
What is DLL Hijacking?
While the names for this type of attack sound very complicated, it is in effect an attack that exploits the way certain Windows applications search and load DLLs that they need and use. Most Windows applications do not use a fully qualified path (or the full path) to load any required DLLs. An attacker (or malicious programmer) can place a DLL for a known program in a location that is searched before the real DLL’s location and ensure that the malicious DLL is loaded, resulting in remote code execution.
For instance, let’s say that an application, program.exe that requires library.dll that is usually in the Windows system directory. If the application does not specify the exact path for library.dll, Windows will search for the dll in the directory from which the application has been loaded first. If a malicious hacker has placed his own dll in the same directory as program.exe, then that dll will be loaded instead of the real dll. Windows just tries to find the first file that has the same name and does not verify if the file is actually the one that is required.
This vulnerability requires an attacker to convince someone to open a file using a vulnerable program (such as Word, PowerPoint or one of a huge number of other programs) from a remote network location. If the vulnerable application tries to load an external dll from the same location, the attack may be successful.
Impact of DLL Hijacking attack
Let’s assume that the real dll contains a function called GetFileSize. The attacker could have written a function with the same name, but made it do something quite different such as deleting a file or modifying registry settings. The dll will run with the same privileges as the user running the application. If the user is logged on with administrative user rights, the attacker could take complete control of the system.
Protecting against DLL Hijacking attacks
The ideal way is to load external libraries securely by using using fully qualified paths. Application users can do the following to safeguard themselves:
- Disable loading of libraries from WebDAV and remote network shares
- Disable the WebClient service
- Block TCP ports 139 and 445 at the firewall
- Install updates from third-party vendors that address insecure library loading
- Protect your computer by installing updates/patches and enabling personal firewall software.
Detailed information and instructions can be found in Microsoft’s security advisory 2269637.