Well no one ever implied that Dan Kaminsky was the first person to know about these vulnerabilities. He made them public, and the bad guys are just getting their returns in while the getting is good. Who knows how long these holes have been in use for.
By KincaidPosted Thursday 31st July 2008 19:46 GMT
I saw that Time Warner & Roadrunner were both deemed unpatched the last I checked. I use OpenDNS instead which is protected according to the DoxPara DNS Checker.
By Glenn BoothPosted Thursday 31st July 2008 20:10 GMT
I didn't expect anything different, but Zen Internet's DNS services are all in the green. I hit both 212.23.3.100 and 212.23.6.100 - they've done their job; source port randomness abounds.
By Anonymous CowardPosted Thursday 31st July 2008 20:31 GMT
DNS gets attacked all the time, maybe someone else just spilled their version.
He should have created a encrypted file with the details and publicly posted it.
So who knows.
Thing is people will use the known exploits just as they emerge, the chaos helps to cover tracks. I still think what he has done is a bit irresponsible, DNSSEC has been preventing these attacks for a while, and the latest bind patch was available before this went public. So, what we have here is a known attack given a lot of publicity.
Well, if the sec guys can keep up with the numbers, they may find quite a few of the crackers, but this has upped the volume.
By Steve Evans (a different one)Posted Thursday 31st July 2008 21:27 GMT
Newnet seems to be ok
Your name server, at 212.87.64.7, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).
1. 195.8.69.7 (resolver1.uk.clara.net) appears to have GOOD source port randomness and GREAT transaction ID randomness.
2. 80.168.69.20 (resolver3.clara.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
I like my ISP, not cheap, not throttled either. No apparent port blocking. Local call rate support. Just in case anyone wants to jump ship from any Phormised ISP.
By ChronosPosted Thursday 31st July 2008 22:56 GMT
Yes, they're vulnerable. The transaction ID is irrelevant as it is guessed by the attacker with chances of a hit being one in 65536 per shot. The crux of the matter is a static upstream query port on the recursive server being queried, allowing the attacker to both send unique unresolvable queries within the target domain (1.example.com, 2.example.com...) to port 53 AND know which port the server is listening for an answer on. He then fires answers at it pretending to be the server the resolver is querying (remember, this is UDP. No state, easy to spoof, no reply needed once you get an answer accepted). You only need to guess the transaction ID correctly once and then you've polluted the cache for the entire example.com domain for however long you set that answer's TTL to (or the cache lifetime, whichever is smaller) by dint of in-bailiwick answers always being accepted for the whole domain. All the real example.com DNS servers will send back is NXDOMAIN, which doesn't get cached so you have, in effect, limitless query headroom to get the transaction ID correct without the risk of the real servers populating the cache first.
What the patch does is enable the server to use a random source port for every query in a recursive search, spoiling the cracker's ability to track which port the server expects a response on, thus giving the cracker no opportunity to insert his own bogus answers. It is, unfortunately, security by obscurity. We need signed roots and DNSSec. DNS is and always has been insecure. It's only a matter of time before more holes are found and this whole song and dance commences yet again. Of course, that implies ISPs will care enough to set up trust anchors, but that's a discussion for another day.
By the way, if anyone thinks adding 1 IN A x.x.x.x, 2 IN A x.x.x.x etc. to their zones is a defence, just ponder the use of very small shell scripts, uuidgen and sed to create the hostnames to query. I'm sure you'll agree that this idea is no defence at all. The hostname used is just a simple way of explaining the exploit. Even your run-of-the-mill skiddie isn't going to be that obliging. Patch. Now.
Note: In order to utilize the query port randomization to mitigate the weakness, you need to make sure that your network setup allows the DNS server to use random source ports for query and that you have not set a fixed query port via the "query-source port" directive in the BIND configuration.'
So did you check your "query-source port" directive in BIND?
By Anonymous CowardPosted Friday 1st August 2008 05:46 GMT
Re: Verizon
Thanks for the explaination about port versus transaction randomness.
The thing about all this that really boils my bottom is that even though I have bothered with a home router, firewall, anti-virus and such for years my IS-freaking-P's unpatched DNS could render such preparations moot.
Alas, poor internet, I knew it Horatio. A place of infinite wit and zest.<holding 4-port router, talking to it>
By System AdministratorPosted Friday 1st August 2008 06:44 GMT
DIG: "62.6.40.162 [indnsc70.ukcore.bt.net.] is POOR: 26 queries in 3.8 seconds from 25 ports with std dev 271"
WEB Version: POOR source port randomness GREAT transaction ID randomness.
I get the POOR source port warning whatever test I use. I run my own LAN and LAMP setup via my otherwise vanilla BT Broadband connection (via HomeHub).
I suspect other factors rather than BT's DNS may be involved in the results - it would be great if someone could give us a clue and briefly explain what may restrict source port randomness. I have a clue (NAT/Firewall etc) but some folk out there actually 'know' :-)
OR - should I rely on the test and BT *are* actually POOR/GREAT rated!
Your name server, at 209.179.23.207, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).
Check your named.conf for "query_source" and remove/comment that line. Other possible causes are the rc script calling rndc reconfig rather than kill/exec, which will leave the running process resident and just cause it to re-read the config. Manually /etc/init.d/named zap && /etc/init.d/named start (or is it /etc/init.d/dns on Genitals? I forget...) as big bad root. You may also have a firewall/router in the path of the 'net connection undoing all your nice port randomness.
By WokstationPosted Friday 1st August 2008 09:14 GMT
"Your ISP's name server, 80.3.128.148, has other protections above and beyond port randomization against the recently discovered DNS flaws. There is no reason to be concerned about the results seen below.Requests seen for a563cec7b068.doxdns5.com:
By Paul TaylorPosted Friday 1st August 2008 09:36 GMT
quoth www.doxpara.com, "Your name server, at 194.106.56.6, appears vulnerable to DNS Cache Poisoning. All requests came from the following source port: 32785"
By Adrian WaterworthPosted Friday 1st August 2008 10:01 GMT
Although the standard deviation test for randomness seems to give BT a POOR rating all the time, if you look at the scatter plots, there don't seem to be any obvious patterns (leastways there weren't when I ran the tests here), so I suspect that the BT servers are probably patched for this one.
Perhaps they have some way to limit the port range that they use in requests/responses, so it's a random selection from a (relatively) small pool - hence POOR as far as a standard deviation test is concerned?
Orange. On the DNS-OARC test, the source ports for the 2 Orange DNS's looked nonrandom. The plots of Source ports showed two parallel lines. This happened both for 193.36.79.100 (cache0.orange.net) and 193.36.79.101 (cache1.orange.net). The transaction ID plots are well scattered for both IP addresses. As Simon van der Walt reported, DNS-OARC says the results are great, but advises an eye check for randomness. Doxpara thinks the DNS's are ok, but advises a check for pattern and DNS-OARC shows the pattern.
Seeing as o2 data are 'aware of the situation' but seemingly unwilling to do anything about it, they are still wide open (193.113.200.171) so anyone browsing the net on an iPhone could start to have fun in the very near future.
You can only imagine the fun I had trying to get an answer out of them on the phone about when they were going to patch, and no, not the phone, the server...
By Richard KayPosted Friday 1st August 2008 10:45 GMT
1. 194.168.8.110 (winn-dnsbep-2.server.virginmedia.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 194.168.8.109 (winn-dnsbep-1.server.virginmedia.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
Looking at the scatter plots it appears the source ports are randomised but within a very narrow range of 200 or so as opposed to the range of 65,000 or so which should be used. So the source port randomisation combined with the transaction ID randomness gives 8 + 16 = 24 bits of entropy compared to the 32 bits maximum possible. It is possible that Virgin Media may have other defences, e.g. against domains showing suspicious UDP packet storms involving many subdomains over a short duration.
By System AdministratorPosted Friday 1st August 2008 11:23 GMT
"which idiot's idea was it to post vulnerable DNS severs here?!?"
Strong words based on a shallow analysis of the situation I feel.
a) The patch is available and, given it's severity, should have been implemented by now by anyone taking our money for ISP services - notwithstanding the possible costs or impact on network performance.
b) It's inevitable the 'baddies' will have access to this comments section - but that's offset by us mere mortal users being able to concur here and find out if we have a vulnerable ISP - there is no other source of reliable information other than the likes of this.
c) Do you honestly believe the 'black hat' community doesn't already have a comprehensive list already?
d) It's an unfortunate fact of life that an attack on an ISP, or an increase in suspicious traffic, is more likely to spur them to patch than a very clear technical warning - which they have already had.
Yes - on the face of it this exercise may appear foolish although to say so is plain crass. I see no horse in this stable - therefore I'll leave the door open as it stinks in here ....
By vagabondoPosted Friday 1st August 2008 12:53 GMT
194.106.56.6 was deprecated as a Freedom2Surf nameserver last November. They changed to 212.139.132.44 and 212.139.132.43, which were patched some time ago. If your router gets its nameservers dynamically it would have updated itself.
By Bruce OrdwayPosted Friday 1st August 2008 13:21 GMT
Your ISP's name server, 68.87.77.132, has other protections above and beyond port randomization against the recently discovered DNS flaws. There is no reason to be concerned about the results seen below.Requests seen for 1c512a407263.doxdns5.com:
Your name server, at 70.52.198.134, appears vulnerable to DNS Cache Poisoning.
Recursion - So Why This Focus on 'Your' DNS Servers? #
By PhilPosted Friday 1st August 2008 14:08 GMT
Whether or not 'my' DNS server is patched, if it queries an unpatched server for the IP of an unknown domain and the unpatched server has been poisoned for this domain then surely 'my' DNS cache becomes poisoned too.
By Ose PedroPosted Friday 1st August 2008 17:01 GMT
Suppose someone tries to visit an online banking site, and a rogue DNS server directs them to a counterfeit page. Presuming the creators of that page haven't compromised the bank's public/private key pair, they won't be able to provide a valid security certificate for the login procedure. Hence the lack of security certificate should immediately alert the visitor to the page's inauthenticity. So as long as we always check for valid certificates before logging in, our bank details etc. will remain clear of prying eyes, no?
By Johnny UtahPosted Friday 1st August 2008 19:34 GMT
When I originally tried the test on DoxPara, it said my name server looked ok, but to check that the port numbers didn't appear to follow a predictable pattern, which some of them did. Now it says "Your name server, at 71.250.0.38, 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 65."
These are the results of the other test:
1. 71.250.0.36 appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 71.250.0.38 appears to have POOR source port randomness and GREAT transaction ID randomness.
3. 71.250.0.39 appears to have POOR source port randomness and GREAT transaction ID randomness.
I do things like pay my bills online, so the other day I called my ISP, FairPoint, to ask if they had addressed this problem. The number on their website actually connected me to Verizon tech support (from whom FairPoint recently bought the phone / internet business in this area). I spent something like an hour on the phone with them doing a lot of waiting and getting bounced around from person to person, and ultimately I got no information. The tech support people at this company are morons and had no idea what I was talking about and were unable to put me in touch with anyone who did.
So what do these results mean, am I in good shape or not?
moved my router to OpenDNS and got better results #
By Paul MurphyPosted Friday 1st August 2008 21:02 GMT
The VM defaults were;
Ok on doxpara, and
poor/great on www.dns-oarc.net,
so I changed to OpenDNS servers;
doxpara seemed just as happy and
great/great on www.dns-oarc.net,
so happier here - unless this is all a great con and now my home network is getting added to another Bots'R'Us swarm.
By Joseph HelenihiPosted Friday 1st August 2008 23:20 GMT
"offset by us mere mortal users being able to concur here and find out if we have a vulnerable ISP - there is no other source of reliable information other than the likes of this."
Precisely stated logic, the mainstay of all that is computing. The fact that it was posted to El Reg solidifies the argument very nicely.
Everyone else on here with an ISP using unpatched DNS and a story like Johnny Utah's should go to the OpenDNS site. Simply point your router or dialup client application to the safe DNSs offered therein.
Waiting for a fix from a hamhanded ISP who simply wants your money at the expense of your security deserves neither. But, if they are the only game in town, you don't have to use their dodgy DNSs. You will likely have to reboot your router, and or your PC to get the new DNS addresses to work.
By Andrew GallagherPosted Saturday 2nd August 2008 00:35 GMT
doxpara: Your ISP's name server, 89.101.160.5, has other protections above and beyond port randomization against the recently discovered DNS flaws.
dns-oarc: 1. 89.101.160.4 (ie-dub01a-dns01.upc.ie) appears to have GOOD source port randomness and GREAT transaction ID randomness. Test time: 2008-08-02 00:08:05 UTC
By Jim MorrowPosted Saturday 2nd August 2008 14:32 GMT
>> Whether or not 'my' DNS server is patched, if it queries an unpatched server for the IP of an unknown domain and the unpatched server has been poisoned for this domain then surely 'my' DNS cache becomes poisoned too.
No. The only way your server should query an unpatched server is when it is asking that unpatched server for authoritative data: ie when your server queries one of the name servers for google.com (say). Even if that google.com name server is unpatched, it will be serving authoritative data that it has loaded from disk. When it does that, the data it loads cannot be compromised by a cache poisoning attack. Besides, most authoritative servers don't *make* queries, they just answer them. If a DNS server doesn't make queries, it can't be spoofed and can't have its cache poisioned. Largely because it doesn't have a cache.
I've used the Paris icon because even she knows how DNS works
I think it's more a question of "How do you keep idiots entertained?" - The answer, of course, give them a page that tells them "<ip address> appears to have POOR source port randomness and GREAT transaction ID randomness.
Next week's article "Twenty years reading my zone alarm log and other internet pastimes"
By Anonymous CowardPosted Sunday 3rd August 2008 03:51 GMT
Your ISP's name server, 24.200.241.97, has other protections above and beyond port randomization against the recently discovered DNS flaws. There is no reason to be concerned about the results seen below.
By Anonymous CowardPosted Monday 4th August 2008 08:35 GMT
Rogers - Canada - Too busy counting money - no time to patch....
Your name server, at 64.71.246.85, appears vulnerable to DNS Cache Poisoning.
All requests came from the following source port: 34212
Due to events outside our control, details of the vulnerability have been leaked. Please consider using a safe DNS server, such as OpenDNS. Note: Comcast users should not worry.Requests seen for 61c747213638.doxdns5.com:
Breaching Fort Apache.org - What went wrong?
Snow Leopard security - The good, the bad and the missing
US Dems fill inboxes with 419 scams
BlockMaster SafeStick hardware-encrypted USB drive
Comments on: Black hats attack gaping DNS hole
Whaaat #
By nick Posted Thursday 31st July 2008 18:16 GMT
PlusNet look to be patched. #
By Neil Woolford Posted Thursday 31st July 2008 18:39 GMT
Eclipse seems Ok #
By Dave Morgan Posted Thursday 31st July 2008 18:42 GMT
shure, Y nought? #
By bob, mon! Posted Thursday 31st July 2008 18:44 GMT
gasp #
By Alan Posted Thursday 31st July 2008 18:48 GMT
Virgin Media #
By Anonymous Coward Posted Thursday 31st July 2008 18:57 GMT
BT Broadband #
By David Jones Posted Thursday 31st July 2008 19:02 GMT
Comcast - Great Lakes Region #
By Richard Conto Posted Thursday 31st July 2008 19:04 GMT
ADSL24 #
By Test Man Posted Thursday 31st July 2008 19:18 GMT
eek #
By ben edwards Posted Thursday 31st July 2008 19:45 GMT
OpenDNS #
By Kincaid Posted Thursday 31st July 2008 19:46 GMT
Road Runner #
By Andrew Tyler Posted Thursday 31st July 2008 19:47 GMT
aanet - australia adsl #
By Lee T. Posted Thursday 31st July 2008 19:56 GMT
Well done Zen. #
By Glenn Booth Posted Thursday 31st July 2008 20:10 GMT
Plusnet scoring "GREAT" #
By Martin Sylvester Posted Thursday 31st July 2008 20:12 GMT
How do we know this is his exploit #
By Anonymous Coward Posted Thursday 31st July 2008 20:31 GMT
OK! #
By Colin Morris Posted Thursday 31st July 2008 20:43 GMT
Verizon #
By Anonymous Coward Posted Thursday 31st July 2008 20:53 GMT
Bellsouth (now AT&T) - South florida #
By Petr Posted Thursday 31st July 2008 21:13 GMT
Newnet seems to be ok #
By Steve Evans (a different one) Posted Thursday 31st July 2008 21:27 GMT
Clara #
By adnim Posted Thursday 31st July 2008 21:36 GMT
Re: Verizon #
By Chronos Posted Thursday 31st July 2008 22:56 GMT
Sky #
By Robert Grant Posted Thursday 31st July 2008 23:08 GMT
gentoo portage up to date? #
By robert Posted Friday 1st August 2008 00:15 GMT
Tiscali #
By Mark McC Posted Friday 1st August 2008 00:15 GMT
@ robert - GIYF #
By Trix Posted Friday 1st August 2008 01:04 GMT
Open DNS tested okay #
By grant warkentin Posted Friday 1st August 2008 01:48 GMT
Verizon DNSs #
By Kanhef Posted Friday 1st August 2008 04:22 GMT
Orange UK #
By J. Simon van der Walt Posted Friday 1st August 2008 04:37 GMT
Demon #
By Old Man - Grey Fleece Posted Friday 1st August 2008 04:55 GMT
Shaw Cable ok #
By Stewart Midwinter Posted Friday 1st August 2008 05:18 GMT
@ Chronos #
By Anonymous Coward Posted Friday 1st August 2008 05:46 GMT
Oops - Nildram still vulnerable #
By when_the_sh*t_hits_the_fanboi Posted Friday 1st August 2008 06:00 GMT
BT Broadband #
By System Administrator Posted Friday 1st August 2008 06:44 GMT
BeThere #
By Andrew McAuley Posted Friday 1st August 2008 07:09 GMT
Bit worrying #
By Theresa Jayne Forster Posted Friday 1st August 2008 07:13 GMT
Earthlink seems to be all right #
By Kibble Posted Friday 1st August 2008 07:27 GMT
Sprint PCS, patched! #
By Anonymous Coward Posted Friday 1st August 2008 07:33 GMT
OpenDNS #
By Goat Jam Posted Friday 1st August 2008 07:40 GMT
Pipex #
By Anonymous Coward Posted Friday 1st August 2008 07:41 GMT
TMNet (Malaysia) #
By Dave Harris Posted Friday 1st August 2008 07:48 GMT
Re: gentoo portage up to date? #
By mdubh Posted Friday 1st August 2008 08:13 GMT
BT - No suprises #
By Subs McNubs Posted Friday 1st August 2008 08:29 GMT
Mistral #
By Tom Smith Posted Friday 1st August 2008 08:36 GMT
Aquiss #
By Rob Simmonds Posted Friday 1st August 2008 08:43 GMT
BT Business Broadband #
By AlfieUK Posted Friday 1st August 2008 08:59 GMT
nildram fail #
By Anonymous Coward Posted Friday 1st August 2008 09:08 GMT
Re: gentoo portage up to date? #
By Chronos Posted Friday 1st August 2008 09:11 GMT
Title #
By Wokstation Posted Friday 1st August 2008 09:14 GMT
Andrews & Arnold #
By Mal Franks Posted Friday 1st August 2008 09:21 GMT
Kelloggs Frosties #
By Galaxy Bob Posted Friday 1st August 2008 09:29 GMT
TeleDanmark #
By grumpy Posted Friday 1st August 2008 09:35 GMT
Freeddom2Surf aka pipex aka Tiscali #
By Paul Taylor Posted Friday 1st August 2008 09:36 GMT
Re: BT results #
By Adrian Waterworth Posted Friday 1st August 2008 10:01 GMT
Orange DNS test #
By John Posted Friday 1st August 2008 10:07 GMT
Vodafone mobile 3G #
By Anonymous Coward Posted Friday 1st August 2008 10:24 GMT
iPhone surfing in the UK STILL not safe #
By Photon Posted Friday 1st August 2008 10:25 GMT
job's a good'un #
By Anonymous Coward Posted Friday 1st August 2008 10:31 GMT
oops #
By Tom Posted Friday 1st August 2008 10:41 GMT
Virgin Media #
By Richard Kay Posted Friday 1st August 2008 10:45 GMT
Telenet in Belgium vulnerable #
By Daniel Posted Friday 1st August 2008 11:23 GMT
@Tom #
By System Administrator Posted Friday 1st August 2008 11:23 GMT
Bloody black-hats #
By John Posted Friday 1st August 2008 11:43 GMT
DNS hole #
By Willys Posted Friday 1st August 2008 12:33 GMT
@Paul Taylor - F2S/Tiscali #
By vagabondo Posted Friday 1st August 2008 12:53 GMT
above and beyond #
By Bruce Ordway Posted Friday 1st August 2008 13:21 GMT
Bell Canada still vulnerable #
By Ryan Posted Friday 1st August 2008 13:22 GMT
Recursion - So Why This Focus on 'Your' DNS Servers? #
By Phil Posted Friday 1st August 2008 14:08 GMT
Is this really a problem for secure sites? #
By Ose Pedro Posted Friday 1st August 2008 17:01 GMT
Omsoft (local ISP in Davis CA) #
By Jeffrey Nonken Posted Friday 1st August 2008 18:21 GMT
Verizon / FairPoint DSL iffy #
By Johnny Utah Posted Friday 1st August 2008 19:34 GMT
moved my router to OpenDNS and got better results #
By Paul Murphy Posted Friday 1st August 2008 21:02 GMT
@ System Administrator #
By Joseph Helenihi Posted Friday 1st August 2008 23:20 GMT
NTL Ireland (=UPC) looks OK #
By Andrew Gallagher Posted Saturday 2nd August 2008 00:35 GMT
Be Unlimited #
By jeffrey Posted Saturday 2nd August 2008 08:29 GMT
Virgin Media #
By John Posted Saturday 2nd August 2008 12:13 GMT
How the DNS works #
By Jim Morrow Posted Saturday 2nd August 2008 14:32 GMT
OpenDNS #
By James Cleveland Posted Saturday 2nd August 2008 16:41 GMT
Logs...is there anything they can't do? #
By Michael Posted Sunday 3rd August 2008 03:13 GMT
Videotron, Quebec #
By Anonymous Coward Posted Sunday 3rd August 2008 03:51 GMT
Melita Cable #
By Andy Towler Posted Sunday 3rd August 2008 08:07 GMT
ADSL24/Entanet #
By Jason Posted Sunday 3rd August 2008 11:12 GMT
cox in arizona mostly good #
By Anonymous Coward Posted Monday 4th August 2008 03:23 GMT
freedom2surf.net :: POOR #
By David Greaves Posted Monday 4th August 2008 08:31 GMT
No shock here #
By Anonymous Coward Posted Monday 4th August 2008 08:35 GMT