DNS lords expose netizens to 'poisoning' More than a decade after serious holes were discovered in the internet's address lookup system, end users remain vulnerable to so-called domain name system cache poisoning, a security researcher has warned. Developers of the software that handles DNS lookups have scrambled to patch buggy code that could allow the attacks, but …
The space you wasted telling your audience OF IT PROFESSIONALS that:
"DNS lookups are one of the most basic and common tasks on the internet. They translate human-friendly names such as theregister.co.uk with machine-readable IP addresses like 212.100.234.54."
would have been much better used with a list or link to a list of affected servers, or of those systems which use real crypto.
If the underlying DNS infrastructure is ever going to change, the Internet Engineering Task Force (IETF) has got to do to more research, create more secure technology and spread the word about it. Then ICANN and IETF both need to force the issue onto the operators of the root servers and top-level domain servers.
IETF does have a working group just to TALK about security (http://www.ietf.org/html.charters/wg-dir.html#Security%20Area), but unfortunately they don't seem to be DOING anything.
It makes a girl want to start breaking kneecaps.
Well firstly the IETF have been and are doing something (DNSSEC) this protocol is ready to roll (and is being rolled in places) however it does need a push from a political (and marketing) point of view.
As for the zero cache although this is a good idea in principal if everybody were to ignore the TTL's on zones and there was no caching we would have a helluva lot more traffic on an already very congested internet, so not really scalable.
The answer is short term to ensure the ID's are propely randomised, and long term to deploy DNSSEC.
Brett
Doesn't the very definition a pseudo-random number generator mean that it isn't ever truly random and thus will always be able to be predicted?
It may not be easy to predict it, but nevertheless, given enough time you will always be able to predict it.
Surely then, until they use true random number generators everything will be vulnerable to pseudo-random number prediction.
@Samuel Walker
Do you know of any examples of "true" random number generators in the programming world? Or even the distant hope of one?
@Brett
Good on ya! Credit where credit is due. Many articles about things like cache poisoning, spamming and other internet-age bugaboos fail to mention what is available to fight the beasties, even as those who are responsible for implementing those solutions (or at least the next generation of potential solutions) ignore them. DNSSEC for cache poisoning, SMTP-Auth for spam. etc.
When a potential solution will cost real money to implement, the big players avoid adopting it, choosing instead to hope nothing really bad happens or to push responsibility for fending off the problem onto some other player.
"Users, activate those phishing filters, now with cache poisoning detection technology!"
"Users, buy our latest anti-spam filter!"
What you say here:
"It may not be easy to predict it, but nevertheless, given enough time you will always be able to predict it."
.. is of course completely correct. But not all PRNGs are equal, and in practical terms, a crude one that can be guessed in a few hundred to a few tens of thousands of guesses is predictable, whereas a crypto-based PRNG that would require a brute-force attack lasting longer than the likely span of the universe is, to all intents and purposes, not predictable.
The key difference is whether your number generator is designed to produce a good statistical spread of numbers, or if it's designed to be difficult to predict. It's possible to have a random number generator with excellent statistical properties that is highly predictable, or a highly unpredictable generator with terrible statistical properties. The first is good for monte carlo simulations, the latter for cryptography.
Unfortunately most programmers don't seem to understand the difference.
Brett: Up until RFC 5255 was released this year, there were some good reasons not to implement DNSSEC: it provided a means to list all the names that exist in a domain without testing every possibility.
As well as sending signed responses about existing domains, DNSSEC sends signed responses for domains that do not exist (otherwise you could spoof a "no such domain" response for a real domain). One of the constraints on DNSSEC is that all the response data can be signed ahead of time so that the DNS server doesn't need access to the private key. It'd be impractical to create signed responses for every possible non-existent domain, so the signed negative responses actually assert that ranges of domains do not exist. By enumerating the gaps between the domains, you can discover what domains really exist.
Given that they only fixed this problem earlier this year (by introducing hashing to the negative responses), it isn't too surprising that it isn't more widely used yet.
@zcat: One of our local banks has an interesting approach to the problem.. they set the DNS expiry time to zero so that it's never cached and every lookup has to go back to their server (in Australia)
Which is exactly why the DNS caches in Australian ISPs set a minimum cache time. We got sick and tired of that bank's DNS server being temporarily unavailable and the blame for the apparent lack of connectivity falling on us ISPs.
This problem is easily fixed by deploying DNSSEC. It's well time the DNS registries got that happening. DNSSEC isn't suitable for use on all names in a firm, but it's deployment against the DNS names supporting public services would address most of the real-life spoofing problem.
I suspect that if you google for them, you'll find hardware-based true random numbers which use a natural random noise source like the reverse biased breakdown noise from a signal diode, fed to some analogue to digital convertors. It's not rocket science, but I'd suspect they're used mostly in the intelligence community rather than in the mainstream corporate world.
Just to add my two bits. Amit Klein informed us in a very proper manner of our deficient random generator, and was helpful in finding a good replacement. We implemented his suggestion of going to AES in CTR-mode, which appears to work very well.
I can understand why not everybody goes down this route though - we've already had problems with people being unable to distribute PowerDNS because it suddenly contains 'encryption'.
DNS is vulnerable enough as it is, even with good random. Bad random is inexcusable. For more details, see http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-03
Bert Hubert
PowerDNS.COM BV
"Do you know of any examples of 'true' random number generators in the programming world? Or even the distant hope of one?"
Assuming you're not sticking to 100% software solutions then there are plenty of true random number generators. Most of them are based around devices that sample the background radiation. You can get pretty good results from certain wireless cards that generate a number based on whatever they can pick up.
Aside from the marvels of "unlimited" (but only if it's not much HTTP traffic) "broadband" (as long as you live inside a telephone exchange) and how the connection providers have marketed the interwebtubes, the single biggest tickler is that Joe Public actually believes that this network is in some way secure.
So much of the underlying system is still run on trust:
- I trust my peers not to try to obliterate Youtube outside .pk... oops
- I trust an unknown third party to guarantee my banks web server is my banks web server
- I trust grandma@freeserve.com is really grandma@freeserve.com
- I trust an unauthenticated address translation system to tell me where to connect
- I trust a badly maintained personal computer with the intimate details of my life
The list goes on and on. When I tell legal clients that email is not privacy-guaranteed (and more akin to writing your message on a postcard) unless it's encrypted (and even then....blah) they are genuinely shocked, as conventional wisdom presents email as more like letters than postcards.
Yes, DNS is insecure. So's the rest of it. But don't tell the unwashed masses.
50c PIC CPU connected to 5c 3.3v zener diode as a noise source. I2C or serial connection to host.
(You can get 8pin SM PIC with built in A/D).
I'd not bother with wireless. Too many non-random signals.
The noise from a Zener is real random noise from Molecular kinetic/heat energy. The amount is related to temperature. It's usable from DC up to 2GHz as a "white noise" source to align / check filters with a Spectrum analyser.
James:
I am well aware of RFC5255 and the problems it fixes, and am very well aware of how dnssec works (I deployed it on the European Reverse tree) hopefully when there are some solid implementations of nsec3 we will start to see more deployments, however we still need support from ISP's and there needs to be a cost benefit for them to do it.
Sara: You are right the root operators are not/have not done anything with regard to dnssec in . However don't blame them the key and signing policies are political issues that need to come from ICANN, if you really want to see this happen get involved with ICANN and push it through.
Brett
Errr, this kind of research was done YEARS ago using phase space analysis. Like 7 years ago. Read up on Michael Zalewskis research at http://lcamtuf.coredump.cx/oldtcp/tcpseq.html.
It was primarily targetted at TCP hijacking, but DNS was also considered and shown to be vulnerable to the same weakness.
No such thing as absolute security, only ever relative to the ability of the attacker and as secure as the weakest link...this DNS poisoning and variants of, has been going on for years... use numeric IPs. Don't assume everything is OK, and that the system will `look after you` - it won't. Keep your eyes open. Do not trust everything (or anything) you see, until you have verified it to the best of your ability. DNSsec might sound super now, but I guarantee in a few months, definitely years, it will be about as secure as a wet paper bag. Be paranoid, do not trust your ISPs or any silly little notions of security or data protection. Research, probe, test... take nothing for granted...buy a decent Cisco router, or if you can't afford it then flash the firmware of some cheap generic unit to something halfway decent (eg DDWRT for linksys WRT54G units) and lock it down as much as possible using what is available. Audit regularly, reflash regularly.
Alternatively just pick up a pen and write on paper,or type then print cipher, put it in a sealed envelope and send via private courier to be scanned and unencrypted by recipient- it might take longer, but it's a lot more secure...
But the distinction is not human friendly to machine readable.
Both are machine readable, and well a domain name is perhaps more human friendly, but so is an IP number in many instances.
A domain name is just what it says on the tin - a name that associates a domain of addresses.
So a domain name is something like theregister.co.uk, a fully qualified domain name with host would be www.theregister.co.uk and that address would be associated with an IP number. The point is they are separate systems that interface with each other. DNS uses IP for routing, but that is not a fixed requirement. You could theoretically route via DNS and we could forget IP numbers altogether.
Machine readable and human friendly is not a true distinction between DNS and IP addresses, but it is a common mistake.
> DNSsec might sound super now, but I guarantee in a few months, definitely years, it will be about as secure as a wet paper bag.
In that case, I look forward to you presenting you with a couple of Nobel Prizes and the Fields Medal. And with these powers of prediction, you must be able to tell me what the winning numbers will be in Saturday's lotto draw. I need some extra walking around cash to buy some more bling.
DNSSEC uses cryptographic hash algorithms and public key cryptography to sign DNS data: SHA, MD5, DSA, RSA, etc, etc. If you can guarantee these will be compromised in a few months or years, you must know about a world-shattering breakthrough in number theory.
James Grinter asks: So, the random number generator in BIND is poor, but we can all rest assured that they got it right with implementing DNSSEC?
Two points:
[1] There's only a 16-bit space for DNS query IDs. [They were invented 25 years ago to help a resolving server match responses to the outstanding queries it had made. Read RFC 1035. They never are and never were meant to provide a security blanket.] This is a fundamental limitation of the DNS protocol. Feel free to rewrite it and reboot the internet.
Using good entropy sources to generate these is just an example of security through obscurity. It only takes 65535 packets to enumerate the query ID space. Which is trivial. Even if a client or name server uses a truly random data source for these IDs. And of course all bets are off the bad guy can diddle with the DNS query or response while it traverses the net. That said, I'd prefer a good entropy source, all things being equal. But I wouldn't believe that made my DNS servers and clients more secure. Because it doesn't. Get over it.
[2] DNSSEC generally involves off-line signing and key generation by special purpose tools, not the name server itself. The tools that generate DNSSEC keys use things like /dev/random or /dev/urandom as the entropy source. Not good, but still a whole lot less predictable than truly random data for a tiny 16 bit space. People using DNSSEC generally go for 1024 or 2048 bit RSA keys. And if they're paranoid, they get the key generation tool to use a data source based on some truly random physical property such as radioactive decay or noise from a semiconductor junction. Now these sources could be used to generate query IDs, but the cost/benefit analysis simply isn't worth it. Feel free to buy one for each of your name servers and hack the code to use that device as the entropy source.
The real solution to this long-standing DNS spoofing problem is widespread deployment of DNSSEC. Anything else is just re-arranging the deckchairs on the Titanic.
Sara Peters said: I just wish I knew of the root servers and TLDs doing something with DNSSEC. Or perhaps doing something that takes active baby steps toward DNSSEC.
.se, the Swedish TLD has been signed for a couple of years now. RIPE NCC has signed its in-addr.arpa zones and e164.arpa. Some other TLD registries set up DNSSEC testbeds and have run experiments. If your favourite TLD isn't using Secure DNS yet, complain. Ask them why not. Create a fuss. Encourage them to deploy it and announce a timetable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
