Re: DNS Rebinding Prevention for the Weak Host Model Attacks

[Barry Margolin]

In article ,
 Florian Weimer  wrote:

> * Bradley Falzon:
> 
> > Craig Heffner's version of the DNS Rebinding attack, similar to all
> > DNS Rebinding attacks, requires the DNS Servers to respond with an
> > Attackers IP Address as well as the Victims IP Address, in a typical
> > Round Robin fashion. Previous attacks would normally have the Victims
> > IP Address to be their Private IP.
> 
> For which protocols is this supposed to work?  Why would a
> security-minded web application serve content under a name it knows
> cannot be its own?

Home routers generally don't have names, and they don't implement 
virtual hosting, so the programmers of the configuration interface 
presumably didn't see the need to use the Host header.

In fact, one of the recommendations in the paper that was referenced is 
that routers should check the Host header.  It should either be the 
router's hostname (if it has one) or the router's IP.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Rebinding Prevention for the Weak Host Model Attacks

[Bradley Falzon]

On Wed, Aug 18, 2010 at 1:05 AM, Phil Mayers  wrote:
> On 08/17/2010 04:31 PM, Florian Weimer wrote:
>>
>> * Bradley Falzon:
>>
>>> Craig Heffner's version of the DNS Rebinding attack, similar to all
>>> DNS Rebinding attacks, requires the DNS Servers to respond with an
>>> Attackers IP Address as well as the Victims IP Address, in a typical
>>> Round Robin fashion. Previous attacks would normally have the Victims
>>> IP Address to be their Private IP.
>>
>> For which protocols is this supposed to work?  Why would a
>> security-minded web application serve content under a name it knows
>> cannot be its own?
>>
>
> You're assuming it's an HTTP attack. You can trick flash, java and other
> plugins to circumvent the browsers same-origin policy, and do much more
> subtle things like sending SMTP email.
> ___

Just to note here, the possible prevention I am discussing will only
address this specific attack. Where an attack uses the weak host model
to circumvent DNS rebinding protection built within popular browsers
and attack the victims NAT'd router, using the IP address of their WAN
side.

You're point is still valid though, as many modems also permit Telnet
and SNMP access to the device, and allow reconfiguration via a
different protocol that doesn't check/have Host headers.

What could we legitimately break by implementing this kind of
protection, and if no obvious legitimate access could be broken, is
someone able to assist (or point me in the direction of bind-devs) in
writing a patch for bind that would do what we are proposing ?

-- 
Bradley Falzon
b...@teambrad.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Rebinding Prevention for the Weak Host Model Attacks

[Bradley Falzon]

On Wed, Aug 18, 2010 at 1:01 AM, Florian Weimer  wrote:
> * Bradley Falzon:
>
>> Craig Heffner's version of the DNS Rebinding attack, similar to all
>> DNS Rebinding attacks, requires the DNS Servers to respond with an
>> Attackers IP Address as well as the Victims IP Address, in a typical
>> Round Robin fashion. Previous attacks would normally have the Victims
>> IP Address to be their Private IP.
>
> For which protocols is this supposed to work?  Why would a
> security-minded web application serve content under a name it knows
> cannot be its own?
>

My concern about the attack is in regards to common NAT routers. I am
no expert on this subject matter and do completely agree, these kind
of routers need better security checking (such as Host Header checks),
but conversely, HTTP daemons available on embedded platforms, in my
limited experience, have been mostly HTTP 1.0 compliant only as such
do not support the Host header.

But you are completely correct is saying the devices themselves should
offer protection, the fact is though, many devices do not (even if
they are HTTP 1.1 compliant, many are simply ignoring the unknown Host
Header) and in order to upgrade these would require common people to
upgrade their modems firmware - or the ISP assisting them.

Addressing the attack as a patch in bind would allow an ISP to patch
their DNS Caches as opposed to upgrading all customers firmware. The
long term solution being as you've outlined - these NAT routers need
to offer more forms of robust protection.

-- 
Bradley Falzon
b...@teambrad.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: «tsig verify failure» only on some zones

[Hauke Lampe]

Joachim Tingvold wrote:

> During initial startup of NS3, most zones gets «tsig verify failure»,    
> but some zones are successfully transferred. All zones uses the same    
> transfer-key.

> Could this be an issue with different BIND-versions, or are there    
> other matters that could cause this?

What TSIG algorithms do you use and how long are the keys?

It could be that you hit an interoperability bug in BIND that was fixed in 
9.7.0, although it doesn't fit the symptoms exactly:

http://www.mail-archive.com/bind-users@lists.isc.org/msg04663.html

This is just hunch. I'd have no other explanation yet.


Hauke.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

«tsig verify failure» only on some zones

[Joachim Tingvold]

Hi,

I've been trying to wrap my head around this for a while now, so I  
thought I'd ask around here.


For a while, I've had two nameservers, one master (let's call this  
NS1), one slave (let's call this NS2) -- which has been working  
flawlessly. They've both run BIND 9.6-ESV-R1 on Debian Lenny, and has  
static, public IP-addresses.


I've tried to get a third nameserver (let's call this NS3) up and  
running. This one runs BIND 9.7.0-P1 on Debian Squeeze, and sits  
behind NAT (a Cisco-router, FWIW). Proper measures have been taken  
(ie; proper ports have been opened, «no-payload» has been applied,  
debug shows no packets being dropped, so I think I've ruled out this  
to be a NAT-issue -- I could be wrong, though).


During initial startup of NS3, most zones gets «tsig verify failure»,  
but some zones are successfully transferred. All zones uses the same  
transfer-key.


I pulled some logs, from both NS1 and NS3, showing what's happening on  
both sides; . For  
clarification; 80.0.0.1 is the public IP of NS3, and 90.0.0.1 is the  
public IP of NS1.


I notice that «request failed: end of file» shows up sometimes; this  
also shows up in the logs on NS2, but transfers all the zones without  
issues. NS2 has an identical config to NS3 (except other forwarders,  
etc), so I've assumed this isn't what's causing the «tsig verify  
failure». Maybe I'm wrong?


I could also mention that all three nameservers are chrooted, but  
they've all been created with the same script, so the setups are  
identical.


The timestamps from the logs differs by about ~40 seconds -- is this  
too much a variation?


Could this be an issue with different BIND-versions, or are there  
other matters that could cause this?


--
Joachim
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Rebinding Prevention for the Weak Host Model Attacks

[Phil Mayers]

On 08/17/2010 04:31 PM, Florian Weimer wrote:

* Bradley Falzon:


Craig Heffner's version of the DNS Rebinding attack, similar to all
DNS Rebinding attacks, requires the DNS Servers to respond with an
Attackers IP Address as well as the Victims IP Address, in a typical
Round Robin fashion. Previous attacks would normally have the Victims
IP Address to be their Private IP.


For which protocols is this supposed to work?  Why would a
security-minded web application serve content under a name it knows
cannot be its own?



You're assuming it's an HTTP attack. You can trick flash, java and other 
plugins to circumvent the browsers same-origin policy, and do much more 
subtle things like sending SMTP email.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Rebinding Prevention for the Weak Host Model Attacks

[Florian Weimer]

* Bradley Falzon:

> Craig Heffner's version of the DNS Rebinding attack, similar to all
> DNS Rebinding attacks, requires the DNS Servers to respond with an
> Attackers IP Address as well as the Victims IP Address, in a typical
> Round Robin fashion. Previous attacks would normally have the Victims
> IP Address to be their Private IP.

For which protocols is this supposed to work?  Why would a
security-minded web application serve content under a name it knows
cannot be its own?

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users