To Answer A Couple Of Questions
Some people would like to have the IP address of www.doxpara.com, so that if their DNS server is compromised, they can still find out if it’s vulnerable (the theory being, if it’s compromised, it won’t actually go to Doxpara).
Here’s the problem: I’m watching you look up Doxpara’s names. That’s how I can see what ports you’re using! If you don’t use DNS to find Doxpara, I can’t watch you finding Doxpara, and thus I can’t tell you if you’re always using the same ports.
Also, people want to have the ability to ask for a particular name server to be tested. My problem here is that I probably don’t have access to your name server, except through you — so I need your web browser to poke your name server to look up a name from me. Then, and only then, can I tell you if there’s a problem.
Finally. some people think that if their name server only accepts requests from Internet IP’s, it’s safe. No. As alluded to in the last paragraph, I may not have access to your nameserver, but your browser does, and I do have access to your browser.
So, in conclusion: Patch, and verify the patch is working (NATs continue to be a headache). If it’s not working, forward to something that is. OpenDNS has capacity to spare.
Dan Kaminsky's Blog 
Dan Kaminsky:
Your 27 July post stated that “Patch, and verify the patch is working (NATs continue to be a headache).”
But my computing knowledge is limited, so I am wondering: What’s the headache with Net Address Translation?
Clicking on your “Check My DNS” gave me 10 http: results, but I don’t know how to interpret that.
I have not yet installed client DNS patch 953230, but will do so today, assuming that Windows Update lists it.
I believe I do have NAT, because I am behind my ISPs firewall (as well as behind my own comuter’s Danware’s NetOp client firewall), and I have a fixed IP address between me and my ISP (Redshift.com).
At your convenience, please clarify.
Thanks for any help. (I learned about your test from Susan Bradley’s PatchWatch column in the 24 July WindowsSecrets newsletter.)
Sincerely, R.N. (Roger) Folsom
this is what i get with opendns. something is not right here:
porttest.dns-oarc.net
canonical name = z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
text = “208.69.34.6 is UNKNOWN: Only received 4 queries. Please try again in 60 seconds”
only 4? lol i rather stick with my isp, thank you very much
Hi,
thanks for your advises, it appears my provider hasn’t patched his DNS servers.
So what the precautions I could take until that?
I mean, there are some site that are safe like https ones or to be sure I need to type their IP directly (using http://www.who.is for example).
Thanks for answer
microguru
Hi Roger,
I don’t believe *you* being behind NAT is the problem… just DNS servers being behind NAT. So if your ISP has a DNS that you are using, then whether it is behind NAT is the real issue.
Regards,
SC
Dan,
Thanks again for your continued updates. What are your current thoughts on the port rewriting problem with DNS servers located behind a NAT boundary? Do you have any feeling for when firewall (and other NAT device vendors) might address this?
I’m afraid that there are a lot of enterprises patching without taking this issue into consideration, as well as a lot of enterprises that will drag their feet on moving DNS into a DMZ.
Thanks,
Ryan
Okay since this will affect banks and financial institutions the most because of phising attacks, can the following be used to reduce the threat? These secure sites should already have certificates. The banks need to update their certificates for their IP address rather than the name of the URL. Then the links to the secure sites need to be changed from the URL to the IP address. For example: the link to “https://www.coolbank.com/securelogin.asp” would be changed to “https://172.16.100.1/securelogin.asp”. By doing this, the web browser verifies the certificates name against the banks authentic IP address instead of verifying the certificates name against the name of the URL, which can be spoofed. The user can then have confidence in the site once the browser displays a secure connection. Some might say that HTTPS is safe with the certificate verifying against the name of the URL, but can anyone be absolutely sure?
I’ve conjectured somewhat on the problem that NAT poses to a patched DNS server. I believe that a patched Bind DNS server offers better protection than an unpatched one, even when queries must pass through NAT. However, the threat is still exploitable (albeit somewhat less exploitable that before) if the attacker can coordinate an internal and external attack.
More details posted here:
http://blog.ghostinthemachines.com/?p=7
May I suggest that you reword the example in your DNS checker? At first, I thought you wanted to tell me that 1001, 1002, 1003 are the ports this DNS server look you up from.
Now that I know that those are examples, all is well. Yet, adding a ‘for example’ would go a long way in not agitating people in higly paranoid mode (and yes, my system’s have been patched since day one, but I wanted to show the fact to someone. At the least, I am fully awake _now_ 😉
Kudos to you for finding this one, btw 🙂
Richard
Dan, a quick question.
I run a local LAN DNS caching server, and this showed up on your test page as vulnerable. I upgraded and built to latest BIND 9.5P1 release, and all is now reported as well (as can be).
My question: As I only run a caching server, (I use ROOT domain list) and fallout to openDNS, _if_ my local cache DNS does get poisoned, I guess just a restart to clear the cache would be suffice to clean it up? Or will the cached entries propagate somewhere and I will just get them back again?
DK:
“Some people would like to have the IP address of http://www.doxpara.com, so that if their DNS server is compromised, they can still find out if it’s vulnerable (the theory being, if it’s compromised, it won’t actually go to Doxpara).”
And that’s where the debate should end. Not only would your site not be able to test, they wouldn’t see your post stating the real IP address as they would be looking at the 3v1l haXX0rs version of doxpara anyway 😉
Is there a tester IP address I can temporarily point my firewall/router at as it’s primary DNS?
I know that the request from OpenDNS to doxpara is safe, which is all well and good, but the tester doesn’t tell me anything about the request from me to OpenDNS.
So as I understand the vulnerability, I could be vulnerable even though the test widget gives the all-clear. I’d need to figure out whether my firewall/router caches DNS, and if so whether it caches in-bailiwick responses. If it does, and if it uses predicable ports, then I’m vulnerable even if I’m using OpenDNS.
Is this correct?
Like many people, my ADSL router gives out its IP address as a DNS server for DHCP clients. I think this might be at risk. Maybe if a tried a non-cursive query after a recursive one, I could tell if the router’s DNS server caches using nslookup. Won’t get back to it for a few hours…. If it does cache, then the situation is surely a LOT worse than people anticipate. Millions of ADSL routers AREN’T going to get patched. We’ll have to ensure we are using a real (patched) DNS server for our requests…
Am I totally wrong on this? I suppose without knowing how each different ADSL/Cable router works, it’s really hard to judge….
How come when I initially go to your site and run the test tool, it tells me that my DNS is ok but when I re-run the tool (when staying on your site), it tells me it may be vulnerable?
I a not sure I understand how forwarding to OpenDNS would help. If a vulnerable machine uses OpenDNS for resolving, can’t the attacker simply spoof the OpenDNS servers?
thank you so much for this program, or whatever it is! now my DNS its safe! 😛
In response to testing name servers is there a method that ‘wget’ or some other tool may be used on a *nix box to test for the vulnerability since a browser must be used?
Can’t you put the test under https to authenticate this site, rather than posting the IP address?
In my opinion, everyone should be using the DNS-OARC test page to determine if the DNS resolvers which are used by the computer on which they view the page are vulnerable.
https://www.dns-oarc.net/oarc/services/dnsentropy
It gives a huge amount of relevant information and is in beautiful color. Just click the button labeled “Test my DNS”.
This test should be run on every computer which has a browser on it. If the test passes, that means your computer is using (relatively) safe DNS servers to fetch domain name translations with. If it fails, you need some basic knowledge of the DNS to figure out what to patch and what to reconfigure.
Can anyone explain how this test actually works? Is there some change in the headers or something after the patch?
Hi Dan.
I’ve being following the recent news of the DNS exploits in the media. By now it’s made fairly clear that this is a serious problem. But one thing that I felt being left out everywhere is how it impacts the majority of end users out there. ISPs are supposed to patch, Windows seemed to be patched two weeks, etc. But what does that mean for an end user? If the ISPs do not patch, how does it affect us? What kind of risk are we facing? If we type in http://www.insert_name_here.com, should we expect a different site? After going through all the materials I could find, I still don’t have an answer. Maybe you should write a new post explaining its effects on its effects.
The tester on this site says I’m unsafe.
(gives a specific IP number)
the tester at https://www.dns-oarc.net/
says I’m safe (gives a name for the IP)
Who should I trust?
Nobody with a DNS number over 30?
Dan,
You’ve said in this entry that “Also, people want to have the ability to ask for a particular name server to be tested. My problem here is that I probably don’t have access to your name server, except through you”
We also see that problem of your tool.
On July, 25, 2008, we – Bkis, has released BkavDNSCheck, new software checking for your DNS flaw. The advantage of this software is that BkavDNSCheck could solve the limitation of your tool. BkavDNSCheck is able to test exactly the specific DNS Server which DNS Administrators want to check.
We think you could comment any DNS Administrators to use BkavDNSCheck Tool to test the vulnerability that you discoved.
To check the DNS server, administrators must do as followings:
1. Configure the DNS Server Forwarders function to point the domain name BkavDNSCheck.vn to IP Address: 203.162.1.239
2. Download an run the BkavDNSCheck tool
3. Applying patches if the system is vulnerable
We have the detail guide to use the BkavDNSCheck in this link: http://security.bkis.vn
Together with launching the software, we provide the article of the tool to local press and APCERT in order to guide administrators to check and patch their systems.
Nou: There’s a change in the behavior of your DNS server when it’s patched – a vulnerable DNS server will use consecutive or predictable port numbers, a patched one will not. The test looks at several consecutive requests to see if they appear random or not: if they ‘look’ random, it means you’re patched.
Don’t forget, in order for testing to work… JavaScript has to be turned on. Thanks for letting me know I am secure! [yes, I did turn JavaScript on for the test :D]
The first time I run the test at your site or at
https://www.dns-oarc.net/oarc/services/dnsentropy my ISP (Earthlink) gets a clean bill of health. The second time I run the test from either site my ISP fails. Which test is correct, the first or the second? Subsequent iterations have the same inconsistency.
I’d greatly appreciate information on this.
@Jack
A friend of mine was also confused by the DNS exploit. After explaining things to him, I figured my explanation might help others too. I posted my thoughts on the matter here:
http://blog.ghostinthemachines.com/?p=6
I won’t claim that it is exhaustively thought out, but it should help you to start wrapping your mind around the problem.
@Ian
I do not believe your ADSL router maintains a cache. Most routers are limited in amount of memory, so they are probably not wasting it on an internal DNS cache. The ADSL router acts simply as a router to your ISP’s DNS server (as assigned via DHCP from your ISP to the router).
If there is caching happening, it is being done on the ISP’s DNS server and possibly on each individual computer behind the ADSL router. For example, Windows workstations keep a cache (this is what the “ipconfig /flushdns” clears when you run the command in the DOS prompt.)
@Steven Reese
A browser does not need to be used to attack the vulnerability. Simply being able to make a recursive DNS query is the primary attack vector. A browser may be used, as it initiates queries for servers hosting web pages and images.
@James Sutherland
That is not exactly correct. A vulnerable DNS server will usually only use a single UDP source port for queries. A patched DNS server will use random UDP ports.
If you are seeing consecutive or predictable port numbers, your DNS server may or may not be patched. (Depends on the specific DNS software you use.) However, in my line of work, the more typical reason for the consecutive port numbers are the use of a NAT device between the source DNS server (which may or may not be patched) and the target DNS server which is being queried.
@Other
To test this, you can use tcpdump (Linux) or snoop (Solaris) to monitor UDP traffic on your DNS server. Maybe I’ll write up an explanation of how to do this, if there’s enough demand.
Here are some instructions on how to test for a patched DNS server. Initial two sections are for normal end-users. The last section is for a root-privileged system administrator.
http://blog.ghostinthemachines.com/?p=48
Okay, thanks for that.
Joe has patched his PC’s O/S and he ran the check here and elsewhere which says his DNS server has good entropy. But what Joe doesn’t know is that his ADSL router is de-randomising the UDP packets between his workstation and his DNS server. All the docs say that stub resolver is at risk… but less so than servers.
So Joe is at risk, is he not? Because someone could spoof the packets that he is expecting back from his DNS server.
How credible is this risk?
For those that are now aware, Connecticut-based KeyID has actually introduced a documented (and of course patented) solution to the challenges i.e. DNS hijacking, along with the related and wide-spread problems i.e. phishing/pharming.
The solution is actually very simple, and of the many industry experts that have kicked the tires, nobody has been able to come up with a “but this is why it doesn’t work..” other than the fact that it wasn’t built by them…Happy to arrange conference calls with interested parties.
Can someone shed some light on this?
The doxpara tool runs and indicates our patched DNS servers are safe – I can tail our logs to verify that doxpara requests came in and did indeed query our servers.
But the part I am having a hard time with is the results will show up with an IP that isn’t even on our network (a Level 3 server that isn’t a DNS server). I am missing something here and am just curious to see if anyone else has any ideas – the behavior is the same with doxpara, dnsstuff and dns-oarc. Thanks for any replies….
Dan,
I’ve been running this “dig porttest.dns-oarc.net TXT @servers” test to see whether or not some dns servers I know of are vulnerable. In some cases, the servers owned by official authorities (both in my country and others), the result is poor.
What would you recommend doing in such a situation? Do you usually let people and organizations know they have a potential security issue?
Personally, I feel like letting them know is the only option there is, but given that some organization hits back at you by reporting it as “hacking”, it’s not very tempting.
@Ian
The Doxpara test tool, and the web-based oarc tool, work by monitoring inbound DNS requests from a given server. Since those packets go out through the router and whatever NAT devices are in place, the test will show the status of requests as seen by an authoritative server on the internet. Thus, if NAT is an issue, they’ll show it.
@Jeff
I disagree. My resolver in my O/S makes a request to my DNS server. My DNS server recursively resolves what it needs to and Doxpara hears the UDP requests from my DNS server. It has no knowledge of the interaction between my PC’s resolver and my DNS server. It is this interaction that may still be vulnerable. A hacker would know my IP address and the IP address of my DNS server, so what is to stop the hacker from spoofing the return response from my DNS server to my O/S’s resolver? To test the issue, IMHO you need to configure a recursive DNS server on your side of the NAT and configure that as your DNS server in your O/S. Then run the test and if Doxpara or similar confirms it’s okay, then you should be alright.
I tried this but the Doxpara test gave me a little window of “unable to find server”. The oarc web test indicated that I was ‘good’ on both accounts and quoted my ADSL ip address as the DNS server (which is what I expected)… IMHO this confirms that NAT is not an issue for me… but that might not be the case for everyone else who uses a cheap ADSL router.
@Jeff
The doxpara test tool doesn’t know what ports are being used between the edge of Joe’s NAT and Joe’s DNS server (operated by his ISP). For one thing, that communication is probably entirely within his ISP’s local network.
That’s what Ian is asking about. Is there a vulnerability there?
@boo, Ian:
“I do not believe your ADSL router maintains a cache.”
My router is a WRT54G. By default it runs dnsmasq, which according to the man page uses a “small local cache”. There’s a cache-size option which can set the size to 0 (default is 150 names). IIRC the router has 16M RAM, so a cache of a few dozen names would not necessarily be out of the question. I don’t know what the firmware version I’m using does, so I just disabled dnsmasq to be on the safe side.
I think this means that everything on the network has to either take DNS settings from DHCP, or else be configured to use a server other than the WRT54G. That’s not been difficult so far.
In fact, the CERT warning alludes to the fact that a stub resolver needs the random part stuff to be more secure… “In lieu of strong port randomization characteristics in a stub resolver…”. So if the randomness of your stub resolver is important, then it is a risk if your NAT device de-randomises it.
@Steve
I wouldn’t use your routers in-built DNS resolving abilities anymore, unless you can prove it uses random ports and even then it won’t include the other recommended changes.
Unpatched versions of dnsmasq are at risk, therefore so are all routers that use.
http://secunia.com/advisories/31197/
This is (one of) the issues have have been going on about. 1000’s of ppl will be affected and they won’t even know it!!
Thanks 4 your info,
My DNS is safe now,
I was AD 4 Ur Website on:
http://k3lvinmitnick.blogspot.com
Tks,
Hey Dan,
Using the link to OpenDNS in your “check my DNS” results section causes it to open their site inside that tiny frame. I think you need to specify the target for the link to make it load in the actual window, not the frame.
Thanks for your work and research!
Your test says the name server i use is vulnerable. As i understand my internet provider has to update its name server. From the point of regular surfer, should i additionally update something on my PC? Thanks!
Okay, I see what you’re saying now.. I missed the fact that your requests to your caching server are passing through a NAT, and out to the internet. What you’re saying is absolutely right.
I spent quite a bit of time thinking about this. This is how I see it. Yes, all unpatched stub resolvers, recursing servers, etc can be slipped a spoofed DNS resply. I think the reason that the ADSL router is not as at as much risk as the a recursing server, is that when it asks for an ‘A’ record, it will not expect or accept and referral and a glue record. The first response will stay in it’s cache and likely to be correct. I think the increased risk is that the glue record in the spoofed packet will overwrite what’s in the cache, one the right UDP packet has been received to fool the server. The won’t happen on a local stub resolver cache or an ADSL router. Therefore, I don’t think this is an equal risk to a recursing server.
So, what I think covers it:-
1. Check your external DNS servers using the tool here and elsewhere (Don’t forget to check your secondary!)
2. Patch machines on your local network.
3. Statically configure your machines this side of your ADSL router to use your ISP’s DNS server, not the IP address of the router.
BUT…
Back to the main attack on resolving DNS servers… even with source port randomisation, what if an distributed attack was built with 65536 drone machines, all sending 65535 different TransIDs.
Dan has said that this kind of attack would make a ‘lot of noise’. Unfortunately, it doesn’t matter how much noise something makes, if nobody is listening.
Too much knowledge is assumed for this reader. I have no idea what to do with the information provided.
(So, in conclusion: Patch, and verify the patch is working (NATs continue to be a headache). If it’s not working, forward to something that is. OpenDNS has capacity to spare.) What?
As for the numbers the DNS checker told me to watch out for, that, too, is meaningless without further explanation.
I started delving into this stuff a while back. Bravo, sir! Super DNS Lookup Gateway and Network Calculators educated me a lot in this area. Secunia first did a few years ago. Kind of core stuff, isn’t it. I grid compute, and one of the big server nets, I believe, was somewhat compromised a month or two ago. I noticed when I tried their forum page, everything would freeze. Not my system, and not my ISP. I probably go to extremes, but their ain’t NO cookies, or browsing history, or temp files in my system after every single web session. And yet, even that is not enough. Frankly, if an exploit has been published, then it’s our responsibility to patch. Information is power, but one must utilize it, or someone else gets the power.
My ISP is secure, and great thanks/ kudos for the checker. I used the lookup gateway to find the address for …….., I learned it’s uses and limitations a while back after reading Secunia’s repeated warnings about Internet Explorer then continuing vulnerabilities to exploits. But, everybody is exploitable, if everyone does not patch. Oh, my bad… 7cures is my World Community Grid nom de plume! And you know what? I believe they were attacked a couple of months ago by a similar exploit, or maybe a prototype. Experiencing freeze behavior was not strange, but on only one website was. I used Network Calculators to ID the site, and they could! By inspection, not just by DNS identifier! Maybe I’m blowing smoke, because it is a new area of study for me. Any way, I will studt more. The last time I did dark side stuff was in college in 1973, when I wrote a little BRK disable command in a BASIC number counter program on the school’s HP 2000! That was enuf for me. Been in the light ever since!
@Ian
@Ian
“A lot of noise” means “use a lot of bandwidth.”
Possibly more than you have.
Could you PLEASE post something explaining to us normal folk what the heck “…but make sure the ports listed below aren’t following an obvious pattern…” means; how are we supposed to define an obvious pattern -ie do all 6 listed port #s have to be an obvious pattern, or is 2 or 3 falling into a pattern too many – ; what the danger is; and most importantly what are we supposed to do about it or at least where can we get more info?
Thanks. I googled “following an obvious pattern” and other variations and all I get are references back to this one page.
are we in open-ended oooops land?
I remembersome 15 years ago coming across some form of making stuff sound like white noise when it goes down the wires . Oford University Maths public FTP
@L. Taylor
I supposed a distributed attack such as I have described may deny service to a DNS server through flooding before it ever did a successful poisoning, if that’s what you mean.
I presumed “make noise” = “use enough bandwidth so that someone notices”, but my experience over the last few days that very large players in the UK are fairly oblivious to what’s really going on out there. I work on behalf of a large IT service company that runs many government and military projects… and our DNS servers aren’t patched… and yes, I raised it as an issue on Tuesday. It’s gone up the chain, but it is still ping-ponging around while somebody decides to take responsibility :o)
For anyone interested in some of the possible impact of all this, (and a slightly different layman’s explanation), I’ve written a bit about it here:
http://blog.simplicity.net/
@Ian
This is why I like smaller organizations.
When this exploit came out, our chief technologist consulted with our President/CEO.
We turned to our vendor, who had just become aware of the exploit (the day Dan went public), and their lead developer and the President of that organization had a discussion, and decided the fix was the very top priority.
Took about two minutes. Of course, all five “people” in that scenario are the same person.
Developing, testing and deploying the patch took a little longer — thank you Dan for the time.
Anything that puts ISC and Microsoft and Cisco in the same room is scary on the surface. If that isn’t enough to get management moving, you have a choice:
Arrange a demonstration (using the sample exploit code) or let them do whatever they’re going to do.
Dear Dan
I am sure that following the NYT article you are even more submerged with emails than usual.
However I cannot help but wondering, even with the patches starting to be available and implemented, what is the future plan on improving the system using current technology without causing much of a substantial impact/disruption on current network? Will these changes manage to be seamless or …?
Most interested in your Las Vegas presentation,
Sincerely,
alex becker
@L. Taylor
The latter… and not do my online banking during my lunch hour. :o)
“Ian on July 30th, 2008 2:55 am
Okay, thanks for that…//
//… So Joe is at risk, is he not? Because someone could spoof the packets that he is expecting back from his DNS server.”
Yes, this risk is nothing new and not specific to the DNS issue in this discussion. Some call it IP Spoofing, some call it IP Hijacking, basically it’s the same thing – setup an intercept “DNS Server” between the real DNS server Joe’s machine is expecting an answer from, let’s call it “Fake DNS Server” … this is how the simplified process goes – 1. Joe’s Machine request for DNS lookup –> 2. Fake DNS Server intercepts request –> 3. Fake DNS Server returns whatever IP Address the hijacker wishes to direct Joe’s Machine to –> 4. Joe’s Machine arrives at false address thinking it’s the real deal.
now, whether or not the DNS Server at ISP level is patched, whether or not Joe’s router is patched, whether or not Joe’s Machine is secure is totally irrelevant at this point, because it this happens, it is not due to the DNS issue we’re discussing but a direct targetted hit on Joe’s Machine. And that, is a story for another time 🙂
—–
“Ian on July 31st, 2008 1:37 pm
I spent quite a bit of time thinking about this…//
//…3. Statically configure your machines this side of your ADSL router to use your ISP’s DNS server, not the IP address of the router…. ”
again, that’s rather pointless, refer to Fake DNS Server scenario above.
actually, hard-coding your ISP’s DNS Server’s Address on every machine is an adminstrative nightmare and could be detrimental. I’ll illustrate why in a moment. But before that, allow me to point out a typical setup using Joe’s Machine.
Joe’s Machine points to ADSL Router for DNS resolving. the ADSL Router typically DOES NOT hold the entire internet’s DNS Entries, and is definitely not authoritative, which means it almost always forwards the request to the ISP’s DNS Server unless the address requested happens to be in cache. If the ISP’s DNS Server address is not hard-coded on the ADSL Router (which is the typical case) the ADSL Router would have queried the ISP for DNS Server Address upon login. All these just means that Joe’s ADSL Router is acting as a DNS relay only – whether you configure your machines this side of your ADSL router to use your ISP’s DNS server, not the IP address of the router does not make a difference – the query will still go out to your ISP’s DNS Server.
now here’s the DETRIMENTAL effect the you could invariably cause IF you choose to statically configure all the machines to use your ISP’s DNS server – you will have to manually key in your ISP’s primary and secondary DNS Server Address on all machines, which is an administrative nightmare as I’ve already mentioned.
But here’s something for you to consider: Not likely to happen, but then who’s to say it wont? …. WHAT IF your ISP’s current DNS Server is unpatched, and they up a new freshly patched and updated DNS Server and promote it to the Primary DNS, demoting the current DNS Server that you’re pointing to as a backup, or even worse, takes it offline due to attacks?
You now have to re-configure all the machines to point to the new unknown ISP DNS Server’s Address, but before you even get there, you’d have everyone telling you that they can’t get online. Well, in this scenario, at least you’re somehow alerted to the fact that the DNS Server Address has changed.
The other scenario of course is you’re still pointing to the vulnerable unpatched/old DNS Server while everybody else was automatically pointed to the newly up DNS Server because their machines points to their ADSL Router for DNS resolution, their ADSL router relays whatever DNS Server the ISPs says to use during login 🙂
and once again, bear in mind that IP Spoofing / Hijacking is a seperate issue all together
—
maybe i’m no securities expert, but i think that my points make sense?
Thanks m8!! I also needed taht info to understand few things, didn’t havd time to investigate how you found the ports and now its clear for me.
I’m using a vulnerable server because my IP is full of dickheads.
@wkhai
Well, the CERT advisory states that stub resolvers are vulnerable, but not as much as servers. Yes, this may be a good old fashined IP spoof, but so is the original attack. IMHO, this makes it ‘in scope’. The only different here is you can’t manipulate the cache to be overwritten, like you can with the server attack. I must admit, when I posted the first item you quoted, I wasn’t sure what aspect made the stub resolver vulnerable but “less so” than servers. I think I understand it better now and I wouldn’t necessarily have written what I first post, knowing what I know now.
On your second point, maybe statically configuring was perhaps a little drastic, and not necessarily what I meant :o). Configure your DHCP server to give out the IP addresses of the DNS servers, NOT its own address as the DNS server. Perhaps your router could be configured to give our what it receives from the DHCP info it receives from your ISP. I don’t accept that ISP might change the IP addresses of the DNS server without warning. I think it is an assumption too far that everyone is using DHCP either on their LAN or on their ADSL connection itself.
In the first instance, I was trying to identify the steps you could take to best protect yourself, not whether they were worth doing or not.
Avoiding the ADSL router is simply because it is less likely to have a patch for this issue than your resolver on you PC or the DNS servers.
Anyway, you can ‘prove’ if your ADSL router is an issue by running an up-to-date instance of BIND on this side of the NAT, set your PC to forward its requuest to it and then run the Doxpara/OARC test. Took just a few minutes to figure that my ADSL router was not removing entropy because of NAT. (This didn’t prove a thing about the stub resolver in the ADSL router itself… which is why I think it best to avoid it.)
As OpenDNS is not correctly resolving the domain I own and has failed to respond to support requests sent on Thursday and again yesterday, I’ve had to switch to something else. I don’t care what DNS server I’m using as long as it’s safe–but anyone else using OpenDNS will be unable to find my domain and possibly others.
Dan,
Thanks again for your continued updates.
It seems that there are still ISPs out there with issues (DNS this time)
I am moving out to ZoneEdit until the storm is over.
http://www.inetholding.com/hosting/1and1-has-dns-problemsagain/
Great work Dan, keeping us informed and on the lookout!
Julian