DNS Rebinding Prevention for the Weak Host Model Attacks

[Bradley Falzon]

I am looking at the deny-answer-* section for this, but we just need
to ensure we minimally affect legitimate applications. This is why I
was proposing we only action when the source is apart of the answer AS
WELL as another answer. Blocking based on just the source would affect
dyn-dns type applications when resolving from the source network - as
well as other applications, such as domain controllers, that maybe
querying then finding out it is themselves.

My concern is breaking current applications, for example, let's assume
example.com has dc1.example.com and dc2.example.com. Both of these
being Windows Domain Controllers. If dc1.example.com queries for the
round-robin address dc.example.com it may result in dc1.example.com
and dc2.example.com being in the answer - my proposed logic would
SERVFAIL that.

>From my understanding though, Windows DC's are usually deployed
managing their own DNS, so I don't think this would normally happen -
but - is there an example where this is widely deployed and possible
to impact applications ?

If it can impact applications, but it's very small, an opt-out service
could be possible. Alternatively, simply logging maybe good enough.
But I still feel within bind would be a great place for this checking
to occur.

On Thu, Aug 19, 2010 at 1:51 AM, Kevin Darcy <kcd at chrysler.com> wrote:
> deny-answer-addresses { %source%; };
> deny-answer-aliases { %source%; };
>
> Maybe?
>
>                                        - Kevin
>
> On 8/17/2010 12:22 AM, Bradley Falzon wrote:
>>
>> bind-users,
>>
>> In light of Craig Heffner's recent Black Hat talk (here:
>>
>> https://media.blackhat.com/bh-us-10/whitepapers/Heffner/BlackHat-USA-2010-Heffner-How-to-Hack-Millions-of-Routers-wp.pdf
>> and here: http://rebind.googlecode.com) I would like to propose a
>> possible solution in line with the 'DNS rebinding attack prevention'
>> provided in version 9.7.
>>
>> 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.
>>
>> BIND, in version 9.7, developed two new options: deny-answer-addresses
>> and deny-answer-aliases. Within these ranges an ISP or Corporation
>> could put in the list of RFC1918 Addresses or other address clients
>> should never be resolving to. However, Craig's attack would bypass
>> these rules: the Victims IP is actually the Victims WAN IP - not their
>> internal address. An ISP would be unable to place their entire IP pool
>> into the 'deny-answer-*' options, allocated to customers, because this
>> would break many legitimate uses.
>>
>> I would like to know though, what if bind was given the option that
>> allowed an ISP to block and/or log DNS requests (again with a
>> SERVFAIL), based on if the query-source was in the response along with
>> at least one other address.
>>
>> Basically:
>>
>> if ( query.source = query.result[0]&&  count(query.result)>  1 ) {
>>    return (servfail)
>> }
>>
>> If the Source IP of the client was also at least one of the results,
>> log and return a SERVFAIL. The rule would permit queries with a single
>> response.
>>
>> Craig Heffner's method is serious for ISP's that supply their
>> customers modems that are vulnerable. The proper protections on the
>> customers modems would be a logistical nightmare.
>>
>> Placing these protections, along with the current DNS Rebinding
>> protections already in 9.7 would be a great step forward in
>> realistically protecting these types of attacks.
>>
>> I would propose "three" parameters for this. The first mode being
>> completely off (and I assume the default); the second, Permissive,
>> would only log the attacks; the third, Enforcing, would log and block
>> the attacks.
>>
>> This would allow ISPs to upgrade to these specific versions of bind,
>> turn on Permissive parameter first and Enforcing if the attacks become
>> well known or impact is minimal.
>>
>> What are your thoughts on this ? What could these protection break the
>> legitimate use for ?
>>
>>
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Bradley Falzon
brad at teambrad.net