Protecting Against Remote DLL Preloading Vulnerabilities
Posted by Shane Garrett and David Means on August 30, 2010 at 10:54 AM EDT.
In the wake of the .LNK issue described in MS10-046, there has been a renewed interest in remote resource loading vulnerabilities.
The Back Story
HD Moore’s recent posting on the Rapid7 blog (and corresponding Metasploit module)make it abundantly clear that the long known problem of insecure DLL loading (which historically was believed to be a low impact local issue), can be successfully exploited to allow remote code execution via SMB or WebDAV.
Reports of this vulnerability in various applications have appeared, such as the recently disclosed issue in Apple iTunes described in CVE-2010-1795. Microsoft has also recently posted on their Security Research & Defense blog, information outlining the vulnerability, a risk assessment guide, a link to the original Security Advisory and a tool to help mitigate the issue.
How it works
When an application requests a DLL, the specified DLL is typically opened. However, if the DLL is specified by name only, then a series of paths will be searched and the first DLL found that matches the requested name will be loaded. Thus, applications that are vulnerable to this attack will have its working directory (the directory from which they are started) considered as part of the search path and a DLL in that directory, or a subdirectory there of, is loaded.
Therefore, if an attacker can entice a victim to open a program (or file) on a remote share, then the vulnerable program effectively searches the remote share as a current working directory. The result is that the application loads the attacker supplied DLL, leading to remote code execution in the context of the user running the program. The file opened by the user does not need to be malicious, or even valid. It may only serve as a means to start an associated vulnerable application that when activated, will search for a specific library (DLL) which the attacker has provided on the remote share.
Detection
Successful alerting upon non-desirable remote share access verses allowing desired remote share access is next to impossible from an IPS perspective.
From the perspective of an IPS, a remote resource looks like any other resource on your intranet. Hence, there is no easy way to distinguish between legitimate accesses and exploit accesses to these DLLs via network analysis. In the end, this is an application specific vulnerability and as such, each application is responsible for loading its own particular DLLs – it’s called Defensive Programming.
Current Remediation
Nevertheless, there are reasonable measures you can employ at the perimeter in order to protect against this type of attack.
- Block outbound SMB traffic at the network perimeter.
- Disable WebDAV on the client machines by stopping the Web Client service.
- Modify the operating system’s library loading behavior to prevent loading DLLs from remote shares as indicated in the Microsoft SRD blog post and KB2264107.
- Enable one or more of the following user-defined events (see your product documentation for specific details on specific implementation and/or configuration):
- pam.userdefined.url_data.[issueid]=”^.+[.]dll”
- pam.userdefined.url_raw_data.[issueid]=”^.+[.]dll”
- pam.smb.filename.[issueid]=”filename.ext”
- pam.smb.open.[issueid]=”filename.ext”
Note: for ‘pam.smb.*.[issueid]’, “filename.ext” is not a regular expression.
Note: [issueid] is in the set of {2011000, …, 2018999}
Future Remediation
In an upcoming XPU, we will release additional events which you may use in place of the described User-Defined events.
