Today we released MS12-074, addressing a Critical class vulnerability in the .NET Framework that could potentially allow remote code execution with no user interaction. This particular CVE, CVE-2012-4776, could allow an attacker on a local network to host a malicious WPAD PAC file containing script code which could be executed on a victim machine without requiring any type of authentication or user interaction. To help you assess and mitigate the risk this vulnerability poses in your environment, we’d like to explain each of elements of a successful attack and list the potential workarounds and countermeasures.
First, an attacker would need to act as the authoritative proxy auto-configuration file server for your network. One way this could happen is if an attacker is able to register the hostname WPAD on your network. Alternately, an attacker present on your network segment could potentially act as a man-in-the-middle and respond to any WPAD queries for a legitimate proxy auto-configuration file server. Or, an attacker having the ability to spoof DHCP, DNS, or lower layer responses on your network segment can specify an arbitrary proxy auto-configuration file server directly.
The second element necessary for this attack is an outbound request from a .NET application requesting the proxy auto-configuration file server. Simply launching the browser is not enough to trigger this vulnerability. An Internet-based attacker would have trouble triggering this outbound request because the common browser-based Internet Zone .NET application mechanisms have been disabled by default, as of MS11-044. However, if an attacker can lure a victim user to an Intranet Zone site they control, the attacker could potentially instantiate an XBAP-based application which would trigger the request. If a .NET application uses the default proxy settings of the system either implicitly or explicitly via the .NET WebRequest.DefaultWebProxy property, and the app.config default proxy setting is not present, the Internet Explorer proxy settings will be used. If the “Automatically Detect Settings” box (shown below) is checked in Internet Explorer’s Internet Options->Local Area Network (LAN) Settings, the system will use WPAD to try to find the configuration file when the default proxy lookup is requested by the .NET application.
The third element necessary to trigger the vulnerability is the proxy auto-configuration file server responding with a PAC file containing malicious script code. If you are particularly concerned about this attack, you might consider inspecting PAC files for malicious script code.
Workarounds and Countermeasures
Installing the MS12-074 security update will comprehensively address this vulnerability. If you are unable to do so, you might consider other options to protect your machine from being exploited by this .NET vulnerability. The workaround list below is sorted by our recommended order of effectiveness:
- Explicitly set the proxy in .NET application’s code. This avoids default proxies at the application level.
- If not 1, provide an app.config file for your .NET app with the proxy explicitly set in it. This avoids default proxies at the application configuration level.
- If not 1 or 2 (because your .NET app MUST rely on a default proxy), uncheck “Automatically Detect Settings” and instead provide a location in “Use automatic configuration script” in IE Internet Options->Local Area Network (LAN) Settings, as shown above. This avoids WPAD entirely.
- If not 3, Register WPAD. See http://support.microsoft.com/kb/934864 for details. This protects WPAD from being spoofed.
The proxy configuration file is searched for in a sequence of steps, which can be found at http://blogs.msdn.com/b/askie/archive/2008/12/18/wpad-detection-in-internet-explorer.aspx.
We hope this blog post helped clarify the risk posed by this vulnerability to your network. Please email us with any questions you might have at switech [at] Microsoft [dot] com.
- Neil Sikka, MSRC Engineering