Bell Canada is safe

The article incorrectly states that Bell Canada is vulnerable. I used the test when I first heard about the problem and it said everything was fine. Just re-checked with the same result. As much as I despise Bell, they must have done the right thing. Either that, or the tool to check for the exploit is not working properly.

Re: "port range too narrow" or "ports may follow a predictable pattern"

Anonymous Coward said:

"Does this mean that subscribers who are getting the "port range too narrow" or "ports may follow a predictable pattern" test error are using name servers that are not patched properly?"

Well, my latest tests of Demon produce:

"Your ISP's name server, 194.159.187.38, appears to be using the name server written by Nominum, which has effective protection against the newly discovered attacks despite the limited port range. Nominum is working to expand the port range for even greater protection, but there is no reason for concern at this time."

but also

"Your name server, at 194.159.187.34, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 171."

(which is the same as previously reported for this server)

So now I'm confused. Are Demon using different versions of Nominum on different servers? Or is their patching not complete? Perhaps someone who is more savvy than me could explain what's going on here.

Firewalls

"Demon Internet was reported as potentially being vulnerable, because a Firewall or NAT in front of the DNS server "appears to be interfering with its port selection policy," according to Kaminsky's test."

I would guess Demon's firewalls INTENTIONALLY interfere with the port selection. Our Checkpoint firewalls alter both the port and the Id number used, specifically to mitigate the issue under discussion (and the server guys have applied the necessary patch) but the Check My DNS site still thinks we are vulnerable.

Swisscom's server vulnerable

Your name server, at 195.186.1.110, appears vulnerable to DNS Cache Poisoning.

All requests came from the following source port: 47043

Swisscom (Switzerland) primary DNS server for ADSL customers

Limited port ranges

My understanding is that if you randomise the port but only within a range of (say) 256 ports, then you have 24 bits of randomness including TXID. So even if the attacker can only get one packet in before the valid response, then they have a better than 1 in 17 million chance of success. According to Kaminsky's blog, the attacker can make a couple of thousand attacks (on different subdomains) per second - presumably this depends mostly on connection speeds. 8 thousand seconds is over 2 hours.

Now, 2 hours is a moderately long time to flood a server without anyone noticing. It's a very long time if there's something looking for such attacks in real time, although what a server can usefully do if it detects a series of attacks I'm not sure.

However, if my rough calculation is orders of magnitude out in the bad direction (for instance, suppose the attacker can reliably get 100 spoof responses in before the genuine response) then I don't see how the protection is adequate. It might take under a minute of activity to poison a DNS cache. That activity might conceivably be distributed across time and/or a botnet to reduce the chances of detection. If a large botnet were to devote its time to attacking such "24 bit" DNS servers, then it would successfully poison some of them, wouldn't it?

Perhaps Kaminsky can explain why a range of a couple of hundred ports is good enough. I haven't analysed the issue at all, I'm just repeating what I've read from Kaminsky and others. But my suspicion is that the warning is there for a reason, and the reason is that a narrow port range is not a full fix.

On the NAT issue: it doesn't matter whether the port randomisation is done by the DNS resolver or by the NAT, except that:

1) If the resolver is less random than the NAT, then you're somewhat more vulnerable to an attacker inside the NAT than outside (this is what happens if the NAT is fixed and the resolver isn't).

2) If the NAT constricts the port range of the resolver, then you're somewhat more vulnerable to an attacker outside the NAT than one inside.

Combining the two cases, if there are attackers both inside and outside the NAT then you're as protected as the worst case of port predictability. So what we want is for all resolvers and all NATs to randomise ports across as wide a range as possible.

Presumably if there's a "bad" NAT between you and a "good" DNS server, then Kaminsky's test would report you clean (because it only sees the requests from the fixed caching resolver), but actually you'd be vulnerable even if the non-caching resolver in your OS is patched, because the randomised port choice is rendered predictable by the NAT. So depending on network topology, there may be cases where your own domestic firewall/router makes you vulnerable to an attacker inside your ISP's subnet, even though everything else is fixed. Do ISPs route packets directly from one customer IP to another? What brands of firewall/router randomise ports adequately?

I'm sure Kaminsky will have all the answers at Black Hat. Or someone else will provide them sooner.

As expected

Your name server, at 80.58.61.250, appears vulnerable to DNS Cache Poisoning.

Telefonica couldn't care less about its subscribers. Fortunately the show equal care as to what their subscribers do.

Need a black Pais icon

I am ashamed of you ElReg - only a white Paris? Please make an icon out of this so we can truly express our opinions:

w w w.rude.com/steverudeman - take out the spaces

Not all of Telus is ok

Only certain regions. Also at risk in Canada are Navigata and Westel:

204.244.3.129

204.244.3.130