The DNS Vulnerability: What You Should Know and Do
On July 31, 2008, Apple released an overdue patch for a major vulnerability in the way Mac OS X Server handles turning the names in Web sites and e-mail addresses into the numeric addresses used for connections. The vulnerability is a fundamental flaw in the Domain Name Service (DNS) protocol and affected all but a handful of DNS servers built into operating systems and released as stand-alone server software packages.
If exploited on an Internet service provider (ISP) or company's DNS server, an attacker would be able to redirect any user of that server to a destination of his or her choosing. Thus, while you might select Macworld.com from your bookmarks or type it into a browser's location field, and the browser shows you www.macworld.com in that Location field, you've actually downloaded the home page of a malicious website hosted by a bad guy who has loaded it with malware and phishing attempts.
Although Apple released a fix for all Macs running OS X 10.4.11 and 10.5.4 (Server and desktop, Intel and PowerPC, Leopard and Tiger), the fix only repaired the most vulnerable part of DNS, the server software, even on systems that don't use it. (The server software is installed, but not turned on, in the regular flavor of Mac OS X, and in OS X Server, DNS service has to be configured and activated.)
Client DNS software, used by an operating system to request a DNS lookup from a full-scale DNS server, is still at risk, but at a lower level and under more limited circumstances.
Understanding the vulnerability
Earlier this year, security researcher Dan Kaminsky accidentally discovered a major vulnerability in DNS--the protocol that translates the domain names we can remember (www.macworld.com) into the Internet Protocol (IP) addresses used by the software that powers the Internet (220.127.116.11). (Note: One of the authors of this article, Rich Mogull, worked with Kaminsky on preparing the announcement.)
To be more accurate, Kaminsky didn't discover a new vulnerability, but a new, lethally effective method to attack a known weakness in DNS. Known as cache poisoning, this class of attack allows an attacker to corrupt the database a DNS server holds in memory, and consults to provide details to users' systems when they request name-to-number lookups.
This flaw lets an attacker replace the valid IP address tied to a domain name with any IP address the attacker wants. In effect, an attacker can hijack users' Web browsers (and other Internet software) by providing the browser with the wrong IP address; the browser shows what the user thinks is the address they typed in, rendering the redirection invisible. Other browser redirection uses tricks like frames and can't be as easily hidden.
If a user is sent to a malicious destination, the bad guys could use a variety of social engineering tricks to fool you into entering sensitive information (like a fake bank site that looks real), or to directly attack you using web browser vulnerabilities. Mac owners are more likely to be hit by the former than the latter, as there are currently no known public Mac OS X exploits in the wild that work simply by visiting a Web site.
Before Kaminsky's discovery, cache poisoning was a tough attack to pull off. Each DNS request has two parts: a transaction identifier (TXID) that's a random 16-bit number, which means there are just under 66,000 possible values. The TXID is paired with a port number, which is a kind of mailbox at an IP address. An outbound request of any kind is attached to a port so that the response from a remote server or other computer can be delivered back to the right cubbyhole on the requesting machine.
Cache poisoning used to involve trying to guess TXID and UDP combinations, and trying to provide forged responses that would be accepted as legitimate. This could take days or weeks and wasn't guaranteed to be successful or unnoticed. This method also wouldn't replace entries already in the cached DNS number database due to protections inserted into DNS in the 1990s after earlier attacks were figured out. It was a race that was really hard for the bad guys to win.
The new attack bypasses earlier limitations, based on two factors. First, most (but not all) DNS servers sequentially assign the ports they use in making DNS queries. That is, they start with 58363, then use 58364, and so on, incrementing by one. Second, Kaminsky determined that sending a series of bad requests of a certain type would dramatically increase an attackers' potential to win the race.
The attack generally starts with an attempt to get a DNS server to look up a maliciously controlled domain entry. If an attacker makes a DNS server look up an address from a DNS server the attack controls, that malefactor can obtain the current port number that the targeted DNS server is using. The next part of the attack involves bombarding the server with requests for non-existent subdomains--the leftmost part of a domain name--at the domain for which the attacker wants to hijack lookups.
For instance, the attacker might force the server to lookup aaaaaa.macworld.com, and then, because he knows the UDP port, send tens of thousands of fake responses in a second or so for that subdomain. If the macworld.com DNS server responds with the right TXID and port before the attacker, it wins. But the attacker has tens of thousands of runners in this race, and the one with the right TXID has to beat the macworld.com server.
If aaaaaa.macworld.com fails, the attacker can move to aaaaab.macworld.com, and so on. Eventually, the attacker wins through pure numbers--it might take from 10 seconds to a few minutes to win, and, once won, all is lost. The response that wins can also contain other information about the same domain--called additional record record fields--and the attacker uses that to replace the cached entry for the main domain or any other domain they wish.
Think about it this way. Alex is set up with a blind date named Charlene. But Alex has an enemy named Beth. Beth finds out that Alex is supposed to meet someone at Cafe Depot for coffee at 12.10 p.m., but doesn't know the blind date's name. Beth sends 50,000 women to the cafe--rather crowded, now--all with different names. "Hey, Alex, I'm Alexis, aren't I here to meet you?" "Hey, Alex, I'm Zelda, aren't I here to meet you?"
If Beth's hired hand named Charlene meets Alex before his real blind date, the next thing he knows, he's been slipped a mickey, and wakes up in a hotel room with a scar where his kidney was, his wallet missing, and a whopping room service bill.
Kaminsky is well known for researching DNS issues, and, after puzzling over this issue, called Paul Vixie, the fellow largely responsible for DNS from its start. Vixie is also the person behind Internet Security Consortium, which makes BIND, one of the most widely used DNS servers--it's the software used by Apple. Kaminsky and Vixie contacted other experts and major vendors and pulled together a secret meeting in March on the Microsoft campus.
At the meeting, those participating agreed to a coordinated date to release patches to minimize the risk the bad guys would figure it out before some products were patched. This core group then worked with other vendors, like Apple, that re-use vulnerable versions of DNS. (Some firms released patches before the coordinated date with no details about the exploit, and no one noticed that these changes were made.)
On July 8, 2008, an unprecedented massive multivendor patch was released, and promoted by US-CERT, the United State Computer Emergency Response Team, that helps disseminate critical computer security information.
The fix randomized the ports used by DNS, making it much harder for attackers to predict where to send their spoofed responses. Drawing upon our example from earlier, imagine if Beth only knew that Alex was to meet Charlene at some point in a given week. She'd have to send millions of impostors out, and the likelihood of a fake Charlene arriving at the right time to intercept Alex before the real one is vanishingly small.
It's not a permanent fix, but it's one that all vendors could implement, and it didn't necessarily reveal the exact vulnerability, giving everyone extra time to patch. Unfortunately due to a combination of factors, the full details of the vulnerability became public 13 days later, and were immediately followed by attack tools.
Despite being informed of the problem back in May, Apple failed to issue a patch on July 8 with other major operating system vendors, including Microsoft. Apple even delayed releasing a patch for weeks after exploit code became public and attacks appeared in the wild. Apple not only failed to patch, but it failed to even inform customers when they could expect a patch. Since it was possible for server administrators to manually update the version of BIND on their OS X Servers themselves, it's hard to understand why it took so long for Apple to respond.
Understanding your risk
With attack tools in wide use, it's critical that anyone using Mac OS X Server as a recursive DNS server immediately apply Apple's patch.
We tested last week's update after reading an entry at the blog of the SANS Institute, a security research consortium, that Apple's patch only fixed the DNS server in Mac OS X Tiger and Leopard, not the client. We confirmed that's the case: clients are still vulnerable, but the specific circumstances for successfully attacking average computers aren't yet public. Dan Kaminsky will be releasing those details at a talk he delivers at the Black Hat security conference on Wednesday, but it's believed the risk to clients will still be low.
The real risk to the average Mac user is using an unpatched DNS server. At home, this might be your ISP; at work, it's your employer; on your iPhone, it's AT&T; and in Internet cafes it's the ISP for the cafe. When browsing behind a vulnerable server that assigns you an IP address and DNS servers, if attacker take over that server, they can redirect you wherever they want.
You have a couple of options to protect yourself. First, you can always hard-code your Mac to use a "safe" DNS service like OpenDNS, which offers free DNS service and relies on DNS server software that was already hardened against this attack before it became known. OpenDNS's DNS servers are located at 18.104.22.168 and 22.214.171.124. Entering these IP addresses prevents exploitation, as they're used directly, not looked up.
To set OpenDNS or another safe DNS server, follow these steps:
On an iPhone, you unfortunately have to change the DNS server settings for every single Wi-Fi connection you make. This is easy for your home and office networks, but a pain for every other network. AT&T doesn't allow EDGE (2.5G) or 3G connections to have alternate DNS, and AT&T remains, as of this writing, one of the national ISPs that's failed to update their DNS server software to avoid the exploit, which has been seen on AT&T's network in Austin, Texas.
With an iPhone or on a laptop or desktop, you could use a VPN connection instead from a company you work for or via Witopia.net or publicVPN.com. VPN connections require a valid login over a secure means, and an exploited domain name for the VPN server will prevent the connection from taking place, which is a good warning. With the VPN connection active, DNS service is typically provided via a server on the other end of the VPN connection. Use the technique in the next paragraph to confirm that your VPN service's DNS server has been correctly patched.
To help you find out if you're vulnerable, Dan Kaminsky posted a DNS Checker on his web site. Click on the button in the upper right hand corner and it will tell you if your current DNS server uses port randomization.
The other risk if you're using an unpatched DNS server or one that you aren't sure is secured is with secure Web connections. Secure Web servers use digital certificates, which browsers and operating systems can validate, using information already built into the browser and OS to check for the cryptographic signature of a well-known third-party authority that confirms the certificate is legitimate.
With the DNS flaw, attackers could change www.amazon.com to point to an IP address where they've installed their own certificate that alleges to be valid for www.amazon.com. However, any browser that supports secure connections will alert you that the certificate is either invalid (contains the wrong validating signature or none), or is self-signed, meaning no third-party vouches for it. Stop. Do not pass Go. Do not connect!
A second way that a secure Web site could be compromised is if you don't have a bookmark to the URL for a banking or other site that starts "https," the shorthand for a secure Web connection. If you enter www.chase.com, you're first taken to the unsecured site in normal use, and then redirected by Chase to its secure site.
With attackers taking over your DNS server's lookup for chase.com, they can choose to not redirect you to a secure site, and thus avoid certificate warnings. It's critical to look at your browser to make sure what you think should be a secure connection has actually closed that lock (lower right, Firefox; upper right, Safari) and has https in the location field.
The worst thing was the waiting
This exploit, once patched, looks unlikely to recur, because the degree of difficulty has been raised so high. Unless another exploit is extracted from DNS, this fix may last a while.
Apple turns out to be the goat in this case by failing to have a patch ready and by failing to communicate with its corporate and individual customers about the progress of the patch.
And that's unfortunately what looks like the outcome is. Despite over a decade of work on DNSSEC, a way of tying certificate-based validation to DNS responses, there's no definitive path to move forward. Ultimately, the only way DNS can be secured is by using encryption. Those who make and distribute DNS may have much more motivation to settle on a plan and move into action.
[Glenn Fleishman writes about wireless security issues and Mac OS X for his blog Wi-Fi Networking News, TidBits, and the Seattle Times. Rich Mogull is an independent security consultant who blogs regularly on security issues at Securosis.com. He is also a contributing editor at TidBits.]