Posted Thursday 31st July 2008 18:50 GMT
I was extecting to read a story about people in bowler/top hats & other rediculous headgear to be invading t'internet. Oh well.
Posted Thursday 31st July 2008 18:50 GMT
s-oarc.net reckon "212.159.6.113 appears to have GREAT source port randomness and GREAT transaction ID randomness"
The Kaminsky page reckoned ok as well, but without the nice scatter plots and GREAT CAPITALISATION.
Posted Thursday 31st July 2008 18:50 GMT
1. 212.104.130.65 (resolver2.th.eclipse.net.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness.
2. 212.104.128.102 (uplink2-bba1.th.eclipse.net.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Test time: 2008-07-31 18:36:45 UTC
Posted Thursday 31st July 2008 18:50 GMT
ISP - Verizon (buncha scumbagz)
DNS resolvers - 71.242.0.39, 71.242.0.36
Doxpara and DNS-OARC basically agree that my ISP's DNS servers are okay, but my local NAT router isn't randomizing the source ports very well.
My router is a re-imaged Linksys - guess I better get around to updating it :-(
(Icon? "Proceed with this nonsense at flank speed!")
Posted Thursday 31st July 2008 18:50 GMT
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.
Posted Thursday 31st July 2008 19:34 GMT
Came back as safe from doxpara.
dns-oarc gave the following :
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.
3. 62.254.32.148 (belf-dnsany-1.server.virginmedia.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
Pretty middle of the road then.
Posted Thursday 31st July 2008 19:34 GMT
DNS Resolver(s) Tested:
1. 194.74.65.68 (ns6.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 194.72.9.34 (bcn.customer.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
Test time: 2008-07-31 18:49:17 UTC
Posted Thursday 31st July 2008 19:34 GMT
https://www.dns-oarc.net/oarc/services/dnsentropy
DNS Resolver(s) Tested:
68.87.72.131 (chic-cns01.area4.il.chicago.comcast.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
68.87.77.131 (detr-cns01.westlandrdc.mi.michigan.comcast.net) appears to have
POOR source port randomness and GREAT transaction ID randomness.
68.87.72.133 (chic-cns03.area4.il.chicago.comcast.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
Test time: 2008-07-31 18:37:53 UTC
---
When I changed my DNS forwarder to one I knew was patched, it reported GREAT GREAT.
---
DOXPARA said that things were good, and only reported ONE of the DNS servers I forward to.
Posted Thursday 31st July 2008 19:34 GMT
"195.74.113.58 (ths-dns-cache1.enta.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
195.74.113.62 (ths-dns-cache2.enta.net) appears to have GREAT source port randomness and GREAT transaction ID randomness."
So this is good then?
Posted Thursday 31st July 2008 19:53 GMT
Time Warner ( Road Runner) - 65.24.7.3
GREAT/GREAT at DNSOARC
DoxPara - Looks good to me. I guess.
Posted Thursday 31st July 2008 19:53 GMT
How do we really know doxpora is legit? We'd be freely giving away the names of our DNS servers, and easily too!
Posted Thursday 31st July 2008 19:53 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.
Posted Thursday 31st July 2008 20:57 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.
Toodle pip.
Posted Thursday 31st July 2008 20:57 GMT
"1. 212.159.6.101 appears to have GREAT source port randomness and GREAT transaction ID randomness.
"2. 212.159.6.97 appears to have GREAT source port randomness and GREAT transaction ID randomness.
"Test time: 2008-07-31 20:08:11 UTC"
Posted Thursday 31st July 2008 20:57 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.
Posted Thursday 31st July 2008 20:57 GMT
Yep, Zen Internet seem to know what time it is!
Paris, cos she's safe too...
Posted Thursday 31st July 2008 20:57 GMT
DNS Resolver(s) Tested:
68.238.112.36 appears to have POOR source port randomness and GREAT transaction ID randomness.
68.238.96.38 appears to have POOR source port randomness and GREAT transaction ID randomness.
68.238.96.37 appears to have POOR source port randomness and GREAT transaction ID randomness.
Ok, does this mean that redirection to a bogus site would still work?
Posted Thursday 31st July 2008 22:06 GMT
1. 205.152.132.31 appears to have GREAT source port randomness and GREAT transaction ID randomness.
2. 205.152.144.13 (oldmail1.mia.bellsouth.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
3. 209.244.5.159 (ics2.Atlanta1.Level3.net) appears to have GOOD source port randomness and GREAT transaction ID randomness.
Posted Thursday 31st July 2008 22:06 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...).
but how do I check the ports??
Posted Thursday 31st July 2008 22:06 GMT
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.
No I am not a Clara employee ;-)
Posted Thursday 31st July 2008 23:27 GMT
1. 90.207.242.85 (5acff255.bb.sky.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.
2. 90.207.242.82 (5acff252.bb.sky.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.
3. 90.207.242.87 (5acff257.bb.sky.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Posted Thursday 31st July 2008 23:29 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.
Posted Friday 1st August 2008 00:45 GMT
212.139.132.41/42 both scored great on all fronts. Which is surprising, because everything else about them is a bit pants.
Posted Friday 1st August 2008 00:45 GMT
Ive just emerged the latest version of BIND from portage on my nameservers (9.4.2-P1) and restarted the service but im still getting:
(...co.uk) appears to have POOR source port randomness and GREAT transaction ID randomness
Posted Friday 1st August 2008 09:31 GMT
After a whole 3 seconds of Googling, I found this page on the Gentoo site:
http://www.gentoo.org/security/en/glsa/glsa-200807-08.xml
'All BIND users should upgrade to the latest version:
Code Listing 3.1: Resolution
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-dns/bind-9.4.2_p1"
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?
Posted Friday 1st August 2008 09:33 GMT
Open DNS tested okay
1. 208.67.216.13 (bld3.sea.opendns.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Posted Friday 1st August 2008 09:33 GMT
141.154.0.68 (gtebo.ba-dsg.net)
141.155.0.68 (gteny.ba-dsg.net)
151.197.0.39 (home4.bellatlantic.net)
151.198.0.39 (home5.bellatlantic.net)
151.201.0.39 (home6.bellatlantic.net)
151.202.0.85 (nyc2-qwest.bellatlantic.net)
151.203.0.85 (boston2-qwest.bellatlantic.net)
All come up with poor source port randomness, great transaction ID randomness.
Posted Friday 1st August 2008 09:33 GMT
dns-oarc.net gives Orange UK;
193.36.79.101 Source Port Randomness: GREAT
193.36.79.101 Transaction ID Randomness: GREAT
but at doxpara.com the test doesn't seem to work; get a 'page not found'
Posted Friday 1st August 2008 09:33 GMT
1. 64.187.29.134 (h64-187-29-134.gtcust.grouptelecom.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
2. 64.59.135.133 (nsc1.so.cg.shawcable.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
3. 64.59.135.135 (nsc2.so.cg.shawcable.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Posted Friday 1st August 2008 09:33 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>
Posted Friday 1st August 2008 09:33 GMT
Your name server, at 213.208.106.212, appears vulnerable to DNS Cache Poisoning.
All requests came from the following source port: 33542
Posted Friday 1st August 2008 09:33 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!
Posted Friday 1st August 2008 09:33 GMT
1. 87.194.0.51 (cache0.betherenow.co.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness.
2. 87.194.0.52 (cache1.betherenow.co.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Posted Friday 1st August 2008 09:33 GMT
Well when i test on BOTH sites i get Problem Loading page, Server cannot be found
Sky Broadband....
Is this good or bad?
Posted Friday 1st August 2008 09:33 GMT
Using my usual local dialup number:
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...).
@ Steve Evans
I don't know how to check the ports either.
Posted Friday 1st August 2008 09:33 GMT
68.28.250.92 (ns2.atlngar03.spcsdns.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
68.28.242.91 (ns1.atlngar03.spcsdns.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Test time: 2008-08-01 07:24:35 UTC
For my wireless broadband, Sprint fixed it within the last week.
For my Verizon woes, I have pointed my router to OpenDNS, as opposed to letting my ISP do my DNS and that works just fine.
Thanks again to Chronos, et al, for the information. Yet another reason to love El Reg.
Posted Friday 1st August 2008 09:33 GMT
I haven't used my ISP's dns server for ages. OpenDNS is the way to go.
Posted Friday 1st August 2008 09:33 GMT
1. 203.121.16.85 (ns1.time.net.my) appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 203.121.64.59 appears to have GOOD source port randomness and GREAT transaction ID randomness.
Posted Friday 1st August 2008 09:33 GMT
@robert
BIND 9.4.2-P1 should be immune to this issue:
http://www.isc.org/sw/bind/bind-security.php#matrix
Is your DNS server behind a proxy firewall or NAT device that is de-randomizing the source ports?
http://support.microsoft.com/kb/956190
Posted Friday 1st August 2008 09:33 GMT
1. 194.72.6.57 (ns3.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 217.169.46.108 (217-169-46-108.bis-internet.co.uk) appears to have UNKNOWN source port randomness and UNKNOWN transaction ID randomness.
Oh dear.
Posted Friday 1st August 2008 09:33 GMT
217.154.96.244 (adsl-217-154-96-244.mistral.co.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness
So that's alright then :)
and I use OpenDNS at home.
Posted Friday 1st August 2008 09:35 GMT
Are Great all round according to the tester.
Which is nice...
Posted Friday 1st August 2008 09:35 GMT
Via dns-oarc.net;
1. 194.72.9.34 (ns5.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
2. 62.6.40.178 (indnsc71.ukcore.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
...and...
1. 194.72.9.34 (bcn.customer.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
1. 194.72.9.34 (indnsc30.ukcore.bt.net) appears to have POOR source port randomness and GREAT transaction ID randomness.
Posted Friday 1st August 2008 09:35 GMT
Name servers 213.208.106.212, 213.208.106.213
Posted Friday 1st August 2008 09:35 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:
80.3.128.148:33383 TXID=33827
80.3.128.148:33421 TXID=26554
80.3.128.148:33406 TXID=40195
80.3.128.148:33373 TXID=9963
80.3.128.148:33330 TXID=37889
ISNOM:ISNOM TXID=ISNOM "
From Tesco.net, a Virgin reseller.
Posted Friday 1st August 2008 09:35 GMT
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.
Posted Friday 1st August 2008 09:35 GMT
81.187.81.41 (lifeless.aaisp.net.uk) appears to have GREAT source port randomness and GREAT transaction ID randomness
Sign up, sign up for The Register's weekly IT security newsletter - click here
Back to the article
