Vulnerability to cache poisoning -- the rest of the solution

Chris Buxton cbuxton at menandmice.com
Fri Jul 11 18:59:05 UTC 2008


Correct. The new, random port is set by the outbound query as its  
source port. The return response goes to the same port that the query  
came from.

Chris Buxton
Professional Services
Men & Mice

On Jul 11, 2008, at 11:53 AM, Jeff Lightner wrote:

> Thanks.
>
> RHEL has released a patched version of the BIND 9.x they distribute.
> I've already contacted management about the need to do this.
>
> Since we're in the middle of a PCI compliance push it will likely be
> easier for me to get this implemented than it might have been in the
> past.
>
> I saved the DNSSEC in 6 minutes PDF posted earlier and will look to
> implement that long term beyond doing the patch.
>
> Just so I have it straight:
> The firewall change required is only to allow OUTBOUND random ports?
> That is, the connection once established would stay on the port
> initiated by my server and wouldn't require an INBOUND connect back  
> on a
> separate random port?
>
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Chris Buxton
> Sent: Friday, July 11, 2008 2:38 PM
> To: bind-users at isc.org Mailing List
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
> solution
>
> Jeff,
>
> You haven't yet figured out the attack vector, or the goal of the
> attack.
>
> If your name server is used by client machines to look up outside
> names, then your server is at risk. The risk is that someone will
> manage to convincingly forge a response to your name server's outbound
> query, thus causing your name server to believe something untrue and
> cache it. This cached data is then used to attack you and your users,
> e.g. directing you to the attacker's clone of PayPal instead of to the
> real thing. (They still won't have a valid PayPal SSL certificate, but
> if you don't put the "https://" into the URL in your browser, you may
> never notice that.)
>
> It doesn't matter if you have recursion restricted - as long as
> recursion is enabled for some user, then your server is subject to
> these attacks. If you turn it off, then it is not at risk. The attack
> does not threaten the actual operation of the name server, it
> threatens the pool of users who send recursive queries to the name
> server.
>
> However, that said, this attack is not new. The weakness addressed by
> this latest patch is not some new revelation - it's something we in
> the community have known about for years. It's just that Dan Kaminsky
> is presenting a paper next month at Black Hat telling the world how to
> exploit it.
>
> To convince your name server that a bogus response is real and
> correct, the attacker must get the following values right:
>
> - The source address and port of the query.
> - The destination address and port of the query.
> - The query ID.
> - The query name, class, and type.
>
> If the attacker has a packet sniffer somewhere upstream of you, you're
> dead in the water. He can sniff these values and forge a response on
> the spot. Otherwise, however, he has to guess or determine all of  
> that.
>
> The source address of the query is, of course, your server's address.
> If the attacker is trying to spoof paypal.com, then there is a small
> number of destination addresses, the name servers for paypal.com, and
> also the query name/class/type triplet is known. The destination port
> is 53. These should be the only known quantities, ideally.
>
> There have been several recent security updates to BIND relating to
> the query ID not being sufficiently random. In fact, in some cases, a
> low-traffic server's next query ID could be predicted accurately, over
> and over.
>
> Now we have publication of the fact (long-known by those of us who
> teach this subject) that the source port used for queries is knowable
> - all the attacker needs to do is set up a name server to be
> authoritative for some zone, and then wait (or cause) your name server
> to look up that data. His server will then log the source port used
> for queries. Until this latest patch, BIND chooses a single source
> port at startup and sticks with it. The latest patch makes this port
> random for each query, although the side effects of this may be
> intolerable for some installations. (If I may suggest to the folks at
> ISC, perhaps an option to put a rate limit on the frequency of changes
> - N times per second, for example - would solve this. And for
> goodness' sake, be a little more aggressive about closing ports after
> some time has passed.)
>
> Combine a weak or predictable query ID with a known source port and
> the attacker has an easy time spoofing a response - he just has to
> keep sending responses to your server and wait for some valid user to
> try to look up the targeted RRSet. (There is some effort required to
> keep updating his knowledge of your query ID random number pool's
> state, but in some cases that's not much of a barrier.)
>
> Because these two variables are the only ones we can really
> strengthen, it becomes very important for the DNS server vendors out
> there to do so. Both values are constrained to 16-bit values, so we
> max out the difficulty to a 32-bit random number - not very secure by
> modern standards. As it was before this latest patch, however, it
> became effectively a 16-bit random number once a small amount of
> effort was completed.
>
> Now consider the value of DNSSEC, in which we augment this with, say,
> a 1024-bit cypher. Your (at best) 32-bit key has now become (at least)
> a 1024-bit key. And it's all validated by multiple cross-checks.
>
> Chris Buxton
> Professional Services
> Men & Mice
>
> On Jul 11, 2008, at 10:21 AM, Jeff Lightner wrote:
>
>> Thanks.
>>
>> Forgive me for being dense but I'm trying to understand.
>>
>> Is the "cache poisoning" poisoning of our name servers' cache or of
>> name
>> servers that our recursive queries are using for resolution of
>> external
>> sites (e.g. google.com, yahoo.com, billybob.com)?
>>
>> When you say allowing recursion is the issue are you saying that in
>> the
>> sense that there is a risk from internal sabotage as there is from
>> internet hackers or are you saying simply having it on for internal
>> users somehow also would allow internet hackers to exploit it?
>>
>> Reading your final paragraph makes it seem like you mean it is the
>> latter.
>>
>> Just to make sure I understand recursion:  My assumption is that
>> this is
>> necessary to do lookups for zones for which we are not authoritative
>> like the examples above.   Is that correct?
>>
>> -----Original Message-----
>> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
>> Behalf Of Alan Clegg
>> Sent: Friday, July 11, 2008 12:44 PM
>> To: bind-users at isc.org
>> Subject: Re: Vulnerability to cache poisoning -- the rest of the
>> solution
>>
>> Jeff Lightner wrote:
>>> I had thought turning off cache queries to external lookups was
>>> sufficient.   Are you saying this is needed in addition or that  
>>> cache
>>> query disabling had nothing to do with the cache poisoning?
>>
>> If your server is authoritative only, it is not at risk.  If it is
>> recursive, it is at risk.
>>
>> It's not allowing queries from outside your network that puts you at
>> risk, it's doing recursion on behalf of others (internal or external)
>> that opens you to the vulnerability.
>>
>> If you recurse, install new code and don't limit your queries to a
>> single port.
>>
>>> Also as to the randomization - is this only for outbound responses?
>> The
>>> initial query would have to come on port 53 where named listens or
>>> are
>>> you saying that it somehow listens on random ports as well?
>>
>> This randomization is of queries being sent out from recursive  
>> servers
>> on behalf of the system that sent the query with the recursion  
>> desired
>> "RD" bit set.
>>
>> All DNS queries will have a destination of port 53.  You just don't
>> want
>> all of the queries to have the same SOURCE port.
>>
>> AlanC
>> ----------------------------------
>> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
>> confidential information and is for the sole use of the intended
>> recipient(s). If you are not the intended recipient, any disclosure,
>> copying, distribution, or use of the contents of this information is
>> prohibited and may be unlawful. If you have received this electronic
>> transmission in error, please reply immediately to the sender that
>> you have received the message in error, and delete it. Thank you.
>> ----------------------------------
>>
>
>
>



More information about the bind-users mailing list