<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Mark Goodwin&#039;s Blog - dns tag</title>
  <link>http://directwebremoting.org/blog/mark/tags/dns/</link>
  <description>Security, information, miscellanea</description>
  <language>en</language>
  <copyright>Mark Goodwin</copyright>
  <lastBuildDate>Thu, 16 Aug 2007 22:02:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Does Firefox implement DNS Pinning?</title>
    <link>http://directwebremoting.org/blog/mark/2007/07/19/does_firefox_implement_dns_pinning.html</link>
    
      
        <description>
          &lt;p&gt;
I&#039;ve been playing around with DNS pinning over the past few weeks; mainly on how the presence of proxies affects the story, which Rsnake and Portswigger &lt;a href=&#034;http://ha.ckers.org/blog/20070710/dns-pinning-affects-proxies-too/&#034;&gt;beat  me to&lt;/a&gt; (nice work guys), but also on various other bits.
&lt;/p&gt; 
&lt;p&gt;
Something that&#039;s caught my attention, especially following &lt;a href=&#034;http://blogs.msdn.com/dross/archive/2007/07/09/notes-on-dns-pinning.aspx&#034;&gt;David Ross&#039; comments&lt;/a&gt; on how IE does not actively implement DNS Pinning, is that the Firefox&#039;s DNS Pinning behaviour (if it does it at all) is rather interesting:
&lt;/p&gt;
&lt;p&gt;
It seems that all you have to do to make Firefox rebind is wait a minute or two.  The normal explanation of how the attack needs to work is as follows:
&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;i&gt;Client&lt;/i&gt; is fooled to request a page from &lt;i&gt;attacker&lt;/i&gt;, &lt;i&gt;client&lt;/i&gt;&#039;s resolver looks up &lt;i&gt;attacker&lt;/i&gt; and is told that &lt;i&gt;attacker&lt;/i&gt; is at yyy.yyy.yyy.yyy.&lt;/li&gt;
&lt;li&gt;&lt;i&gt;Client&lt;/i&gt; requests a page from &lt;i&gt;attacker&lt;/i&gt; (at yyy.yyy.yyy.yyy) and is returned a page containing a script which tells &lt;i&gt;client&lt;/i&gt; to come back later&lt;/li&gt;
&lt;li&gt;Once this is served, &lt;i&gt;attacker&lt;/i&gt; changes its DNS so the RR for &lt;i&gt;attacker&lt;/i&gt; now points to zzz.zzz.zzz.zzz.  &lt;i&gt;Attacker&lt;/i&gt; also firewalls off its webserver.&lt;/li&gt;
&lt;li&gt;When &lt;i&gt;client&lt;/i&gt; comes back to refresh the page (or whatever the script told it to do) it discovers the server is down and rebinds DNS&lt;/li&gt;
&lt;li&gt;&lt;i&gt;Client&lt;/i&gt; then connects to what it thinks is &lt;i&gt;attacker&lt;/i&gt; but which is actually the machine at zzz.zzz.zzz.zzz&lt;/li&gt;
&lt;li&gt;The script served to &lt;i&gt;client&lt;/i&gt; by &lt;i&gt;attacker&lt;/i&gt; can now read content from zzz.zzz.zzz.zzz and pass it on however the attacker wishes&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;
It seems that with the Firefox behaviour, &lt;i&gt;attacker&lt;/i&gt; no longer needs to carry out the firewalling step; it simply needs to serve a script which is told to wait for something between 80 seconds and 2 minutes.  The amount of time seems to change; I suspect the browser has a resolver cache which is cleared periodically but I&#039;ve not really looked to find out whether this is the case. 
&lt;/p&gt;
&lt;p&gt;
This has some interesting implications:
&lt;ul&gt;
&lt;li&gt;If you don&#039;t need to firewall off the webserver, it&#039;s much easier to make use of more than a single host; many targets of this type of attack will sit NATed behind a firewall, and even selective firewalling would block other potentially useful client machines&lt;/li&gt;
&lt;li&gt;
The &lt;a href=&#034;http://seclists.org/fulldisclosure/2007/Jul/0159.html&#034;&gt;original &#039;Princeton&#039; attack&lt;/a&gt; on applets (and presumably various browser plugins) can perhaps still be made to work without relying on a proxy just by timing things right.
&lt;/li&gt;
&lt;/ul&gt;
&lt;/p&gt;
&lt;p&gt;
I&#039;m sure the rabbit hole goes much deeper than this. Let&#039;s see what happens.
&lt;/p&gt;
&lt;p&gt;
&lt;b&gt;Update:&lt;/b&gt; In my tests I&#039;m sending responses to the original request to &lt;i&gt;attacker&lt;/i&gt; with &lt;code&gt;Connection: close&lt;/code&gt;; maybe this is affecting the behaviour?
&lt;/p&gt;
&lt;p&gt;
&lt;b&gt;Update 2:&lt;/b&gt; Having tested my theory on applet attacks; I think this is not possible.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <comments>http://directwebremoting.org/blog/mark/2007/07/19/does_firefox_implement_dns_pinning.html#comments</comments>
    <guid isPermaLink="true">http://directwebremoting.org/blog/mark/2007/07/19/does_firefox_implement_dns_pinning.html</guid>
    <pubDate>Thu, 19 Jul 2007 18:27:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>
