Vulnerability to cache poisoning -- the rest of the solution

[Jeff Lightner]

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.
> ----------------------------------
>