Tag Archives: DNS

DNS Meltdown

There have been enough clues over the last few years that the global DNS system as used in its current form, is particularly frail and subject to simple attacks. Yet the main commercial protagonists piggy-backing onto this system, have remained almost spectacularly silent on the issue and there seems to be little impetus to change things. Similar to the massive holes found in OpenSSL 2 years ago, the DNS system performs a critical job with very little support. As was the case with OpenSSL after these issues, it’s probably time for a few of the larger companies who are making a living from the internet, to come together and add their financial muscle to the DNS system.

Dyn’s meltdown last Friday is a small hint of what’s to come.  But besides Dyn’s specific problems, there are some issues here that need addressing:

First, why do global brands like CNN, Twitter and Spotify use a 3rd party for their authoritative DNS? This alone beggars belief … it takes a skilled IT admin a few hours to put up a geo-safe, high-availability authoritative DNS solution. Were they trying to save money? Was it simply the easy route? Or maybe they were sold on the Cloud gravy train … where TITSUP* seems to be a common theme.

Second, is it too much to ask that manufacturers of IoT devices, do at least the simplest of security audits on their products? Perhaps there should be a global program where a seal of approval is  given to IoT devices once they’ve passed a security test.

And finally, the DNS system itself, an aging 35-year old solution that’s well past its sell-by date. Amplification attacks on the DNS infrastructure are simple to enact. The DNS system needs to be rebuilt with security in mind even if this means running a dual-system for a period or breaking the internet.

Because if we don’t do something soon, a trivial attack on the DNS system will mean total carnage for the internet as we know it.

*total inability to support user performance

DNSSEC finally on the move

It looks like DNSSEC is breing implemented at the root level world-wide. Almost 2 years after the first country level signing ( .se for Sweden ), the K-, D- and E-root servers operated by RIPE, University of Maryland and NASA respectively, started root signing this week past. 7 of the 13 root servers now supply DNS record signing.

The DNS Security Extensions protocol, called DNSSEC in short, is designed to provide improved DNS security. DNSSEC uses cryptographic signatures to authenticate the responses to DNS queries, which will prevent attackers from forging responses via security holes in the DNS protocol, such as those described by Dan Kaminski (cache poisoning). With this protocol, responses to DNS queries are only accepted as authentic if a public key can be matched with a private key. However, signatures can’t be validated during the introductory phase. As a result, initially it will be unlikely that users notice the introduction of DNSSEC on the RIPE root server. While the response packets containing the signatures will be significantly larger, experts say that this doesn’t present a problem if the respective resolvers are implemented correctly. For the time being, users will also still be able to access one of the remaining 6 root servers without DNSSEC. ICANN, VeriSign and the NTIA decided on this gradual transition as a precautionary measure.

Personally I think this has been a long time coming. I had an excellent 2-day training course on DNSSEC with BIND a year ago ( courtesy of coza/Uniforum ) and it’s good to see the hard work of many engineers coming to fruition. Considering the amount of negativity as recently as a year ago, especially from the commercial root server operators ( read Verisign and co. ), it’s great to see DNSSEC in action.

Bind and Nominum

I thought yesterday’s article ( well it actually reads like an advertorial ) on ZDNet UK regarding Bind and Niminum’s new Skye offering, was a joke. Then I realised that no, it wasn’t. But why would the ZDNet author, Toby Wolpe, start with such an inflammatory header? Is he actually looking to be flamed and seen as a useless tech writer? And his lack of challenge to Skye GM Jon Shalowitz, was appalling. Let’s go through Mr. Jon Shalowitz’s arguments for his product:

1. “Freeware legacy DNS is the internet’s dirty little secret — and it’s not even little, it’s probably a big secret. Because if you think of all the places outside of where Nominum is today — whether it’s the majority of enterprise accounts or some of the smaller ISPs — they all have essentially been running freeware up until now”

What? Does Shalowitz actually know the difference between Freeware and OSS? Does  he know that Bind is not Freeware? And why is it a dirty little secret? No answer on any of these …

2. “Given all the nasty things that have happened this year, freeware is a recipe for problems, and it’s just going to get worse.”

There haven’t been that many nasty things this year with BIND specifically – the problems in DNS relate to DNS as a whole and not a single product. Seeing as BIND in effect sets the standards for DNS, Mr. Shalowitz’s product would have the same vulnerabilities. Unless he is selling a non-standard product; but seeing as it’s closed source, no one can make that determination.

3. “So we’ve seen the majority of the world’s top ISPs migrating away from freeware to a solution that is carrier-grade, commercial-grade and secure.”

The top ISP’s have never migrated anywhere – they’ve always used their own solutions. However, considering that the top ISP’s only make up a very small portion of DNS usage on the planet, that leaves BIND as running the bulk of the internet.

4. “If I have a secret way of blocking a hacker from attacking my software, if it’s freeware or open source, the hacker can look at the code.”

Shalowitz’s argument for security by obscurity was debunked many years ago already – why is he peddling this nonsense now? Surely he can’t be that uninformed …

5. “I would respond to them by saying, just look at the facts over the past six months, at the number of vulnerabilities announced and the number of patches that had to made to Bind and freeware products. And Nominum has not had a single known vulnerability in its software.”

He links to one hole in BIND itself in the last 6 months. Pity he didn’t mentioned the hole in his own software the previous 6 months …

6. “But we run over half the internet”

Yes? Since when? Where are the stats?

Some more info: Nominum’s Vantio product was subject to the cache poisoning vulnerability from last year while many OSS DNS packages weren’t. So is Shalowitz being deliberately disingenuous or is just that uninformed? In closing, one of Nominum’s DNS servers is running BIND while their web server runs Apache and Linux …

UPDATE: ZDNet US’ Dan Blankenhorn has also weighed in on the subject and seems to be as mystified as me on Wolpe’s article …

DNS Security

.. has always been a hot topic, considering that it is the cornerstone of the Internet. Without DNS or with a broken DNS, the Internet stops working ( correctly ) so it’s important that this building block is always in top shape, something that has been lacking from time to time. Considering it’s age and what it was originally designed  to address, it has done well so far but it has to do more for the foreseeable future, while maintaining that all important compatibility with previous releases/versions. No one is really in the position to just upgrade the Internet.

But the security aspect is littered with politics, corporate/government agendas and backward compatibility requirements for obvious reasons and it’s been quite a slog to get to a point where everyone will agree on changes required going forward. One such change with security in mind is DNSSEC, which provides a means for zones/dns records to be signed and a mechanism for DNS servers to validate the crypt signature of a domain by traversing the DNS tree to root – if the check fails then the DNS server simply rejects/ignores the request.

The main problem at the moment is that all TLD zones need to be signed by the next level up – the root domain, which is currently not signed and this is where all the fuss is. In addition, as someone has done training on DNSSEC, it is not a simple thing to sign domains, especially above the standard administrative requirements for DNS. So anyone using DNSSEC now needs to install trust anchors for each signed zone on their servers. This is of course a big issue …

The only 2 signed domains at the moment are .se and .org – and ISPs in these zones are only authorizing their zones and none other. Chicken and egg … the IETF, Internet Society ( ISOC ) and DNS experts have been sitting around a table hosted by .SE this week to discuss the status of DNSSEC and other options for DNS going forward. More info here Let’s hope they can all agree as DNS sorely needs to refreshing.

Bind security issues

This time the security issue is with BIND 9 specifically and not DNS in general as Dan Kaminsky’s fabled cache poisoning issue from last year. Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Slaves are unaffected however. Patches are available for the 9.4, 9.5 and 9.6 streams of BIND.

DynDNS have been quick off the mark and updated their DNS services as of last night ( 29.7.1009 ) but they will probably be in the minority as these things tend to take time to filter through to all those managing DNS throughout the Internet. More info here

DNS security saved by Nominum?

Besides SPR ( source port randomisation ), Nominum have a number of other security options built into their Vantio DNS product:

  • SPR
  • defense: strange queries result in a direct connection to the server
  • resistance: tries not to give out ip’s for name servers ( glue records )
  • warns ISP of attack

So, interesting options from Nominum but as I understand it, you can’t actually buy the product – it’s more of a lease type thing. And not cheap, cheap …

Eeek, but let’s look closer. Nominum only fixes the cache poisoning problem for their own users. Defense: shouldn’t they always have a direct secure connection to the server? Resistance: isn’t this what hiding a dns server is all about? Blowing smoke is what this is all about. Perhaps they should give their ‘we fix the DNS for everyone’ solutions to everyone so that we can get rid of the issue once and for all.

OpenID and SSL/DNS poisoning

Ben Laurie of Google’s Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166).

In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs.

In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS.

Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider.

There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to “ensure” that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker.

The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP.

DNS – Source Port Randomisation

Dan Kaminsky gave a very interesting talk on the recent DNS issues as part of the Black Hat USA 2008 conference currently on the go in Las Vegas. Originally DJ Bernstein had advocated ( and put into DJBDNS ) source port randomisation as part of the DNS request but no one else had as they thought transaction id randomisation was good enough. Well it wasn’t, so the current ‘fix’ is to do just that. Unfortunately, the attempts at protection of internal networks ( Firewall NAT’ing ) ends up removing this protection due to it removing the random source port!!!

Dan also has a very cool video of the spread of DNS updates ( or the lack thereof ):
Red — Unpatched
Yellow — Patched, but the NAT is screwing things up
Green — OK

DNS Issues

Dan Kaminsky previewed information relating to possibly the worst DNS-related exploit ever, earlier this month. The issue is a cache poisoning vulnerability and can result in DNS answers containing fiddled information. This is actually a general design issue more than any vendor-specific issue. Imagine entering a url in your browser and been taken to another site instead, one that was not expected, where malicious code is auto executed or worse, a fake copy of the target site has been developed where you unintentionally enter personal defining information such as user names and passwords.

All vendors’ DNS implementations were affected and most have updated their respective versions by now – a notable exception is Apple’s MacOS X Server … Apparently Apple are to busy with more important things like MobileMe issues. Considering that there is active exploit code circulating, it’s vitally important that if you run an authoritative name server, that you update your DNS applications soonest. A test is available on Dan’s site if need more info or to check your system.

A little birdie has also whispered in my ear that BIND 9.5.x-p has been particularly unstable; just a note for those using the latest version of the most popular DNS server on the market.