So there's been quite a bit of press around Dan Kaminsky's DNS vuln today and the associated patches. I even made comments earlier today about the severity of it. Now, however, I'm starting to reconsider. I'm not sure that this is the horror scenario that the press is making it out to be... and I'm not the only one that feels this way.
Now Dan is a bright guy... there's no doubt about that... I saw him talk at SecTOR (I even had the opportunity to have a couple of drinks with him) and I'm really looking forward to his talk at BlackHat, but I just don't see the seriousness here.
The patch changes the number of potential source ports (from 2500 to 16383 (assuming that MaxUserPort is not set)). It also makes it so the Transaction ID (2^16) and the Souce Port *MUST* match. That takes us from 163,840,000 combinations to 1,073,676,288 combinations. I realize that the second number is a good deal bigger (and could potentially be quite a bit larger (if MaxUserPort = 65535 we'd be looking at 4,227,792,896 combinations) but does it really matter that much? This is spoofing, which to me implies that we're not sniffing the traffic and knowledgable of the Transaction ID and Source Port (if that were the case the randomness wouldn't amtter). This means we're talking about randomly submitting data and essentially flooding out valid responses, at least that's my assumption... maybe Dan's presentation will cover something else and this will end up being really cool. However, sticking with the random attempts to generate valid data, even before this patch, 163,840,000 is a lot of potential combinations to have to attempt. It seems to me that the likelihood of this being a problem is fairly minimal... almost to the point of being non-existent. I guess we'll have to wait for BlackHat to see for sure.
As a second thought, everything addresses UDP source ports... I wonder if the same issue was fixed, overlooked or not-affected with TCP. Anyone have any thoughts on this?
Another note, SANS ISC has a post saying that a GSEC Student found this 3 years ago. This is incorrect. If you look at the DNS Client it increments the port for each subsequent query.
Example:
279 27.184611 192.168.218.100 192.168.218.2 DNS Standard query A computerdefense.org
User Datagram Protocol, Src Port: 10044 (10044), Dst Port: domain (53)
Source port: 10044 (10044)
Destination port: domain (53)
Length: 45
Checksum: 0x1547 [correct]
Domain Name System (query)
Transaction ID: 0x0002300 29.536560 192.168.218.100 192.168.218.2 DNS Standard query A ncircle.com
User Datagram Protocol, Src Port: 10045 (10045), Dst Port: domain (53)
Source port: 10045 (10045)
Destination port: domain (53)
Length: 37
Checksum: 0xe304 [correct]
Domain Name System (query)
Transaction ID: 0x0003
Comments (1)
I'm curious what the vulnerability exactly is as well.
I know Dan does a lot of research that involves huge amounts of scanning across many servers and domains using huge pipes and big servers, so...it's possible he found out it is easier than originally thought to poison caches. That could simply be it.
And in doing so, already has a script that can leverage the issue and poison vulnerable DNS caches at will using any URL. Even though that shouldn't be new, the disclosure of such a script would likely elicit a patch response like this.
That and maybe he's getting listened to since he's pretty well known. :)
But no, I have not seen or felt the upheaval of the Internet today, nor has DNS crumbled to the ground, so I don't think it's amazingly critical or fatal, but simply possible. I'm so far assuming it is similar to what you describe above: simple brute forcing.
Posted by LonerVamp | July 9, 2008 2:58 PM
Posted on July 9, 2008 14:58