<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: WPAD: Internet Explorer&#8217;s Worst Feature</title>
	<atom:link href="http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/feed/" rel="self" type="application/rss+xml" />
	<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/</link>
	<description>Building Security in a Networked World</description>
	<lastBuildDate>Wed, 24 Feb 2010 02:00:58 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Grant Bugher</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-350</link>
		<dc:creator>Grant Bugher</dc:creator>
		<pubDate>Tue, 26 Jan 2010 21:10:51 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-350</guid>
		<description>I&#039;m not quite sure what sort of attacks against IE &quot;over SSL&quot; you mean.  There have, in the past, been attacks against browsers by embedding faulty strings designed to cause buffer overruns directly into the X.509 certificate -- the only defenses against these are running a fully-patched browsers (to my knowledge, there are no known attacks of this type that still work on current versions of any major browser) and being cautious as to what you browse to.  If you mean simply being attacked by an SSL site (e.g. embedded malware), it&#039;s once again the same mitigations --- avoid sites that are often malicious (e.g. warez) and use a current browser.  The only thing SSL affects is that network-based IDS systems will not protect you in the case of an SSL site, since they can&#039;t read the encrypted traffic -- you&#039;re reliant on host-based protection like anti-virus or anti-spyware software on your own computer.  Of course, most people aren&#039;t browsing behind a NIDS anyway, so this is no change unless you&#039;re in a corporate environment.

On the other hand, if you mean attacks not against IE but against SSL itself, such as Moxie&#039;s SSLSniff, they&#039;re hard to detect.  One thing that helps is actually opening and verifying the certificate -- just because the padlock icon is there doesn&#039;t mean you&#039;re communicating with what you think you&#039;re communicating with.  Most of the time attackers don&#039;t forge an entire certificate, just the domain name, so everything else may look wrong (or the certificate may be for * rather than a specific domain.)  Once again, use a current, fully-patched browser, as this protects you from null-byte certificates (which actually may look perfect if you inspect them.)  And most importantly of all, don&#039;t use insecure wireless networks.  Attacks like SSLSniff rely on being a man-in-the-middle -- that is, an attacker must be able not just to read your communication but also to modify it.  This means either he has to control a router between you and the website you&#039;re talking to, or he has to be on a wireless network with you.  The &lt;em&gt;only&lt;/em&gt; safe thing to do on an insecure (open or WEP) wireless network is to VPN to a secure network.  &lt;em&gt;Anything&lt;/em&gt; else is vulnerable.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not quite sure what sort of attacks against IE &#8220;over SSL&#8221; you mean.  There have, in the past, been attacks against browsers by embedding faulty strings designed to cause buffer overruns directly into the X.509 certificate &#8212; the only defenses against these are running a fully-patched browsers (to my knowledge, there are no known attacks of this type that still work on current versions of any major browser) and being cautious as to what you browse to.  If you mean simply being attacked by an SSL site (e.g. embedded malware), it&#8217;s once again the same mitigations &#8212; avoid sites that are often malicious (e.g. warez) and use a current browser.  The only thing SSL affects is that network-based IDS systems will not protect you in the case of an SSL site, since they can&#8217;t read the encrypted traffic &#8212; you&#8217;re reliant on host-based protection like anti-virus or anti-spyware software on your own computer.  Of course, most people aren&#8217;t browsing behind a NIDS anyway, so this is no change unless you&#8217;re in a corporate environment.</p>
<p>On the other hand, if you mean attacks not against IE but against SSL itself, such as Moxie&#8217;s SSLSniff, they&#8217;re hard to detect.  One thing that helps is actually opening and verifying the certificate &#8212; just because the padlock icon is there doesn&#8217;t mean you&#8217;re communicating with what you think you&#8217;re communicating with.  Most of the time attackers don&#8217;t forge an entire certificate, just the domain name, so everything else may look wrong (or the certificate may be for * rather than a specific domain.)  Once again, use a current, fully-patched browser, as this protects you from null-byte certificates (which actually may look perfect if you inspect them.)  And most importantly of all, don&#8217;t use insecure wireless networks.  Attacks like SSLSniff rely on being a man-in-the-middle &#8212; that is, an attacker must be able not just to read your communication but also to modify it.  This means either he has to control a router between you and the website you&#8217;re talking to, or he has to be on a wireless network with you.  The <em>only</em> safe thing to do on an insecure (open or WEP) wireless network is to VPN to a secure network.  <em>Anything</em> else is vulnerable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-349</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Tue, 26 Jan 2010 20:45:47 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-349</guid>
		<description>I understand the countermeasures for IE attacks, but how can you detect an attack against Internet Explorer over SSL?</description>
		<content:encoded><![CDATA[<p>I understand the countermeasures for IE attacks, but how can you detect an attack against Internet Explorer over SSL?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Melvin Guaganik</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-192</link>
		<dc:creator>Melvin Guaganik</dc:creator>
		<pubDate>Fri, 01 May 2009 19:20:18 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-192</guid>
		<description>I have a small update.  I have successfully disabled the Vista service &quot;WinHTTP Web Proxy Auto-Discovery Service&quot; and I believe I have finally stopped the implementation of the Web Proxy Auto-Discovery (WPAD) protocol.  

As of now, I&#039;m not sure what side effects I&#039;ll encounter.  Disabling this service may also impact COM Automation and the Win32 API components for sending and receiving HTTP requests from applications.  Actually, I might like this since I really don&#039;t like apps accessing the web without my control.  My browser still works ... that&#039;s good!  Well see.

By the way, with Wireshark I now see a lot of different activity on initialization of my internet connection.  I need to look into this....</description>
		<content:encoded><![CDATA[<p>I have a small update.  I have successfully disabled the Vista service &#8220;WinHTTP Web Proxy Auto-Discovery Service&#8221; and I believe I have finally stopped the implementation of the Web Proxy Auto-Discovery (WPAD) protocol.  </p>
<p>As of now, I&#8217;m not sure what side effects I&#8217;ll encounter.  Disabling this service may also impact COM Automation and the Win32 API components for sending and receiving HTTP requests from applications.  Actually, I might like this since I really don&#8217;t like apps accessing the web without my control.  My browser still works &#8230; that&#8217;s good!  Well see.</p>
<p>By the way, with Wireshark I now see a lot of different activity on initialization of my internet connection.  I need to look into this&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Melvin Guaganik</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-187</link>
		<dc:creator>Melvin Guaganik</dc:creator>
		<pubDate>Sun, 19 Apr 2009 16:49:54 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-187</guid>
		<description>In my investigation, I found that Vista does attempt to download the WPAD file regardless of the browser setting. I have both Firefox and IE 7 with autodiscovery disabled, but still Vista is looking for WPAD on initial startup of my network connection (verified with wireshark).

I have investigated a large number of articles and comments to try to find a solution, and unfortunately, none that I&#039;ve found fully stop the problem.  The best solution I found was to set my computer&#039;s name to WPAD, and thus limit the number of DNS queries that are attempting to locate the WPAD server.  Now, it&#039;ll only query the following:

WPAD.XXXX.YYYYY.COM

and then

XXXX.YYYYY.COM

(where XXXX.YYYYY is my ISP&#039;s domain name).

Before this change, I have a lot of queries for various forms of WPAD addresses, which didn&#039;t exist.  I tried to disable devolution as mentioned in ...

http://www.microsoft.com/technet/security/advisory/945713.mspx

... but it DID NOT WORK.  According to the advisory, I should be able to disable devolution by setting the following registry entry to 0 (FALSE):

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\UseDomainNameDevolution

It didn&#039;t work.  Using ProcessMonitor, I also tracked down two different registry entries for devolution that my system was accessing prior to devolution, and neither stopped devolution.  It must be hardcoded.</description>
		<content:encoded><![CDATA[<p>In my investigation, I found that Vista does attempt to download the WPAD file regardless of the browser setting. I have both Firefox and IE 7 with autodiscovery disabled, but still Vista is looking for WPAD on initial startup of my network connection (verified with wireshark).</p>
<p>I have investigated a large number of articles and comments to try to find a solution, and unfortunately, none that I&#8217;ve found fully stop the problem.  The best solution I found was to set my computer&#8217;s name to WPAD, and thus limit the number of DNS queries that are attempting to locate the WPAD server.  Now, it&#8217;ll only query the following:</p>
<p>WPAD.XXXX.YYYYY.COM</p>
<p>and then</p>
<p>XXXX.YYYYY.COM</p>
<p>(where XXXX.YYYYY is my ISP&#8217;s domain name).</p>
<p>Before this change, I have a lot of queries for various forms of WPAD addresses, which didn&#8217;t exist.  I tried to disable devolution as mentioned in &#8230;</p>
<p><a href="http://www.microsoft.com/technet/security/advisory/945713.mspx" rel="nofollow">http://www.microsoft.com/technet/security/advisory/945713.mspx</a></p>
<p>&#8230; but it DID NOT WORK.  According to the advisory, I should be able to disable devolution by setting the following registry entry to 0 (FALSE):</p>
<p>HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\UseDomainNameDevolution</p>
<p>It didn&#8217;t work.  Using ProcessMonitor, I also tracked down two different registry entries for devolution that my system was accessing prior to devolution, and neither stopped devolution.  It must be hardcoded.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Grant Bugher</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-168</link>
		<dc:creator>Grant Bugher</dc:creator>
		<pubDate>Fri, 02 Jan 2009 06:41:21 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-168</guid>
		<description>I&#039;m not aware of any changes; in IE8 there&#039;s still the usual &quot;Automatically Detect Settings&quot; box in Internet Options, which should still toggle WPAD usage on and off.  It&#039;s possible that IE still &lt;em&gt;looks&lt;/em&gt; for the PAC file even if it doesn&#039;t intend to use it, though I admit that would be somewhat bizarre behavior.  I&#039;ll have to look into it.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not aware of any changes; in IE8 there&#8217;s still the usual &#8220;Automatically Detect Settings&#8221; box in Internet Options, which should still toggle WPAD usage on and off.  It&#8217;s possible that IE still <em>looks</em> for the PAC file even if it doesn&#8217;t intend to use it, though I admit that would be somewhat bizarre behavior.  I&#8217;ll have to look into it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bootsy</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-167</link>
		<dc:creator>Bootsy</dc:creator>
		<pubDate>Fri, 02 Jan 2009 03:33:42 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-167</guid>
		<description>Hello, has something changed in IE recently, I first discovered wpad because I was playing around with wireshark and wanted to know what wpad is.  I&#039;ve gone into connections, Lan Connections and everything is unchecked, yet it is always showing up in wireshark.  Is there any other way to shut it down?</description>
		<content:encoded><![CDATA[<p>Hello, has something changed in IE recently, I first discovered wpad because I was playing around with wireshark and wanted to know what wpad is.  I&#8217;ve gone into connections, Lan Connections and everything is unchecked, yet it is always showing up in wireshark.  Is there any other way to shut it down?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Uno</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-161</link>
		<dc:creator>Uno</dc:creator>
		<pubDate>Thu, 13 Nov 2008 19:18:45 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-161</guid>
		<description>Hi Grant,
interesting post, but have you ever managed to make this work? I haven&#039;t seen any article describing how it work. I&#039;m a pentester but for some reason the attack in not working in my test environment.</description>
		<content:encoded><![CDATA[<p>Hi Grant,<br />
interesting post, but have you ever managed to make this work? I haven&#8217;t seen any article describing how it work. I&#8217;m a pentester but for some reason the attack in not working in my test environment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Grant Bugher</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-140</link>
		<dc:creator>Grant Bugher</dc:creator>
		<pubDate>Mon, 06 Oct 2008 05:40:04 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-140</guid>
		<description>If you specify the location of WPAD using the DHCP auto-proxy-config option, your network is relatively secure against this sort of attack (i.e. secure enough that an attacker is likely to use another avenue altogether rather than doing the sort of thing it would require to get past this, such as spoofing DHCP or playing games with ARPs.)

The problem isn&#039;t so much with corporate networks.  The problem is more that these laptops from corporate networks are all set up to rely on WPAD for proxy information, and then people carry them off to other networks, like open wireless, with those same configuration settings intact.  Suddenly, they&#039;re asking for WPAD on networks that are potentially hostile.</description>
		<content:encoded><![CDATA[<p>If you specify the location of WPAD using the DHCP auto-proxy-config option, your network is relatively secure against this sort of attack (i.e. secure enough that an attacker is likely to use another avenue altogether rather than doing the sort of thing it would require to get past this, such as spoofing DHCP or playing games with ARPs.)</p>
<p>The problem isn&#8217;t so much with corporate networks.  The problem is more that these laptops from corporate networks are all set up to rely on WPAD for proxy information, and then people carry them off to other networks, like open wireless, with those same configuration settings intact.  Suddenly, they&#8217;re asking for WPAD on networks that are potentially hostile.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jack S.</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-137</link>
		<dc:creator>Jack S.</dc:creator>
		<pubDate>Wed, 24 Sep 2008 17:28:58 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-137</guid>
		<description>So am I correct in saying that the exploits you are reffering to are for all intents and purposes, elliminated if you DO use wpad in your enterprise network?  (entries being in DHCP and DNS).

- JS</description>
		<content:encoded><![CDATA[<p>So am I correct in saying that the exploits you are reffering to are for all intents and purposes, elliminated if you DO use wpad in your enterprise network?  (entries being in DHCP and DNS).</p>
<p>- JS</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Coova.org &#187; Blog Archive &#187; DHCP Discovery</title>
		<link>http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/comment-page-1/#comment-24</link>
		<dc:creator>Coova.org &#187; Blog Archive &#187; DHCP Discovery</dc:creator>
		<pubDate>Fri, 25 Jan 2008 13:14:52 +0000</pubDate>
		<guid isPermaLink="false">http://perimetergrid.com/wp/2008/01/11/wpad-internet-explorers-worst-feature/#comment-24</guid>
		<description>[...] from a network. The Web Proxy Auto Discovery (WPAD) protocol provides browsers (primarily Windows Internet Explorer, and maybe others) with a proxy configuration file. This Proxy Auto-Config (PAC) file can configure [...]</description>
		<content:encoded><![CDATA[<p>[...] from a network. The Web Proxy Auto Discovery (WPAD) protocol provides browsers (primarily Windows Internet Explorer, and maybe others) with a proxy configuration file. This Proxy Auto-Config (PAC) file can configure [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
