Blayne Sucks

On Friday, December 11th, my MacBook Pro stopped working properly. I couldn’t get video regardless of what I did. I took it to the Apple store the next day, where I learned that my graphics logic board was the victim of the infamous NVIDIA recall. I was told that it would take up to 10 days to get it repaired. Just as I was starting to recover from the shock of being without my computer for 10 full days, the Apple employee who examined my laptop said they would need my username and password to complete the repairs.

There is no valid reason Apple needs a username and password to repair a graphics logic board. This is a basic principle of computer security: Do not give anyone your username and password. I asked why they wanted it, and I was told that they needed to be able to log into the machine to verify that it works. This is simply false, and I’m disappointed that Apple would claim it was true. Graphics can be tested in a variety of ways without using an existing username and password. First, they could have used the guest account on the machine. Second, they could have booted into an operating system on a CD/DVD such as Knoppix. Third, they could use a bootable USB drive. Fourth, they could boot from an external hard drive. These options are even documented on their website. Needless to say, I refused to give them my username and password. They refused to send the computer off to be fixed. I asked if there was anywhere else I could get it fixed. To their credit, the Apple store employees were prepared to give me a recommendation to Ten Plus Systems.

I knew almost immediately after walking into their store that Ten Plus Systems was a quality computer repair shop. First, I saw one of the technicians talking with the receptionist about a repair. They were clearly organized, and my gut told me immediately that the technician was a genuine computer geek. Second, they were selling an original, fully restored 1984 Macintosh. It was absolutely beautiful. It looked almost new, and a great deal of care clearly went into restoring this machine. I strongly believe that people who are experts in their field have an intuitive sense that allows them to identify other experts rapidly. (Read Blink by Malcolm Gladwell if you are interested in exploring this concept.) As a computer science PhD student who has built at least a dozen computers from parts, I consider myself an expert in this field. I could tell this store was run by experts.

I arrived Monday morning and my computer was fixed 26 hours later. It was basically a one day turn around on a repair that Apple said would probably take 10 days. They didn’t need my username or password. They didn’t even ask. Ten Plus Systems is an Apple-certified repair store, which means that any machine covered by AppleCare can be repaired there. They also repair Apple and PC machines not covered by AppleCare, and they recycle old computer parts for their customers. If you are near Raleigh and need computer repair work done, I would strongly recommend Ten Plus Systems based on my experiences with them.

Disclosure #1: According to the relatively new FTC rules for bloggers, I should disclose my connection with the companies I’m endorsing. I haven’t been paid for this post. I haven’t been given any gift of any kind for this post. I haven’t had an out-of-body experience in which I was in any way compensated for this post. (At least, not yet…) I’m just a genuinely satisfied customer.

Disclosure #2: I agree with Adam Thierer: the relatively new FTC rules for bloggers are almost completely unenforceable.

Last week Bruce Schneier commented on a story about a prison that let an inmate convicted of credit card fraud reprogram a prison computer. Schneier believes this sort of thing should be an “obvious” no-no, and I agree. However, it isn’t obvious to a lot of intelligent and well-intentioned people. In fact there’s consistently been debate on whether or not criminals should be hired for computer security positions. There are people who fervently believe the myth that being an excellent criminal carries over into being an excellent law enforcement officer or security adviser.

Unfortunately, pop culture continues to prop this myth up with TV shows like the USA Network’s upcoming White Collar. The show is about an FBI agent who teams up with his nemesis-turned-good-guy to solve crimes that no one else could solve. Another TV series, called Dexter, which appears on Showtime, portrays a forensics expert who secretly murders the criminals he finds through his work. Both of these shows operate on the premise that experience committing crimes is useful in preventing them.

In reality, committing crimes and preventing crime are fundamentally different activities not because of the skill sets but because of the motivation and interests involved. In fact, the skill sets may be strikingly similar in a lot of ways. Some pirates are excellent sailors, some outlaws can shoot extremely well, and some hackers know a lot about computers. Don’t focus on asking whether the skill sets overlap. Instead, focus on questions like these: Are they dependable? Can they work well with other people in your particular work environment? How do you know they are actually interested in helping your organization? How do you know they are truly reformed?

After focusing on these questions, the truth comes to light: it is very rare that an excellent criminal history translates to an excellent crime-prevention future. There is a reason that police departments do a criminal background check before hiring someone. There is a reason that day care providers don’t hire convicted child molesters. There is a reason that banks don’t hire convicted felons to do security. Why wouldn’t the same rationale carry over to information or computer-based crimes?

Now, there are instances of convicts making amends and turning their lives around. Frank Abagnale is perhaps the most famous of these reformed con men. Hollywood capitalized on his story with the highly successful movie Catch Me If You Can. I know several people who have heard him speak at security conferences, and they have told me that he continues to apologize for his life of crime at the beginning of his talks, decades after they occurred. In fact, he may be a good model of how to lead a life of contrite contribution to law enforcement after being an extremely skilled criminal. He worked long and hard to earn the trust of banks and the FBI. He was initially paid only for positive results, and used the money he earned as a security consultant to pay back his debts.

Still, as a general rule, it should be obvious that hiring anyone convicted of computer fraud to do computer security work is a bad idea. Why take the risk? There are a lot of extraordinarily talented computer security experts who do not have the baggage of a criminal record. If you find, after searching for a non-felon, that you need the particular skills or expertise of a convicted computer fraudster, then don’t put them in a position of power. Don’t trust them without oversight. Don’t get caught up in the Hollywood story. The Frank Abagnales of the world are exceedingly rare; hiring a felon to do computer security almost never ends well.

Recent cryptography news serves as a microcosm of the development of computer security technologies. The discovery of fully homomorphic encryption by Craig Gentry, a Stanford PhD student working at IBM this summer, is by far the biggest headline in cryptography theory this week, month, year, and (probably) decade. Essentially, fully homomorphic encryption can perform arbitrary computations on encrypted data while preserving the encryption. For example, a spam filter could be used to identify encrypted emails containing spam, or an audit logging system could append an entry into an encrypted log file without decrypting it and then re-encrypting it.

Now, nothing is perfect right out of the gate, and there are caveats to this discovery. For the scheme to work, one must know in advance the maximum number of computations that can be performed on an encrypted file. It’s not practical; the discovery shows only that it is possible. Last but not least, we’ve already developed schemes that allow some limited operations, such as search, on encrypted data. These have been around for years, and some have even been reported on technical news sites. But even taking these concerns into account, the discovery is legitimately headline news.

The media loves to report juicy computer security stories, particularly relating to the discovery of new cryptographic techniques. Unfortunately, these headlines distract from the primary concern of the average computer security professional: We are just not using the tools we have! Consider last summer when a flaw in the DNS protocol became huge news. It was a problem that could have been completely avoided using existing cryptography. We just weren’t using it. In fact, despite Dan Kaminsky’s recent efforts, we still aren’t using it. Here’s a great quote from Dan:

DNS is the world’s largest PKI without the ‘K.’All DNSSEC does is add keys.

Why haven’t we “added the ‘K’” yet? DNSSEC has been sitting in a drawer, and even after last summer, it doesn’t appear to be a priority. It is designed with security in mind from the start; it is real, practical, and can be implemented without another breakthrough in cryptography. Only, we aren’t using it. And this has been the pattern of cryptography technologies for the last few decades:

1. Some smart people create something like public key encryption and/or fight against ludicrous export controls on cryptography tools.
2. The story becomes headline news for a day or two, and we all walk around feeling great about how we ’solved’ the security problem and we’re all going to be ’safe’ soon.
3. A few weeks pass and we find that no one is actually using the inventions that were just created and/or saved from oppressive regulation.
4. Eventually, we start all over from Step 1 with a new miracle discovery in computer security. That’s what happened this week.

Consider email encryption. Gmail (and most other webmail providers) still doesn’t support GPG. Gmail also doesn’t use persistent SSL connections by default, which means that your emails are delivered to your web browser in plain text when there’s a cheap and effective form of encryption that could easily be enabled. This was old news when I blogged about it here nearly two years ago, but Google is “looking into whether it would make sense” only recently, perhaps because of a letter organized earlier this month by Chris Soghoian and signed by numerous computer security experts.

I’m not saying that fully homomorphic encryption isn’t important, or that solving this longstanding, open academic question isn’t an achievement. It is important, exciting, and a huge achievement. All I’m saying is that fully homomorphic encryption, or any security technology, won’t solve computer security and privacy problems unless we start using the tools we have.

Edited to add: Here’s a nice piece by Brian Krebs that talks more about the letter sent to Google about ecrypting by default. In particular, I love this quote:

“What we’re saying in this letter is that as an iconic service, and one that professes to be concerned about user safety, Google could set a good example and set the right defaults, and if users want to switch back to something less secure, then they can.”

Dr. Eugene Spafford

(Full Disclosure: I am working with Dr. Spafford this summer at CERIAS on campus at Purdue University.)

Currently, Twitter is the Internet’s dominant micro-blogging service. It has shown that micro-blogging is a distinctly different form of communication deserving of it’s own niche, and it has done so well with its own micro-blogging service that micro-blogging itself is perhaps better known as Twittering.

Of course, there is one small problem. Twitter is a closed platform. As Tim Bray put it:

The basic problem is that Twitter is centralized; that’s not how the Internet works.

A quick look at history tells us that open communication protocols win in the long run. When you call someone on the phone, you aren’t limited to people using the same telephone service provider. When you email someone, you aren’t limited to people who are using the same Internet service provider. Even actual blogging has standardized norms (RSS and Atom) that allow people using blogger, WordPress, LiveJournal, or any other blogging mechanism to easily follow blogs on other platforms. (Though, cross-blog commenting is still a bit of a problem.)

Although I could talk about the Network Effect or Metcalfe’s Law, for the purposes of this post, I will focus on the key security design problem facing Twitter. This is not to say that the Network Effect and Metcalfe’s Law aren’t important. They are. I’m just talking about another, unrelated reason that supports the need for diversity in the micro-blogging industry.

A recent incident is an exemplar of the real problems caused by a centralized protocol like Twitter. An attacker was able to hijack several high-profile Twitter feeds, including Barack Obama’s campaign feed and the official Fox News feed. How did this happen? Well, it turns out that there was a security design flaw on the Twitter site that allowed rapid login attempts. This allowed an attacker to use a dictionary attack against the Twitter account of a member of Twitter’s support staff. Once the password was guessed, the attacker was able to get access to any feed in all of Twitter-dom.

The key security flaw in any centralized protocol is that such protocols are monocultures. Bananas are a great example of the danger of monocultures. Bananas are an extremely important crop worldwide, but the vast majority of bananas grown are of the Cavendish variety. Why? Because the tastier Gros Michel bananas were wiped out by a disease. They were all essentially genetically identical. There was almost no diversity in the banana ecosystem. As a result, they were unable to adapt to the disease, and since the same problem exists with the Cavendish, we’re still one bad disease away from a worldwide shortage of bananas.

The same problem exists for micro-blogging. If you want to micro-blog, you effectively need a Twitter account. Twitter is so dominant that almost all micro-bloggers are using Twitter, which makes it a monoculture. Because Twitter is a monoculture for micro-blogging, the micro-blogging itself is one bad security incident away from obliteration. Also, if Twitter were to go belly up (which is not, as Tim Bray discussed, outside the realm of possibility for an Internet-based company), then, effectively, the entire micro-blogging industry would be eliminated.

At this point you might say, “Wait! Twitter has an open API!” This is not the same as open source, and it does not eliminate the threats posed by monocultures. It does mean that it is very easy to add functionality to the Twitter protocol, but it does not mean that you can participate freely without a Twitter account.

Micro-blogging needs a viable open source alternative to create a federated micro-blogging protocol. Tim Bray proffered Laconica and one of the commenters in his thread mentioned the soon-to-be open source Jaiku, which was recently shutdown by Google.

Whatever happens, a federated micro-blogging protocol would be far more robust than the current Twitter monoculture. If I were to add a single gutsy prediction to the list over at Freedom to Tinker, it would be that a major security incident at Twitter allows an open source alternative to gain a foothold in micro-blogging. It may not happen this year, but I think it’s inevitable with any monoculture.

As a technologist with a strong interest in computer security, privacy, and public policy, I am naturally drawn to the topic of electronic voting. I have written about electronic voting several times before, including this piece on Ed Felten’s work. Recently, I have seen lists of things things could have gone wrong and some lists of things that actually did go wrong. I have even seen a hilarious account of the worst case scenario, but the most interesting accounts that I’ve seen have been personal accounts of computer science professors who volunteered to operate the polls as election workers.

Avi Rubin, a Professor of Computer Science at Johns Hopkins and director of the ACCURATE Voting center, wrote a post describing his experience working the polls and posted it only minutes before most news outlets announced that Barack Obama will be the 44th President of the United States. Professor Rubin is the author of the book Brave New Ballot, an excellent book on the dangers of electronic voting machines that I have reviewed here. His experience at the polls in Maryland describes the very practical and non-technical aspects of just what a poll worker does during the day.

Steven Bellovin, a Professor of Computer Science at Columbia, also wrote about his experience as an election official. Professor Bellovin is another well-respected authority on computer security whose post focuses on the non-technical details of the responsibilities of poll workers in New Jersey. Andrew Appel, a Professor of Computer Science at Princeton, also wrote about the use of voting machines in New Jersey.

Both New Jersey and Maryland used Direct-record electronic voting machines, which have a myriad of security concerns that have been detailed extensively elsewhere. Essentially, DREs store the official record of an election in an electronic form rather than a paper form. If you are interested in some of the problems with DREs and proposed solutions to those problems, then you should check out the USACM’s page on electronic voting.

You may be asking yourself: Why would a computer science professor volunteer to work a poll as an election official? It’s not like there’s anything technical going on there. Well, any computer security expert will tell you that the first line of defense must be physical access. This means that you can have all technology you want, all the cryptography you want, and spend all the money you have and still not be secure without common sense. There was a great video on No-Tech Hacking at DefCon in 2007 which covers what I’m talking about.

Physical access is one of the key problems with DREs: thousands of people must have physical access to the machines themselves to cast their vote. The environment is filled with opportunities for absolutely simple no-tech hacking. Even if these systems weren’t notoriously bad in terms of the technology used, the physical access alone makes these devices difficult to secure.

The challenges of physical access and the stakes of a Presidential election are both great reasons that computer science professors are interested. It’s a unique opportunity to see how these machines are actually used, and some of their observations are excellent. Their posts are worth reading if you’re interested in electronic voting or computer security: Avi Rubin’s post; Steven Bellovin’s post.

ABC News has an article on the eavesdropping of Americans that answers any remaining questions regarding the FISA Amendments passed this past summer. Essentially, the article details the use of surveillance systems to spy on ordinary Americans. Here’s a quote from the article:

“These were just really everyday, average, ordinary Americans who happened to be in the Middle East, in our area of intercept and happened to be making these phone calls on satellite phones,” said Adrienne Kinne, a 31-year old US Army Reserves Arab linguist assigned to a special military program at the NSA’s Back Hall at Fort Gordon from November 2001 to 2003.

Kinne described the contents of the calls as “personal, private things with Americans who are not in any way, shape or form associated with anything to do with terrorism.”

The article goes on to describe the nature of some of the phone call as pillow talk or phone sex. Some of the individuals involved were from the US Military, the International Red Cross, and Doctors Without Borders. Naturally, the Senate is investigating. The article further states that some especially juicy clips were saved by employees of the NSA.

Unfortunately, abuse of surveillance systems by insiders is nothing new. Bruce Schneier has shown us that surveillance cameras are abused and ineffective. Six well-known security and privacy researchers have warned about this sort of abuse with telephone surveillance as well (pdf).

The only thing that is remotely surprising about this is that we have specific details from whistleblowers, who are risking their careers and livelihood to tell us about this abuse. In this case, it is even more surprising that not one, but two independent whistleblowers came forward simply because the agency involved was the notoriously secretive NSA.

The GCHQ, which is the British equivalent of the NSA, recently dealt with its own whistleblower: Katherine Gun. In this case, Gun was a translator asked to favorably translate documents as evidence to garner support for the Iraq war. Her case was dropped at trial almost immediately. Speculatively, the decision to drop the case was due to the calculated decision that producing the evidence required to prosecute her would have been more embarrassing for the GCHQ than simply letting her go.

Many whistleblowers find the ethics of betraying their employer for the greater good an excruciating ethical dilemma. Check out this BBC News interview of Katherine Gun if you are interested in how she weighed the decision. (There’s a book about her if you are more ambitious.) For these reasons and many more, whistleblowers like Mark Klein in the AT&T case that prompted the FISA Amendments and now David Murfee Faulk and Adrienne Kinne in this more recent case with the NSA shouldn’t be our last line of defense.

Essentially, lesson from this ABC News article is simple: surveillance tools will be abused. It is human nature for power to corrupt. The Founding Fathers of the United States recognized this and tried to limit the power of the government explictly for this reason. They built checks and balances into our government because they knew that hoping for whistleblowers to highlight problems was not reliable. Why does the current US government not seem to comprehend this?  How many more whistleblowers and ABC News stories will it take for our government to catch on?

I recently was without my computer for some time and stumbled upon al3x’s Rules for Computing Happiness shortly after getting back online.  My time away from my computer gave me the opportunity to think about my own computer usage.  I thought I would go ahead and post my own short lists of rules.  For the sake of brevity, I will limit myself to five tips per category.

Obviously, the goal of using a computer is to improve your “happiness” through making work easier or making play more fun.  Although measuring happiness is hard, there is a clear divide between how computer power users (geeks) and the average person (non-geeks) uses a computer.

The first group has different objectives when they use their computer.  People in this group are more interested in hardware and software that gives them choice and control.  They are willing to put in the time to weigh their options and make the decision they feel is appropriate.

Geek Software:

1. When looking for a piece of software, always consider using an open source alternative.
2. Use software that stores data in open file formats.
3. Learn how to use a Unix-based operating system.  Good options include Mac OS X, Linux, or OpenSolaris.
4. If you travel, be sure to encrypt your data.  I almost put this into the Non-Geek category, but I think full disk encryption may still be a little bit out of the range of things that Non-Geeks are willing to learn how to use.  Either way, this is incredibly important if you travel and have any personal information on your laptop.
5. Don’t be afraid to use proprietary software when it is simply the best tool for the job.  I think potential examples of this are Photoshop and TextMate.  Both of these programs have good open source alternatives (Gimp and vim or Emacs respectively), but the bottom line is that you should use whatever makes you most productive.  Just don’t forget point #2 in this list.

Geek Hardware:

1. Buy hardware with open source software support. This hardware will almost invariably have good closed source support as well, but open source support will give you more options and more control if you want it.
2. Do not skimp on your monitor, keyboard, or mouse.  If you are going to be using your computer heavily, the quality of the interfaces you use is very important to your health.
3. If you use more than one computer, get a KVM.  It will save you a ton of space on your desk.
4. If you use a router, get a dd-wrt compatible router.  The feature set will blow you away.
5. Conduct extensive research on every piece of hardware you are considering buying.  Good places to start are the Ars Technica Buyer’s Guide or Tom’s Hardware.

The second group consists of a wide variety of people in all kinds of professions that want nothing more than to use it to complete some task or to have fun.  They explicitly do not care about learning how computers work.  My mother falls into this category.  Here are the rules that I would give anyone in this group to help them achieve computer happiness:

Non-Geek Software:

1. Think twice before installing any piece of software.  Could an already-installed application do what you need?
2. Find and use software that will help you back up your data.  Apple’s Time Machine is a good way to do this.  (See Non-Geek Hardware #4.)
3. Keep a written record of all the software you install/remove and the time you install/remove it.
4. Use a password manager that allows you to select stronger passwords.
5. Do not use web applications unless the things you use them for aren’t sensitive.

Non-Geek Hardware:

1. Do not buy top of the line hardware.
2. Do not buy ultra cheap hardware.
3. Hardware features are less important than the software support.
4. Buy an external hard drive and use it to back up your important data.
5. Avoid expensive hardware service plans.

Ordinary Men by Christopher R. Browning is a book on Nazi Germany’s Reserve Police Battalion 101, which participated in the Holocaust. The primary discussion in the book is on how a group of ordinary, middle-aged Germans became mass murderers. He attempts to understand how this transformation took place, and he uses insights from the Milgram experiments and the Stanford Prison experiments. However, he is quick to point out in the forward of the book that “explaining is not excusing; understanding is not forgiving.”

The book was recommended to me by Lucas Layman after a discussion on the importance of the human element in computer security led to a discussion on the Milgram experiments and the Stanford Prison experiments. Certainly there are many elements of computer security and computer crime that can be better understood through studying human psychology. For example, the simple fact that as the men of Reserve Police Battalion 101 were removed from direct participation (e.g. pulling the trigger themselves) to indirect participation (e.g. leading Jews to death trains) they were more easily able to cope with their actions psychologically. Similarly, computer crime is easily disassociated because of the impersonal nature of dealing with computers rather than humans. However, after reading the book my strongest reaction has been broader than just computer security.

When I was in high school I had to read quite a few books on the Holocaust. It seemed that every year we read a different book on the subject, and I tired quickly of the extremes that were pushed. Nazi Germany in general and Hitler in particular have become famous for being the most extreme extreme. This is perhaps best identified by Godwin’s Law.

Ordinary Men suffers from over-extremism to some extent as well. For example, Browning causally refers to the Holocaust as the “most extreme genocide in human history” without offering much in the way of proof or comparison. The number of Native Americans systematically killed by Europeans and the number of Russians killed by Stalin’s regime could each easily exceed the numbers of Jews killed by the Holocaust. The rate of killing in Rwanda could easily surpass the rate of killing in the Holocaust. The brutality of groups like the Khmer Rouge and leaders like Genghis Kahn could be argued to be greater than that found in the Holocaust. Is it even possible to classify something like the “most extreme genocide in history?”

My point is that our only reaction to events like these cannot be the emotional one; we must attempt to understand why and how these things happen so that we can learn from them. We aren’t good at rationalizing emotions, and we are rarely able to draw objective conclusions based on them. However, if we can take a look at some facts, then we may be able to learn important lessons. For example, before the brutality caused by Nazi Germany and in former Yugoslavia, we see extreme hyperinflation. Do we know anywhere else in the world where that is happening right now? I think so. This is something to be concerned about.

More generally security is a field that suffers from extremely emotional reactions. The air travel response to the September 11th attacks is a good example. How many of these responses have been the result of reason rather than emotion? How many of them have actually improved airport security? These are questions that we will probably continue to struggle with for years because of the highly charged emotional response most Americans have to the September 11th attacks.

On the whole though, Browning does a good job of ensuring that we don’t view the people of Reserve Police Battalion 101 as caricatures of themselves. As a result, there are many lessons to be learned from this book. The Holocaust should not be thought of as an abstract evil thing, but instead as a real consequence of human plans and actions. As Browning says, “Ultimately, the Holocaust took place because at the most basic level individual human beings killed other human beings in large numbers over an extended period of time.” The book offers an objective take on how ordinary people are capable of such a thing. I found it to be a very worthwhile read.

I know many readers of this blog also follow ThePrivacyPlace.org, but I wanted to ensure that those who simply follow this one where aware that there is a research survey currently being conducted at ThePrivacyPlace.org. I encourage everyone to participate as this is an excellent way to contribute to academic research and our understanding of online privacy concerns.

Cross posted from ThePrivacyPlace.org:

ThePrivacyPlace.Org Privacy Survey is Underway!

Researchers at ThePrivacyPlace.Org are conducting an online survey about privacy policies and user values. The survey is supported by an NSF ITR grant (National Science Foundation Information Technology Research) and was first offered in 2002. We are offering the survey again in 2008 to reveal how user values have changed over the intervening years. The survey results will help organizations ensure their website privacy practices are aligned with current consumer values.

The URL is: http://theprivacyplace.org/currentsurvey

We need to attract several thousand respondents, and would be most appreciative if you would consider helping us get the word out about the survey, which takes about 5 to 10 minutes to complete. The results will be made available via our project website (http://www.theprivacyplace.org/).

Prizes include $100 Amazon.com gift certificates sponsored by Intel Co. and IBM gifts.

On behalf of the research staff at ThePrivacyPlace.Org, thank you!

I was going to wait until Dan Kaminsky announced more details about this flaw at the Black Hat Briefings on August 6th, but Halver Flake’s recent post as essentially squeezed the toothpaste out of the tube on this one. Just look at what Dan has to say.

I’m not going to talk about Dan’s decision not to release the details of this attack as soon as possible or the merits of full disclosure in computer security. Although interesting, it is less interesting to me than the flaw itself.

I know not everyone who reads this blog is technically oriented. To those people, I encourage you to try and make your way through this (long) post. I will try to keep things as simple as possible and I can guarantee you that a better understand of this particular problem will not only give you a better understanding of computer security, but also a better understanding of how the Internet really works.

Let me take a few moments to provide some background. The Domain Name System (DNS) is the protocol that translates a website’s domain name (e.g. somebank.com) into the corresponding IP Address (e.g. 192.168.1.1). IP Addresses are used by routers and network infrastructure to deliver information from one place to another on the Internet. DNS has been around since the mid 1980’s. It is a critical part of the infrastructure of the Internet. When you type in a domain name or use a bookmark to visit your bank’s website, you are trusting that the DNS protocol will take you to the correct server and not to a well-designed phishing website that looks just like your real bank.

The recent flaw in DNS is a protocol-level design flaw, not a software bug. A protocol is merely a pre-defined set of steps done to achieve some objective. For example, when Alice introduces two of her friends, Bob and Chris, to one another for the first time, she would follow a social protocol of introduction. She may introduce Bob to Chris as her co-worker from the Human Resources department, and she may follow this by immediately introducing Chris to Bob as her friend from church. If Alice forgot to introduce Bob to Chris and Bob eventually had to introduce himself to Chris while Alice was standing there, then that failure on Alice’s part is analogous to a failure in a single piece of software. If there were a flaw in this protocol, then every introduction performed based on this social protocol would fail. That is the difference between a protocol-level flaw and a software bug.

Now we have gotten to the crux of the issue. There is a protocol-level flaw in DNS that allows a phisher to take over the actual domain name of the site that it is trying to imitate. This is a serious problem that led to an astonishing collaboration to patch the entire Internet. Even patching the entire Internet isn’t going to “solve” this problem. Why? Because the patches are just that: patches. The problem still exists in the protocol.

What exactly is this problem? (And here’s where I may lose anyone who’s not technically oriented, but I’ll try and keep this simple.) When a DNS server doesn’t know how to translate a domain name into an IP address, it asks another, more trusted, DNS server for the information. Of course, this happens quite frequently since any given DNS server can’t store all the correct DNS translations for the entire Internet all the time (and since these translations can change).

Each time a DNS server has to ask a more trusted DNS server for a domain name to IP address translation, it does so by providing a number called a Query ID (QID). Now, there used to be a ton of attacks based on these QID since they were sequential. This class of attacks basically consisted of an evil doer asking a DNS server to perform a translation on a domain name that it didn’t already have. The evil doer would then start sending forged responses with sequentially increasing QIDs. If the evil doer got the right one, a bad domain name to IP address would be cached. Once a translation is cached, most DNS software implementations will ignore other updates to that domain’s information.

There are many ways to poison a DNS cache. This particular problem was patched (not solved) by just not using sequential QIDs. If a random QID is used, then it becomes very difficult for the evil doer to respond before the real response arrives.

Another interesting way to poison a DNS cache is to send a fake resource record. This attack works because of a chicken-ad-the-egg problem that I deftly avoided in my earlier description of DNS. I said that when a DNS server doesn’t know the proper translation for a domain name, it asks a more trusted DNS server. How? How does it know a more trusted DNS server? Basically, it only knows trusted DNS servers by their domain name. So it has to resolve a domain name for the next step in the hierarchy. Let me give a simple example.

Let’s say you’re a DNS server trying to resolve checking.somebank.com and you don’t know how. Who are you going to ask? Well, you’re going to ask whatever domain name server is controlling somebank.com since somebank.com is the next step in the hierarchy. If you don’t know that one, you’re going to ask the .com root server. Of course, you would like to learn how to ask somebank.com how to resolve all of it’s subdomains (e.g. checking.somebank.com, savings.somebank.com, etc…) since that would be efficient. This is done through a DNS Resource Record (RR).

Although there are many kinds of DNS Resource Records, for this attack all you need to know is that when you make a query for a DNS translation, you can receive back an answer as well as an additional resource record that is intended to help speed up future queries. Now, it used to be possible to poison DNS caches directly with this because there was a flaw in the protocol that allowed these resource records to be totally unrelated to the original request.

For example, let’s say you’re a DNS server and you just sent out a query about checking.somebank.com. It used to be possible that you would receive a domain name to IP address translation for checking.somebank.com and an addition resource record telling you that you should cache ns.evildoer.com as a name server for future queries. This was patched (not “solved”) by requiring the additional resource records be related to the query. (Thus, you would only be able to get a DNS RR for a somebank.com name server.)

The most recent DNS protocol-level flaw is related to both the QID problem and the DNS RR problem. Here’s how I believe it works (and these details are already available to anyone with access to google and a few minutes):

1. Get a DNS server to look up a subdomain for the site that you want to compromise. For example, randomAAAAAA.somebank.com. The subdomain itself doesn’t really matter other than it shouldn’t exist.
2. Since the DNS server doesn’t have this domain name to IP address translation it will have to look up the answer. Now, the evil doer can’t reliably predict the QID since random QIDs are used. The vast majority of these lookups will correctly be answered by ns.somebank.com as non-existent subdomains with the right QID. However, the evil doer can still try and race ns.somebank.com to guess an answer.
3. The evil doer repeats step 2 and increments the random domain name every time. For example, the next domain name the evil doer might try could be randomAAAAAB.somebank.com. Since QIDs are just randomized and not cryptographically secure, the attacker may still have a mathematically reasonable chance at eventually guessing correctly and beating the real name server’s response. If that happens, then the real name server’s response is dropped and more importantly the attacker has earned the right to send a DNS Resource Record updating the name server for the bank. (i.e. The attacker gets to poison ns.somebank.com and make it point to their phishing site.)

It’s clever. It’s not easy to solve, so we’re going to play the patching game again and people are rushing to patch their DNS servers. Now, this post is not going to talk about the losing battle that is penetrate-and-patch. Although it would be fun to rant, that debate is no longer interesting since all the smart people are on the same team.

So why is the flaw (and perhaps computer security on the whole) interesting? The assumptions involved. Professor Spafford has a great quote about computer security and assumptions:

Finding vulnerabilities is simple; discover the assumptions a developer made, ad then violate those assumptions.

People have become accustomed to DNS working. They assume it will work. It’s not just users, but also developers that do this. Let’s take one example: OpenID.

For those who don’t know, OpenID is an identity system that enables users to store their identity information in one place. Instead of having usernames, passwords, addresses, and other account information stored separately at amazon.com, ebay.com, flickr.com, etc…, users would be able to store it (and update it) all in one place. It’s a really neat idea that could eventually provide useful services and save real people time. However, it was designed with the assumption that DNS just worked.

Kim Cameron points this out on his blog, but I think the best summary of the problem is by Tim Anderson:

Note that Cameron is not opposed to OpenID. Apart from anything else, he recognizes that this may well be the beginning of an identity revolution – part of a process, at the end of which we get a safer, less spam laden, less criminal-infested internet.

At the same time, he’s right. The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.

Now, it strikes me that you can largely fix this by requiring SSL connections. In other words, have the OpenID URL be an https:// URL, and have the relying party (the website where you want to log in) check for a valid SSL certificate. Note thought that SSL must be used at every stage. OpenID lets you use your own URL as the identifier, but redirect to another OpenID identity provider. Both URLs must use SSL to maintain integrity.

Scary indeed. The OpenID developers have assumed reliable DNS. Now, Tim’s probably right that encryption is the solution to this problem, but I don’t think SSL would work. Even if there is a certificate for the site, most browsers fail to properly inform users what it means when an SSL certificate has changed or isn’t there now. Plus, people are trained to use the domain name and trust that it works.

So how can encryption help? Well, I think DNSSEC and IPSEC (or IPv6) would actually solve (not patch) the problem, but designing better protocols hasn’t been the real issue. DNSSEC and IPSEC have been around for a while. The problem is adoption. No one uses these protocols just like no one uses PGP for encrypting their email.

Metcalfe’s Law is holding most people back since they don’t want to be the only ones using the “other” network. This is another great example of why “road” or “highway” analogies don’t work for the Internet. If this were a pothole or even a collapsed bridge, we could fix the problem properly without really affecting most people. However, since this is the Internet, we can’t actually solve this unless everyone agrees to stop using DNS.

So we’re going to continue to see problems with old infrastructure protocols like DNS. As a result, phishing will continue to be a serious problem. The only way this will stop is if there is a problem so big that the monetary incentive to avoid the problem pushes everyone to change. Who wants to guess how big of a problem that would have to be?