When you direct your browser to www.google.com, you take it for granted that the Web page that appears will indeed come from Google and not from some shadowy Internet scammer pretending to be Google. But your faith is misplaced. It turns out to be easy for a malicious computer hacker to trick your browser into steering you anywhere he wants and then to pilfer sensitive information, like your user name, password, and credit card number.
Dan Kaminsky, of the Seattle-based computer-security firm IOActive, stumbled onto the problem in February while examining the functioning of the Domain Name System, or DNS, the database that computers use to find their way around the Internet. At the time, it was still just a theoretical vulnerability; he had not actually observed anyone taking advantage of it. But he knew that clever criminals would eventually uncover the flaw, at which point all kinds of damage could be done. ”I realized the scope of this pretty quickly,” he recalls.
He then alerted other security experts and the makers of network equipment and worked with them behind the scenes to get software patches written. The various vendors released their new code in a coordinated move on 8 July. At that point the existence of the threat became common knowledge, at least among computer types, but the details of how the flaw could be exploited were still shrouded in mystery. To give network administrators time to install the new software, Kaminsky had planned to wait 30 days before publicly describing the vulnerability. But things soon spiraled out of his control.
By looking at the patch, others guessed what Kaminsky had found, and soon some had posted their ideas on the Internet. The cat slipped fully out of the bag when a blogger at the computer-security firm Matasano Security confirmed some of these speculations. The blog post was taken down quickly, but not quickly enough to prevent it from being copied and widely disseminated.
Within days, code to exploit the newfound weakness in the DNS had been posted on the Web site of the ”computer academic underground” (http://www.caughq.org)--precisely the kind of thing Kaminsky had hoped to forestall.
Whereas some network administrators may initially have been reluctant to patch their systems, fearing that the upgrade itself might cause problems, most of them now seem to have made the change. No definitive tally is available, but Kaminsky has created a tool on his personal Web site (http://www.doxpara.com) that allows visitors to check whether the server they are using has been patched. He reports that as of 9 July, about 85 percent of the name servers being tested were vulnerable. But by 6 August, the proportion had dropped to 30 percent.
But even those who have taken the appropriate steps are not exactly breathing easy. The patch is not a perfect countermeasure, as Kaminsky has emphasized on his blog: ”This is just a stopgap--we're still in trouble with DNS, just less.”
If you follow computing at all, you know that security experts routinely uncover software glitches and vulnerabilities and then issue software patches and upgrades. What Kaminsky has found, however, is much bigger and much scarier.
To understand why, you need to know the basics of how the DNS works. The Domain Name System is essentially the Internet's phone book. It's a huge database containing the 32â¿¿bit numeric codes that identify every single site on the Internet. These are known as Internet Protocol addresses, or IP addresses for short. Amazingly, this database is distributed over some 12 million computers worldwide, known as DNS name servers.
When you type ”www.google.com” into your browser, it must translate that human-readable text into an IP address before it can access the site. To do so, your computer sends a request to a name server upstream, probably one maintained by your Internet service provider.
Then, if your ISP's name server has the IP address for the requested site stored--or ”cached”--it returns this information to your computer pronto. If not, it goes through what may be an elaborate process querying other name servers to find the address.
Kaminsky has discovered a way for a hacker to insert a false IP address into the cache of a name server. The hacker could, for example, change the name server's entry for ”www.paypal.com,” thus blocking access to PayPal, or worse, duping people into going to a site that mimics PayPal's. From there, it would be relatively simple to harvest user names, passwords, and other valuable data.
Such an attack would work much like the many ”phishing” scams now plaguing the Internet, but in this case the victims wouldn't need to click on a link in a shady e-mail message. They could type the correct name, ”www.paypal.com,” directly into a browser and still get sent to the wrong place. (The real PayPal would upgrade the security of the connection from http to https, but the victim may easily fail to notice when this doesn't happen on the scammer's simulated site.)
The attacker could also use this tactic to redirect e-mail. By replacing the IP address of, say, a corporate mail server with the IP address of a mail server that he controlled, he could inspect incoming correspondence before passing it on to the targeted company's mail server. Even more troubling, he could add his own malicious code to e-mail attachments, which from the recipient's point of view might appear to come from known and trusted sources.
Security experts had long been aware of two general ways that a hacker could carry out such a ”cache poisoning” attack on a name server. But both had been rendered ineffective years ago with changes to DNS software. Kaminsky, however, has found a way for a hacker to circumvent these fixes--and to combine the two exploits in a way that makes an attack especially potent.