Hide full article
On 08-Jul-08, a massive security patch was released by dozens of vendors for a major vulnerability in DNS (Domain Name Service), discovered by security researcher Dan Kaminsky. DNS is one of the fundamental underpinnings of the Internet, translating domain names (like tidbits.com) into IP addresses (like 216.168.61.78). Because DNS is so core to the functioning of the Internet, this vulnerability is perhaps the most significant security problem to face the Internet in the last decade.
All users who connect to Mac OS X-based servers for DNS lookups are at risk: Apple has not yet provided a patch, unlike dozens of other companies that make or distribute operating systems or DNS server software.
Apple was clearly distracted by the largest set of launches in its history: the iPhone 3G, the iPhone 2.0 software, the .Mac-to-MobileMe transition, and the App Store. Nonetheless, their customers are now in danger and Apple needs to respond immediately.
All companies that provide DNS service to their customers should have already updated their DNS servers. Many have not. You can determine whether your ISP is at risk by visiting Kaminsky's site and clicking the Check My DNS button. If the site says your DNS is at risk of being poisoned, contact your ISP or your company's IT department immediately.
Poisoning the DNS Well -- Kaminsky accidentally discovered a new technique attackers could use to compromise DNS servers, allowing ne'er-do-wells to convince servers to accept an incorrect IP address for a given domain name from a source other than the one that properly controls information for that particular domain. (This is called cache poisoning.) The attack doesn't affect the DNS server software - it doesn't compromise the software itself - but rather the attack changes the information the server stores, or caches, to provide answers about domain names that the server has retrieved from elsewhere.
Thus, when you type www.tidbits.com into a Web browser's URL field, rather than your computer receiving back the correct IP address from its built-in DNS resolver - 216.168.61.78, in this case - an attacker would indirectly convince that resolver to believe the address was something else, like 172.31.0.16.
Your browser would obligingly use that IP address to make a connection to a Web server while displaying www.tidbits.com in the address bar. That site could be - certainly would be - loaded with malware. This is a particular problem for Windows users, whose systems could be infected simply by visiting a site. With no active exploits for Mac OS X that currently result from visiting a Web page, Mac users are more likely to fall victim to social engineering after visiting a site and being told to re-enter a password or provide details that a trusted site doesn't normally ask for.
DNS is distributed and can be recursive, meaning a server keeps working through a set of linked responses it gets from other DNS servers until it gets an authoritative answer. Your computer has a "stub" resolver, which knows to ask a full-blown DNS server for the name-to-number conversion. The full-blown DNS server is typically run by your ISP or the company you work for. That DNS server, in turn, asks root nameservers - run by a variety of organizations - where to find details about, say, .com.
The root nameservers direct your ISP or company's DNS server to the server that has the lookups for that domain. This can go on and on for every dot-separated part in a domain name, but it typically follows this path: root server, top-level (such as .com) domain server, and corporate domain server.
Weakening SSL/TLS, But Not Killing It -- This attack does not directly disable secure Web connections, although it weakens the signals you rely on for trust, and requires that you be more alert. Secure Web connections use SSL/TLS (Secure Sockets Layer/Transport Layer Security), a mechanism that encrypts a connection and also relies on trust outside that connection to validate the connection. The digital certificates used as the basis of these connections require that a domain name match a particular IP address; but if your DNS has been poisoned, a bogus certificate becomes a much more serious risk.
However, the outside trust element should save you. Certificates must be signed by third parties, known as certificate authorities, like Thawte or Comodo. These authorities are supposed to verify the identity of a party requesting a certificate before the authority signs their request. Authorities charge fees from tens to thousands of dollars depending on how much background checking and control over the certificate is asked for. Details about these authorities are pre-installed in browsers and operating systems completing the circle of trust: Your browser knows an authority's signature, which enables your system to validate the authority's approval of a Web's site
certificate.
If an attacker's fake site tries to present you with a certificate that alleges it's www.amazon.com, your browser will alert you that the certificate hasn't been signed or at least wasn't signed by a known certificate authority. That's always a reason to refuse a connection, unless you're connecting to a Web site run by a trusted party that's given you explicit information about the certificate they've chosen to use.
A Coordinated Fix, Except for Apple -- While cache poisoning has always been a problem for DNS, the technique Kaminsky discovered is faster and more effective than any previous known exploits. Kaminsky's flaw allows an attacker to overwrite existing DNS entries that a server has already cached - something never before possible. This vulnerability is a flaw with the protocol itself, and thus affects nearly every DNS implementation in use.
After determining this flaw was legitimate and widespread, Kaminsky immediately contacted major vendors - operating system makers and DNS software developers - and other DNS experts who met secretly at a meeting hosted on the Microsoft campus in March 2008. In an unprecedented move, the vendors all agreed on a simultaneous release of fixes for their products, coordinated with the help of the United States Computer Emergency Response Team (US-CERT).
To obfuscate the nature of the vulnerability, the companies all agreed to use a fix - port randomization - that didn't necessarily reveal the details of the flaw, thus slowing down the ability of bad guys to reverse engineer it and attack servers before organizations could patch. This lasted for 13 days, until the vulnerability was disclosed by a security researcher who accidentally published a draft blog post with all the details. By 24-Jul-08 exploit modules appeared in the popular Metasploit penetration testing tool, empowering any attacker capable of downloading the tool and using a web browser.
(The brief explanation of the flaw is that by forcing a DNS server to look up certain domains by sending it requests, an attacker can take advantage of a predictable sequence of port numbers to send a massive number of fake answers to the DNS server. If just one of the fake answers gets through, the attacker "wins"; it's essentially a race in which the bad guy can have a million marathon runners and the good guy thinks they're off for a solo jog in the park. This can be accomplished in a couple of minutes with Metasploit. Randomizing the sequence of ports used in requests vastly increases the complexity of a bad guy winning. The general vulnerability of predictably used ports was understood in 2001 and built into the DNS server djbdns. The real answer to this problem is DNSSEC, which combines public-key cryptography with DNS, allowing only the legitimate domain owner to provide answers to DNS queries about its domain. DNSSEC has been bogged down for years, but a logjam broke in March 2008, and we're likely to see real use due to this basic DNS flaw being revealed.)
Apple Punts, Doesn't Patch Yet -- Apple has yet to patch this vulnerability, which affects both the desktop version of Mac OS X and Mac OS X Server. While individual computers that look up DNS are vulnerable, servers are far more at risk due to the nature and scope of the attack.
Apple uses the popular Internet Systems Consortium BIND DNS server which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date.
All users of Mac OS X Server who use it for recursive DNS must immediately switch to an alternative or risk being compromised and traffic being redirected. Installing the above-mentioned BIND should be relatively trivial for anyone who can compile software at the command line. The Mac community could take this up if someone created a compiled version of BIND 9.0.5-P1 and distributed it for simpler installation.
With active exploit code available in a common attack tool, it is imperative that Apple fix this vulnerability. Due to their involvement in the process and the ability of other vendors to fix their products in a timely fashion, it's hard to imagine any possible justification for Apple's tardy behavior.
If you are unable to patch a server system with new code, you could reconfigure those servers to forward DNS requests to alternative platforms, such as BIND on Linux or Unix, or Microsoft servers, until Apple issues a patch. Ask your ISP or network provider for assistance.
Although the desktop version of Mac OS X is also technically vulnerable, current attacks are directed at servers, so there's no need to panic.
This is an extremely serious security issue and we hope Apple will act responsibly and address it immediately, despite their initial tardiness.
[Author's note from Rich Mogull: I assisted Dan Kaminsky with the initial communications regarding the vulnerability and the coordinated release. Check out the initial executive summary.]
and Glenn Fleishman 
