The Death of Hope

This is an opinion piece on why the author considers it is important - if not vital - that plans should be put in place as soon as possible to secure (sign) all the top level domains. Countries, in particular, are failing their citizens and indeed placing them at risk, both in economic and security terms, by their abysmal lack of progress and urgency.

But Hope is all we have

When a query request is sent to any DNS for information, for example the address of a domain's web or email server, all we can currently do is hope that the query response data is correct. There no way of proving that it is correct. In point of fact the response could have been duped or spoofed in a variety of ways. For instance, the query response may have been supplied from a poisoned cache - a temporary location used to speed up responses and maintained in DNS caches by ISPs and many individual sites - which may contain incorrect (poisoned) data. The query may have been intercepted and bad data substituted in the response. The query may have been re-directed to a bogus (or hijacked) server for the domain in question and which sends people to a legitimate looking, but fake, location.

Or the response could be perfectly valid, containing good data from the correct source. We can, currently, only hope this is the case.

We can only hope that we really are going to our favorite financial institution's web site and typing in our passwords. We can only hope that our kids really are going to the sites we approved and supplying sensitive information. We can only hope that in times of emergency we can get to news, government and other information resources that could make the difference between panic and a measured response rather than ones created to amplify the effect of the emergency. We can only hope that our country code continues to even exist on the internet.

In a situation where revenues, reputation and security (commercial or national) are at stake, such uncertainty is not acceptable.

Of Phishing, Pharming and acting on the wrong stage

Financial Institutions all over the world are deploying significant resources to prevent Phishing scams. Investing substantial efforts into publicity and customer warnings. Rightly so, in the effort to protect their customers from inadvertently disclosing sensitive information to fake web sites. It is easy for unsuspecting users to be persuaded into following typical links. Of course relatively savvy computer users would never fall for such a trick when the link to follow says www.slimytoadscamsite.com rather than www.respectedfinancialinstitutionrealsite.com. But if the link is the real name of the financial institution, that has been replaced through a DNS poisoning attack, and goes to a copied version of the real site - it is likely that even the most savvy of users would merrily follow such links. And happily type in their sensitive information which is then gleefully harvested by the bad guys.

Even more insidious are the so called Pharming attacks. Why bother sending out email - just poison a few DNS caches (actually the more the merrier) and sit back and wait for we happy surfers to arrive at the bad guys fake sites. The next time you go to your favorite financial institution, ask yourself: is this really the site or has it been stolen by bad guys? And the answer: You hope it is the right site. That's it. You hope it is the right site. All sound a tad far-fetched. A tad gloomy. A tad panicky for no good reason. If you think this scenario is not possible then you may want to read this PDF. It's pretty techy stuff but documents a DNS spoofing attack - and others - which was demonstrated during 2005 to a very cynical, and very savvy, group of people to illustrate just how simple, and transparent, such an attack could be.

A short aside: The modern trend for very low Time-to-Live (TTL) values on DNS records seems to be widely used in the financial services industry - among others. It is typically designed to assist load balancing but means that the bad guys get the chance to intercept and poison DNS caches every 5 minutes or less when DNS records are refreshed. Are we being helpful or what. Bring on the clowns.

While the discussion so far has focussed on financial institutions, consider the same scenario, stealing or spoofing of web, and other, sites in a much darker context. If the bad guys, with relatively modest resources, can play havoc with parts of the financial system what could organisation with serious resources do to amplify the effects of a physical attack - a terrorist attack. At a time when first line responders, government co-ordination activities, armed forces, news organisations and the ordinary citizens's need for timely and accurate information is acute, were the DNS infrastructure to be spoofed and provide disinformation - just how bad could it get?

The point here is not to deride the efforts of those trying to combat the various scams and attacks that happen daily but rather to suggest that without fixing the problems in the underlying infrastructure, any solutions will be less than optimally effective - they are quite simply playing on the wrong stage.

Killing Hope

In April 2005 the IETF published updated specification for DNS Security (DNSSEC). The standards make it possible for suitably configured DNS systems to know, with certainty, that the data that was sent from a definitive DNS source was correctly received and was not tampered with or spoofed. They simply kill hope. And replace it with proof. These new standards are the result of much hard work, over more than 10 years, by individuals and organisations across the world. They have been tested in laboratory and mock operational environments for more than two years and there are two high quality, Open Source, implementations (BIND and NSD) freely available.

Sweden has announced that it is now securing its country zone (dot-se), RIPE has announced that its reverse map zone has been secured and there is talk that the root zone will be secured - perhaps by mid 2006 (early 2007 update - root zone is still not signed). Progress is being made.

Unfortunately not enough.

Lest we are in no doubt - the process of securing the DNS is not trivial. It requires new procedures and tools - some of which exist, some of which are under development, some of which still need development and funding. It will require that organizations that operate DNS servers - either simple caching systems or master or slave servers - implement changes which can range from relatively modest to seriously complex in order that the full benefits can be realised. This process requires time, training, development and publicity. It requires resources.

Countries, especially, must put their efforts behind this process. They control their name space, they have the freedom, incentive and resources to act. They are failing their citizens - placing them at avoidable risk - by not doing so.


Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 dns records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfc's
change log