Opinion: Apple's unforgivable DNS delay
Why is the company the last to address the cache-poisoning vulnerability?
Macworld - For the entire history of Mac OS X, Apple has had a grand time poking fun at Microsoft about a lot of things, but the company has made a point of getting its licks in over its rival's track record with security. The malware problem, the effortlessness with which Windows XP was attacked via Internet Explorer and other vectors -- oh, what a fun time Apple had.
However, through the Windows XP and Windows Server 2003 life cycle, a funny thing happened. Microsoft really listened to the criticism, took it to heart, and started not just saying it took security seriously, but showing that it did. We can argue about how annoying some of the implementations have been, but the fact is, Microsoft learned. While the idea of a "Patch Tuesday" may seem odd to a home user, for a network administrator, having advance notice of upcoming patches is a good thing.
But what about Apple? Well, on a very basic level, Apple got lucky. The flavors of BSD Unix have always had a good level of security, Unix itself is designed reasonably well from a security point of view, and, up until Mac OS X 10.4, Mac OS X was not able to really handle high-end server roles. So, Apple's default stance of "We'll tell you what you need to know, when you need to know it, and you'll like it" wasn't a big deal. But it wasn't good. When you report a security issue, you want -- no, you need -- open communication. Getting told, "We're looking into it" or "It's already been reported," or worse, "Apple takes security seriously, but we don't comment about unreleased products" is... well, frustrating is the best word that I can use in a family publication.
A lot of people in my line of work had been predicting that, at some point, Apple's attitude toward security and the company's opaque nature were going to eventually bite it in the keister -- and hard. It was just a matter of when. But when it happened, it would put a severe hurt on the goodwill Mac OS X had created over the years.
Welcome to "when."
As reported by Rich Mogul and Glenn Fleishman in TidBits (and hundreds of other sources around the Internet), security researcher Dan Kaminsky accidentally discovered a technique whereby an attacker could compromise DNS servers, (part of the essential functionality of the Internet), via what is known as cache poisoning. This technique allows an attacker to change, or "poison," the caches where DNS servers store the data that allow you to use, for example, www.apple.com to get to 220.127.116.11.
So, let's say you want to get an update to an application. You enter in a URL, say www.goodvendor.com, and connect to that site to download the update. The problem is, the DNS server you use -- say, your ISP's or your own -- has had its cache "poisoned," so while you explicitly typed in the proper URL, you end up at some other server; instead of downloading the correct, safe update, you download a Trojan horse and install it, because you think it's safe. While attacks on DNS servers have been around for a while, this vulnerability made such attacks far easier to pull off than they previously had been.
This kind of attack makes most of the ways you detect phishing sites useless, because the URL will be the correct one, not some "almost" correct one. You'll just get rerouted to the wrong place. This is not theoretical either -- there are active exploits for this right now.
Because everyone who uses the Internet relies on DNS in a way that is the very definition of the term mission critical, and given the relative ease with which this vulnerability can be exploited, Kaminsky and other people -- like Paul Vixie, who helped create BIND, the software that pretty much every Unix-based OS uses for DNS -- took immediate action. Kaminsky, Vixie, and others, including the U.S. Computer Emergency Response Team (CERT), privately notified all affected vendors, including Apple, by May 8; Apple was specifically notified on May 5. They then waited two months until July 8 to publicly notify the rest of the Internet community.
- Deep Security +VMware vSphere with Operations Management Most midsize organizations are highly virtualized on VMware, and while this has produced significant savings, it also has created new challenges when it...
- 3 Questions to Ask Your DNS Host about Lowering DDoS Risks Neustar has had wide-ranging conversations with clients wanting to know how they can optimize protection as DDoS attacks increase in frequency and size.
- The Danger Deepens: 2014 Neustar Annual DDoS Attacks and Impact Report This report compares DDoS findings from 2013 to 2012, based on a survey of 440 North American companies, including 139 businesses delivering technology...
- DDoS Infographic: How Are Attacks Evolving? For the third consecutive year, Neustar surveyed businesses across major industries to track the evolution of DDoS attacks. Are they more frequent? Larger?...
- How to Use Crowd-Sourced Threat Intelligence to Stop Malware in its Tracks Threat sharing networks have been around for a long time, however they have typically been "invitation-only", available to only large companies, or those...
- An Incident Response Playbook: From Monitoring to Operations As cyber-attacks grow more sophisticated, many organizations are investing more into incident detection and response capabilities. In this webcast, learn how to develop... All Malware and Vulnerabilities White Papers | Webcasts