[dns-operations] Ang.: ALERT: .QA CCTLD in wrong hands currently
https://twitter.com/Official_SEA16/status/391339315562688513 /amel Skickat från min HTC - Reply message - Från: Kauto Huopio kauto.huo...@ficora.fi Till: Florian Weimer f...@deneb.enyo.de Kopia: dns-operati...@mail.dns-oarc.net dns-operati...@mail.dns-oarc.net Rubrik: [dns-operations] ALERT: .QA CCTLD in wrong hands currently Datum: lör, okt 19, 2013 22:23 On 10/19/2013 10:23 PM, Florian Weimer wrote: * Kauto Huopio: And facebook.qa and tons of .qa govt domains etc. Note also this: google.com.qa. 14400 IN MX 0 google.com.qa. That would actually be valid (but redudant). It causes mail for google.com.qa to be delivered to the host at google.com.qa, based on the A/ records of the domain. Yes,but at the same moment google.com.qa was pointing to something More Nasty. The correct MX pointing to google.com.qa seems to be google.com.qa. 10800 IN MX 10 google.com.s9a2.psmtp.com. google.com.qa. 10800 IN MX 10 google.com.s9b1.psmtp.com. google.com.qa. 10800 IN MX 10 google.com.s9b2.psmtp.com. google.com.qa. 10800 IN MX 10 google.com.s9a1.psmtp.com. --Kauto -- Kauto Huopio Chief Specialist Security Division (CERT-FI) Finnish Communications Regulatory Authority (FICORA) Itämerenkatu 3 A, P.O.Box 313, FI-00181 Helsinki. Tel.: +358 29 5390 555, Mobile: +358505826131 Email: kauto.huopio(G)ficora.fi Web: https://www.cert.fi/ http://www.ficora.fi Personal PGP key: EE83 84DA 2E80 1DC9 1EFF 77E2 52F6 6CD3 549C 2F32 Team PGP key: 933F C1ED AA90 090B D25C C7EE 0089 4AA5 EBB4 1D94 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Ang.: ALERT: .QA CCTLD in wrong hands currently
On 20 Oct 2013, at 17:14, Anne-Marie Eklund-Löwinder anne-marie.eklund-lowin...@iis.se wrote: https://twitter.com/Official_SEA16/status/391339315562688513 If it's on Twitter it must be true, right? :-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
Sorry for delay, I was omw to a different continent. Please see response below. On Sat, Oct 19, 2013 at 9:21 PM, Paul Vixie p...@redbarn.org wrote: Haya Shulman wrote: You are absolutely right, thanks for pointing this out. thanks for your kind words, but, we are still not communicating reliably here. see below. DNSSEC is the best solution to these (and other) vulnerabilities and efforts should be focused on its (correct) adoption (see challenges here: http://eprint.iacr.org/2013/254). However, since partial DNSSEC deployment may introduce new vulnerabilities, e.g., fragmentation-based attacks, the recommendations, that I wrote in an earlier email, can be adopted in the short term to prevent attacks till DNSSEC is fully deployed. by this, do you mean that you have found a fragmentation based attack that works against DNSSEC? One of the factors, causing fragmentation, is signed responses (from zones that adopted DNSSEC). Signed responses can be abused for DNS cache poisoning in the following scenarios: (1) when resolvers cannot establish a chain-of-trust to the target zone (very common), or (2) when resolvers do not perform `strict validation` of DNSSEC. As we point out in our work, many resolvers currently support such mode (some implicitly, others explicitly, e.g., Unbound), i.e., signal support of DNSSEC, however accept and cache spoofed responses (or, e.g., responses with missing or expired keys/signatures). According to different studies, it is commonly accepted that only about 3% of the resolvers perform validation. One of the reasons for support of permissive DNSSEC validation is interoperability problems, i.e., clients/networks may be rendered without DNS functionality (i.e., no Internet connectivity for applications) if resolvers insist on strict DNSSEC validation, and e.g., discard responses that are not properly signed (i.e., missing signatures). Our attacks apply to such resolvers. Furthermore, many zones are misconfigured, e.g., the parent zone may serve an NSEC (or NSEC3) in its referal responses, while the child is signed (e.g., this was the case with MIL TLD). by this, do you mean that if DNSSEC is widely deployed, your other recommendations are unnecessary? Some of our recommendations are still relevant even if DNSSEC is widely deployed. We showed attacks that apply to properly signed zones and strictly validating resolvers. Since referral responses are not signed, the attacker can inject spoofed records (e.g., A records in glue) which will be accepted by the resolvers. Such cache poisoning can be used for denial (or degradation) of service attacks - a strictly validating resolver will not accept unsigned responses from the attacker and will be stuck with the malicious cached name server records (unless the resolver goes back to the parent zone again - however such behaviour is not a security measure and should not be relied upon). Furthermore, in the proxy-behind-upstream setting, even when DNSSEC is supported by all zones and is validated by the upstream forwarder, but not by the proxy, the proxy can be attacked. Ideally validation should be at the end hosts - we are not there yet with DNSSEC. in your next message you wrote: Haya Shulman wrote: ..., the conclusion from our results (and mentioned in all our papers on DNS security) is to deploy DNSSEC (fully and correctly). We are proponents of cryptographic defenses, and I think that DNSSEC is the most suitable (proposed and standardised) mechanism to protect DNS against cache poisoning. Deployment of new Internet mechanisms is always challenging (and the same applies to DNSSEC). Therefore, we recommend short term countermeasures (against vulnerabilities that we found) and also investigate mechanisms to facilitate deployment of DNSSEC. in 2008, we undertook the short term (five years now) countermeasure of source port randomization, in order to give us time to deploy DNSSEC. if five years made no difference, and if more short term countermeasures are required, then will another five years be enough? perhaps ten years? exactly how long is a short term expected to be? for more information, see: http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/ Thanks, you summarised this very nicely. I'd like to bring it to your attention that, in contrast to other sections, you did not cite our work explicitly, in a section where you describe our fragmentation based attacks (please add it). My response to your question is the following: DNSSEC is a new mechanism, crucial for long term (future) security of the Internet. The concern that you are raising applies to other new mechanisms as well, e.g., BGP security and even IPv6, and is not specific to DNSSEC. Deploying new mechanisms in the Internet has always been a challenge, and the mechanisms may go through a number of adaptations during the incremental deployment phases, and intermediate transition mechanisms
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
In that case, on what should an organization spend time or money first, on DNSSEC or the recommendations in the mail message? Would it be better if each of the recommendations in the mail message started with something like this? Deploy DNSSEC, and consider the follow to help protect cached data not yet protected with DNSSEC. It's a good point, thanks. I will rewrite the recommendations according to what is essential and also against which type of attack and to what network configuration it applies. That sounds like a more significant bug than port obscurity or randomization. If it is a bug, which should be addressed first in that software or those installations, this DNSSEC bug or the recommendations in the mail message? It it is a significant DNSSEC bug, it would be good if a future version of the mail message mentioned it. It is not always a bug imho. Some resolvers, e.g., unbound, explicitly allow such permissive modes of DNSSEC validation, others support this implicitly and the rest may simply be not configured properly. Permissive modes are typically used during the incremental deployment phases prior to full adoption, e.g., to see that DNSSEC works ok, and does not break anything. Permissive mode introduces a security vulnerability - since a resolver signals support of DNSSEC, it receives large (often fragmented) responses, and thus may be vulnerable to our cache poisoning attack. On the other hand, network operators, may be concerned (often justly) with enforcing strict DNSSEC validation, due to interoperability (or other) problems (we discuss this in more detail in `Availability and Security Challenges Towards Adoption of DNSSEC`). On Sat, Oct 19, 2013 at 7:14 PM, Haya Shulman haya.shul...@gmail.comwrote: IMHO, DNSSEC is simply the natural defense against the attacks, which is why I did not explicitly mention it, but I definitely had it in mind :-) Regarding the proxy-behind-upstream: to prevent the attacks DNSSEC has to be deployed(and validated) on the proxy. Currently it seems that there are proxies that signal support of DNSSEC (via the DO bit), but do not validate responses, and validation is typically performed by the upstream forwarder. --- The complete absense of any mention of DNSSEC among those recommendations (or elsewhere) reads like an implicit claim that DNSSEC would not help. Even if that claim was not intended, would it be accurate? Would DNSSEC make any of recommendations less necessary or perhaps even moot? If DNSSEC by itself would be effective against cache poisoning, then isn't it among the recommendations, especially for Resolver-behind-Upstream? Why aren't efforts to protect port randomization, hide hidden servers and so forth like trying to make it safe to use .rhosts and /etc/hosts.equiv files by filtering ICMP dedirects and IP source routing, and strengthening TCP initial sequence numbers? On Sat, Oct 19, 2013 at 6:53 PM, Haya Shulman haya.shul...@gmail.comwrote: This is correct, the conclusion from our results (and mentioned in all our papers on DNS security) is to deploy DNSSEC (fully and correctly). We are proponents of cryptographic defenses, and I think that DNSSEC is the most suitable (proposed and standardised) mechanism to protect DNS against cache poisoning. Deployment of new Internet mechanisms is always challenging (and the same applies to DNSSEC). Therefore, we recommend short term countermeasures (against vulnerabilities that we found) and also investigate mechanisms to facilitate deployment of DNSSEC. On Sat, Oct 19, 2013 at 6:05 PM, Phil Regnauld regna...@nsrc.org wrote: P Vixie (paul) writes: M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie I was wondering about that, and went to look at the abstracts: http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 Security of Patched DNS [...] We present countermeasures preventing our attacks; however, we believe that our attacks provide additional motivation for adoption of DNSSEC (or other MitM-secure defenses). So at least this seems to be mentioned in the papers themselves (Id didn't pay to find out). But I agree that the summary would benefit from stating this, as it's currently only way to to avoid poisoning. Not stating it could lead some to believe that these attacks are immune to DNSSEC protection of the cache. Cheers, Phil -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de -- Haya Shulman Technische Universität Darmstadt FB Informatik/EC SPRIDE Morewegstr. 30 64293 Darmstadt Tel. +49 6151 16-75540 www.ec-spride.de -- Haya Shulman Technische Universität Darmstadt
Re: [dns-operations] Ang.: ALERT: .QA CCTLD in wrong hands currently
On Sun, Oct 20, 2013 at 05:19:45PM +0100, Jim Reid j...@rfc1035.com wrote a message of 14 lines which said: https://twitter.com/Official_SEA16/status/391339315562688513 If it's on Twitter it must be true, right? :-) It has been discussed on this list more than 24 h ago so it is old news, and Twitter was right here. Expect a report by Duane Wessels at the next OARC workshop, with great graphs :-) Some people may wish to flush their caches. More than one day after the registry was repaired, 1.5 % of the RIPE Atlas probes I interrogated still have the wrong addresses (31.170.160.0/22) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
I do not see an answer to my intended question. Again, given inevitiably limited real time, over-committed programmer and DNS adminstrator hours, and limited money, should problems in DNSSEC implementations and installations be addressed before or after your issues? Some of our recommendations can be useful for security (also against other attacks - see earlier email), and can assist with interoperability problems, that may emerge during deployment of DNSSEC. For instance, our recommendations for IP layer, e.g., reducing IP defragmentation cache size or randomising IP-ID, can be useful not only against poisoning attacks (in particular, fragmentation has a long history of exploits for denial/degradation of service attacks); Port randomisation is also a useful feature, not only against cache poisonig (see earlier email); and so on. Should the people working on DNS implementations prioritize making their DNSSEC code more robust and easier to use above or below addressing your issues? I do not think that there is a general answer to this question, as it depends on the specific organisation/network. Which should be built or fixed first, mechanisms such as auto-signing that make DNSSEC easier to deploy and more robust (e.g. reducing accidental signature expiration), or your cache pollution issues? Should requests for proposals and requests for quotes rank DNSSEC features including ease of DNSSEC use above or below fixes for your cache pollution issues? Should you spend most of your own time looking for improvements and bugs in DNSSEC or looking for more ways to pollute DNS caches where DNSSEC is not used? Both are important: (1) disclosing attacks raises awareness to the significance of systematic defenses, and motivates deployment thereof; it also enables the networks to protect themselves in the meanwhile. I would not be surprised if similar attacks were deployed in the Internet, without anyone being aware of their existence. (2) I also study deployment challenges and improvements (and not only attacks). I think that is neither a response to my claim, accurate, nor relevant to what I understood of your claim about forwarders. How can something that introduces a security vulnerability not always be a bug in your or anyone's opinion? --- Sure, permissive mode is an explicit feature. I believe a bug is something that is not intentionally introduced (well, at least not as a general rule). --- If you meant instead to say that permissive verification is a less important bug that other things, then how do you rank your cache pollution issues against other bugs starting with not deploying DNSSEC? --- I would hope that disclosure may help some organisations and networks protect themselves. The other option is to be unaware of the vulnerabilities (and their exploits). Do you think vulnerabilities are better left for attackers to take care of? BTW, we withheld some of the works from publication, and tried to coordinate disclosure. Your work would be valuable if it helped pressure people to get busy on DNSSEC. However, instead of saying Use DNSSEC because port randomization has these newly discovered weaknesses, you only grudgingly and under pressure admit that DNSSEC even exists. Many networks cannot deploy DNSSEC overnight, due to different factors. Port randomisation algorithms that were proposed have weaknesses, but proper randomisation should solve these problems. I was under pressure to catch a flight when I responded and forgot DNSSEC; it is as dear to me as it is to you :-) On Sun, Oct 20, 2013 at 10:42 PM, Haya Shulman haya.shul...@gmail.comwrote: In that case, on what should an organization spend time or money first, on DNSSEC or the recommendations in the mail message? Would it be better if each of the recommendations in the mail message started with something like this? Deploy DNSSEC, and consider the follow to help protect cached data not yet protected with DNSSEC. It's a good point, thanks. I will rewrite the recommendations according to what is essential and also against which type of attack and to what network configuration it applies. That sounds like a more significant bug than port obscurity or randomization. If it is a bug, which should be addressed first in that software or those installations, this DNSSEC bug or the recommendations in the mail message? It it is a significant DNSSEC bug, it would be good if a future version of the mail message mentioned it. It is not always a bug imho. Some resolvers, e.g., unbound, explicitly allow such permissive modes of DNSSEC validation, others support this implicitly and the rest may simply be not configured properly. Permissive modes are typically used during the incremental deployment phases prior to full adoption, e.g., to see that DNSSEC works ok, and does not break anything. Permissive mode introduces a security vulnerability - since a resolver signals support of
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On Oct 20, 2013, at 2:16 PM, Vernon Schryver v...@rhyolite.com wrote: Should the people working on DNS implementations prioritize making their DNSSEC code more robust and easier to use above or below addressing your issues? I'd say below. Resolver operators (hopefully) want to protect their caches. DNSSEC will do that, but only if people are signing their zones. There are lots of external parties (e.g., registries, registrars, software developers, resolver operators, etc) to get DNSSEC deployed and there remains very little incentive for anyone to sign their zones, regardless of how robust and easy it might be made. The alternative would be to disregard current and future cache poisoning attacks. Pragmatically speaking, I personally think it highly questionable to ignore cache poisoning vulnerabilities because something which isn't yet deployed to 10% of the Internet will fix it. This would be a bit like saying don't deploy RRL because BCP38 is the correct answer to the problem. Your work would be valuable if it helped pressure people to get busy on DNSSEC. Seems to me the work they have done is valuable, regardless of DNSSEC. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
From: Haya Shulman haya.shul...@gmail.com I do not see an answer to my intended question. Again, given inevitiably limited real time, over-committed programmer and DNS adminstrator hours, and limited money, should problems in DNSSEC implementations and installations be addressed before or after your issues? Some of our recommendations can be useful for security (also against other attacks - see earlier email), and can assist with interoperability problems, that may emerge during deployment of DNSSEC. For instance, our recommendations for IP layer, e.g., reducing IP defragmentation cache size or randomising IP-ID, can be useful not only against poisoning attacks (in particular, fragmentation has a long history of exploits for denial/degradation of service attacks); Port randomisation is also a useful feature, not only against cache poisonig (see earlier email); and so on. Even if that were correct (it's partly wrong), it would not answer my question. Should the people working on DNS implementations prioritize making their DNSSEC code more robust and easier to use above or below addressing your issues? I do not think that there is a general answer to this question, as it depends on the specific organisation/network. I guess I'll play a little more by naming three specific outfits. Should the organizations responsible for BIND, nsd, and unbound to work on DNSSEC improvements and bug fixes before or after your issues? Please do not feel constrained to give a single general answer for all three organizations but please give 3 specific answers for those 3 specific organizations. Which should be built or fixed first, mechanisms such as auto-signing that make DNSSEC easier to deploy and more robust (e.g. reducing accidental signature expiration), or your cache pollution issues? Should requests for proposals and requests for quotes rank DNSSEC features including ease of DNSSEC use above or below fixes for your cache pollution issues? Should you spend most of your own time looking for improvements and bugs in DNSSEC or looking for more ways to pollute DNS caches where DNSSEC is not used? Both are important: (1) disclosing attacks raises awareness to the significance of systematic defenses, and motivates deployment thereof; it also enables the networks to protect themselves in the meanwhile. I would not be surprised if similar attacks were deployed in the Internet, without anyone being aware of their existence. (2) I also study deployment challenges and improvements (and not only attacks). Do you think anyone sees that as responsive to any of my questions? I think that is neither a response to my claim, accurate, nor relevant to what I understood of your claim about forwarders. How can something that introduces a security vulnerability not always be a bug in your or anyone's opinion? Sure, permissive mode is an explicit feature. I believe a bug is something that is not intentionally introduced (well, at least not as a general rule). On the contrary, in the real world, any and all computer sins of commission and many sins of admission are bugs according to the people who matter, users and customers. The programmer, vendor, or whatever can sometimes escape censure by pointing at a specification, but even when it works, that tactic never wins respect, friends, or more business, and it can lose old business. If you meant instead to say that permissive verification is a less important bug that other things, then how do you rank your cache pollution issues against other bugs starting with not deploying DNSSEC? I would hope that disclosure may help some organisations and networks protect themselves. The other option is to be unaware of the vulnerabilities (and their exploits). Do you think vulnerabilities are better left for attackers to take care of? That implication that I have ever said or suggested that you should not have published your findings is disingenuous and offensive. My problem with your findings is that your are grossly overstating their significance. None of them will ever be seen in the wild. As As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and as I've said, showing the inevitiable weakness of port randomization is good. BTW, we withheld some of the works from publication, and tried to coordinate disclosure. That is the right thing to do except when exploits have already been seen in the wild or are likely to be seen soon. However, given the practical certainty that none of your vulnerabilities will ever be seen in the wild, no one should have complained if you had not. Your work would be valuable if it helped pressure people to get busy on DNSSEC. However, instead of saying Use DNSSEC because port randomization has these newly discovered weaknesses, you only grudgingly and under pressure admit that DNSSEC even exists. Many networks cannot deploy DNSSEC overnight, due to different
Re: [dns-operations] summary of recent vulnerabilities in DNS security.
From: David Conrad d...@virtualized.org Should the people working on DNS implementations prioritize making their DNSSEC code more robust and easier to use above or below addressing your issues? I'd say below. Resolver operators (hopefully) want to protect their caches. DNSSEC = will do that, but only if people are signing their zones. There are lots = of external parties (e.g., registries, registrars, software developers, = resolver operators, etc) to get DNSSEC deployed and there remains very = little incentive for anyone to sign their zones, regardless of how = robust and easy it might be made. The alternative would be to disregard current and future cache poisoning = attacks. Pragmatically speaking, I personally think it highly = questionable to ignore cache poisoning vulnerabilities because something = which isn't yet deployed to 10% of the Internet will fix it. This would be a bit like saying don't deploy RRL because BCP38 is the = correct answer to the problem. On the contrary, anyone who spends even one minute on RRL that could be spent on BCP 38 should be...well, I can't say shot because I oppose capital punishment. RRL should be considered only after everything possible has been done for BCP 38. Similarly, only after there is nothing that you can do improve your DNSSEC implementation should you consider improving your port randomization. I agree that port randomization should come before a lot of other things, although that's not saying much because the major DNS implementations are filled with things I would have vetoed if I'd been king. I think their work showing the weaknesses of port randomization in theory and practice is important, because it shows that no security should depend on adversaries being unable to inject packets into UDP or TCP streams because ports are secret. I strongly disagree with Haya Shulman's words to Paul Vixie that seemed to say that their work might fix other applications and protocols. I think their work shows that port randomization is like RRL, a lame kludge of a mess that is better than nothing but not even a distant second choice to actually fixing the problem. I say only consider improving port randomization, because nothing should be added to anything or even changed without clear and significant benefits, especially in security related areas. You've been around long enough to remember many added nice features caused big security problems. Vernon Schryverv...@rhyolite.com P.S. I'm licensed by http://ss.vix.su/~vixie/isc-tn-2012-1.txt and http://ss.vix.su/~vjs/rrlrpz.html to criticize RRL. P.P.S. I've often heard Paul say much the same thing about RRL being a bad idea except compared the alternative of ignoring the consequences of everyone else's failure to deploy BCP 38. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
