| By Woody Leonhard |
Two brazen Web-server break-ins this year call into question one of the Internet’s fundamental security mechanisms — website security certificates.
Because the most recent breach affected only PC users in Iran, most of us assume we’re immune. But we’re not; here’s why — and what we can do to protect ourselves.
The mainstream press has gone gaga over the story and has produced a blizzard of ill-informed and misleading reports. If you can join the words hacker, Iran, and browser with a few technical-sounding nonsense words and then speculate wildly, you, too, could be writing copy for one of the major news outlets.
Below, I explain exactly how security certificates work, and I describe the perversity of the certificate-issuing process: how we got into this fine mess and what we can do to stay out of it in the future.
Just what exactly is a security certificate?
No doubt you’ve used https secure sites for years. You know to look for the “s” in https before typing any sensitive information into your PC, and you know that your browser (depending on brand and version) displays a padlock icon or some equivalent symbol when it’s safe to type passwords, account numbers, e-mail messages, and similar personal information. If you don’t see a lock, or the lock is crossed out as in Figure 1, anything you type can be viewed by anyone casually snooping on your Internet connection.
Figure 1. An indication from Chrome that the site you’re visiting doesn’t have a valid certificate.
When you type https into a browser’s address bar, your browser must validate the site’s Secure Sockets Layer (SSL) certificate (or cert). If the browser believes it’s good, the lock shows up on your browser’s address bar and you have a secure connection.
Or do you?
The answer hinges on how a browser validates a particular SSL certificate. It’s complicated; each browser keeps a list of certificate authorities (CAs) — companies such as DigiNotar that issue trusted certificates — and that list is different for each browser. (For more on this topic, see the ISC Diary article, “How makers of Web browsers include CAs in their products.”)
The process will vary, but it typically goes something like this: you type https:\somebank123.com into your Web browser. The browser goes to somebank123.com and retrieves the site’s certificate. The browser then examines the certificate and determines which certificate authority issued the certificate, checking whether the CA is on its list of valid certificate issuers. In some cases, the browser goes out to the CA’s website to validate the certificate.
If the certificate is issued by, say, VeriSign (which has about half of the certificate business), the browser confirms that VeriSign is on its list. To double-check, the browser next goes to VeriSign’s website to make sure that the cert is valid. If the certificate passes muster, the browser establishes a secure, encrypted connection between the PC and the bank’s Web servers (and puts up the lock icon).
That isn’t the whole story — there are white lists, black lists, revocation lists, and all sorts of other complicating factors. But you get the picture.
Once upon a time, SSL certificates were managed by a handful of CAs. That’s changed; Web browsers now recognize between 30 and 60 CAs. The company that issues a cert is supposed to perform some due diligence to make sure each certificate is assigned only to a legitimate company, but what defines “due” and “diligent” is controversial. CAs are audited only once a year for compliance.
Owners of websites can get free SSL certificates. But a cert from a widely recognized CA costs between U.S. $20 and $1,500 per year. Selling certs is big business — so big, that the major CAs now farm out some of their authority. Many hundreds of companies called Registration Authorities (RAs) are now authorized to issue certificates on behalf of the big CA organizations.
Think of it as a franchise operation. You start a company and pay BigCA, Inc., to become an RA. You sell certs to anybody and everybody and make a lot of money doing so. You get good at selling certs, so you set up an online system so your employees can sit around all day, approving and selling more certs.
The certs are sold by your company, but they carry the imprimatur of BigCA. The folks at BigCA say you need to protect your cert-issuing system, and they check that you’re doing so — but they don’t check very hard. Therein lies the rub: breaking into an RA’s system and issuing fake certs with BigCA’s name is pretty easy. In the case of some RAs, apparently breaking into the cert-issuing systems took no more effort than a simple SQL injection.
The genesis of a man-in-the-middle attack
Back to our connection with https:\somebank123.com. The certificate passes the test; you sign on to your bank account, transfer some money, and you’re done. No big deal.
But what if a cyber thief with a faked certificate for somebank123.com can put himself in the middle of your conversation with the banking site? That’s a man-in-the-middle attack. You type https:\somebank123.com into your browser’s address bar and the browser heads out to somebank123.com, but somehow the bad guy redirects your browser so that it goes to his site. The bad site presents its faked certificate, claiming that it’s somebank123.com — and your browser accepts it.
The bad site also initiates a session with somebank123.com. When you type in your user ID and password, the bad site grabs that information and uses it to sign into somebank123.com. You think you’re directly connected to somebank123.com, doing business as usual, while the whole time the malicious man-in-the-middle site keeps copies of everything that’s coming and going. Your interaction with somebank123.com goes a little slower than usual, but if the man-in-the-middle operation works properly, you’re unlikely to know it’s there.
For a man-in-the-middle attack to work, it’s not enough that the cyber thief has a fake certificate: the thief inserts himself between your browser and the genuine site.
Fortunately, that step isn’t easy. In the past, we’ve seen website redirection crop up in many fascinating places. You may recall that altering the Windows HOSTS file can make a browser look for URLs in all the wrong places. There’s a good overview in a Windows Secrets Support Alert article way back in 2005.
Another technique, DNS poisoning, can also send your browser to a place other than its intended destination. There was a spate of DNS-poisoning attacks (more info) in mid-2008 that took advantage of an inherent flaw in the way Domain Name Servers used to work. That flaw’s been fixed, but DNS poisoning still happens.
The latest round of man-in-the-middle attacks, though, apparently took place with code running on or through Internet Service Provider (ISP) servers. In many countries, the government has direct control over ISP servers — indeed, in many cases, the government is the ISP. If a person or group in possession of a fake cert can take over the Internet Service Provider’s computers, all the elements are in place for this kind of man-in-the-middle attack.
How bad was the recent break-in — really?
This sort of attack has been around for more than a decade.
On Jan. 30 and 31, 2001, VeriSign issued two certificates to someone who said he or she was representing Microsoft, according to a CNET story. There was no technical wizardry involved: somebody simply sweet-talked employees at VeriSign into issuing the two certificates. Microsoft finally found out about the bogus certs and moved to revoke them in mid-March 2001. As best I can tell, nobody ever used those fake certs.
In March of this year, someone calling himself ComodoHacker — describing himself as a 21-year-old Iranian — broke into the certificate-issuing computers of a small RA firm in Italy called InstantSSL.it. InstantSSL sells certs for big-name CA Comodo (yes, the same Comodo that makes firewalls and antivirus software). ComodoHacker got into the InstantSSL system and found that he could issue and validate certificates under the Comodo imprimatur. Did he generate fake certs for paypal.com or bankofamerica.com? No — he went for addons.mozilla.org, www.google.com, mail.google.com, login.skype.com, login.live.com (Microsoft Live, including Hotmail), and login.yahoo.com. Those are precisely the kinds of sites a government might wish to monitor from the middle, to keep tabs on its residents.
The latest skullduggery occurred when someone — possibly the same ComodoHacker — broke into the cert system for DigiNotar, a CA (not an RA) located in the Netherlands, and gave himself many fake certs. From the cracked DigiNotar system, he then broke into six other CAs and issued additional fake certifications — more than 500 at last count. A complete list — which includes certs for Facebook, Tor, the CIA, MI6, LogMeIn, and WordPress — is available on the Tor site. The fake certs cover even *.*.com and *.*.org, which would in theory allow the owner of the certificate to snoop on just about any site.
The Dutch government has issued an interim security report that lists some of the damage. As a Sept. 6 Internet Storm Center ISC Diary entry observed: “The hackers breached the systems possible June 6th already, this got detected by DigiNotar on June 19th, The rogue certificates were created in July and the first time the *.google.com certificate that was detected in the wild was presented on July 27th …. Yet it took till DigiNotar was notified by [a Dutch government agency] before they revoked the certificate.”
In other words, the rogue Google SSL cert was in the wild for more than five weeks. DigiNotar has responded with a press release defending its laggardly ways.
The Dutch interim report clearly points the finger in the direction of Iran: “The rogue certificate for *.google.com detected in the wild was verified against the DigiNotar OCSP service from August 4th till it was revoked on August 29th. 300,000 different IP addresses verified that certificate. More than 99% of those addresses trace back to Iran.”
People in Iran got hit this time. They’re relatively easy targets because stepping into the middle of a browser conversation with Gmail or Yahoo Mail or Hotmail or Skype is something the Iranian government can do with impunity. But that isn’t the only way rogue certs can be used for man-in-the-middle attacks.
How to minimize your chances of being attacked
If you travel to a country that has tight control over its ISPs, the ComodoHacker experience should give you pause. It would be prudent to work through a Virtual Private Network while using the Internet in those countries. (See my Nov. 4, 2010, Top Story for details on VPNs.) Although a VPN won’t always foil a rogue-cert, man-in-the-middle attack, the attacker would have many additional hurdles to clear.
I lock down my Hosts file. Back in Windows’ infancy, some programs needed to modify the Hosts file to keep working correctly. Now when code changes the Hosts file, it’s a sign of bad programming — or that you’ve been infected. To lock it down, make sure you can see hidden files (instructions), navigate to C:WindowsSystem32driversetc, then right-click on the file called Hosts and choose Properties. Check the box marked Read Only, shown at the bottom of Figure 2.
Figure 2. Lock down your hosts file to block one more avenue of attack.
Finally, make sure you apply all recent updates for whatever browser you use. Internet Explorer, Firefox, and Chrome have yanked DigiNotar from their CA lists; Opera and Safari are just now catching up. On Sept. 6, Internet Explorer was finally updated to revoke DigiNotar certs on all versions of Windows.
What needs to be done to fix this mess
It bears noting that this insecurity isn’t a bug in Windows. It isn’t even a browser bug. It results from a defect in the way security certifications are issued and how that process has deteriorated in recent years.
Obvious questions abound. How does one compromised PC turn into six subverted CA systems? Aren’t the CAs even looking at their RAs’ internal security? How is it possible that any RA can issue certs for microsoft.com or google.com, or — for heaven’s sake — *.*.com? It doesn’t make sense.
Efforts are under way to patch the holes in the CA process. There are now multiple levels of secureness for SSL certs. For example, Extended Valuation certs (such as those offered on the godaddy.com site) are subject to more stringent validation. There’s a proposal by the Internet Engineering Task Force to allow owners of specific domains to pick which CA can issue certs for their domain. These are steps in the right direction, but the system itself seems rotten.
Unless the World Wide Web Consortium can come up with a technically sound solution — and get it past all the vested interests — we’re all standing on a very shaky foundation.
| Feedback welcome: Have a question or comment about this story? Post your thoughts, praise, or constructive criticisms in the WS Columns forum.|