What You Should, But Don't, Do About Untrusted Certs, CAs
Security departments could take measures to protect organizations from untrusted certificate authorities and counterfeit SSL certs, but most don't bother.
Despite worries about counterfeit certificates and man-in-the-middle attacks on SSL communications, many security professionals are doing little to protect their organizations from the dangers of untrusted certificates and certificate authorities (CAs), according to new research by Venafi.
Venafi surveyed 333 attendees to the Black Hat USA conference in Las Vegas last month about their perceptions and practices regarding CAs, the arbiters of online trust, which themselves may not always be trustworthy.
One of the most recent events jeopardizing the sanctity of certificates happened in March, when MCS holdings, an intermediary for the China Internet Network Information Center (CNNIC) CA, began issuing unauthorized certificates for Google domains (which could be used for man-in-the-middle attacks). Google responded by removing CNNIC from Chrome's list of trusted root CAs; Mozilla also refused to accept CNNIC certificates issued before April 1.
Another defining event was in 2011, when attackers breached Dutch CA DigiNotar and issued over 500 counterfeit digital certificates for some high-profile domains; DigiNotar went out of business the very next month. Ninety percent of respondents to Venafi's survey expect that within two years a "leading CA" -- perhaps Comodo, Symantec (which purchased Verisign), GoDaddy, GlobalSign, or DigiCert -- will be breached. Yet, respondents' readiness to respond to such a breach was insufficient.
Here's what you need to consider, according to Venafi VP of security strategy and threat intelligence Kevin Bocek.
Emergency Change of the CA That Issues Your Company's Certs
What if DigiNotar or CNNIC had issued the certificates your own organization used to secure your communications with customers? Once the CA is compromised, browsers and your customers begin declaring that CA -- and thereby your company -- "untrusted." Customers' access to your website may be restricted. Therefore, says Bocek, you should be ready to shift your keys and digital certificates to a new CA right away.
However, according to the Venafi survey, only 9 percent of respondents said they would use an automated system to replace keys and certificates. Most would rely on manual processes, 23 percent said they would hire an insider response firm to replace keys and certificates, 24 percent said they didn't know what they would do, and 6 percent admitted they would just continue to use the untrusted certs.
Bocek recommends following the guidance NIST developed after the DigiNotar incident, "Preparing for and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance." The guidance, he says, boils down to "know what you've got, have a relationship with someone you can switch to, then switch to them."
Remove Untrusted Certs From Your Trusted List
Venafi asked Black Hat attendees what action they took after the CNNIC incident. Most (34 percent) weren't sure, 23 percent said they did nothing at all, and 17 percent said they waited for Apple and Microsoft to act (the remaining major browser developers after Google and Mozilla, which had already acted).
Only 26 percent said they removed CNNIC from their list of trusted CAs on devices, and Bocek believes even that is "wishful thinking on the part of the respondents. I think that is an overestimation. I think that's what they'd have had liked to have done," but in actuality, he says, even fewer took that action.
Bocek points out that your devices -- particularly mobile devices -- probably already accept way more certs than you realize, and more than you require. Venafi asked respondents to estimate how many certificate authorities were trusted by mobile devices. To Bocek's surprise, respondents thought mobile devices trusted only two-three CAs, when in reality, iOS alone trusts over 240 CAs, including dozens run by international governments.
Further, all these trusted CAs are trusted equally -- but do they have equal fraud controls? "The answer, I already know, is no," says Bocek.
The U.S. government is concerned enough about the issue that the House of Representatives' Energy and Commerce Committee wrote letters to Apple, Google, Microsoft, and Mozilla in June, stating "our concern with CAs' unfettered authority to issue certificates is heightened when the CA is owned and operated by a government."
Protecting Keys And Certs On Your Internal Systems
Bocek reminds security professionals that they, not CAs, are also stewards of keys and certificates, and therefore responsible for their safety. In fact, Venafi's survey found that security pros may overestimate what CAs actually do to protect and monitor use of them.
As the report states, "CAs only issue and revoke certificates—they don’t monitor their use beyond
that in the wild and ultimately cannot provide any security for them." Yet, when asked "does your CA protect you from theft or forgery of digital certificates," 29 percent mistakenly answered yes and 34 percent said they didn't know.
Bocek recommends security managers review the updates to number 17 of SANS 20 Critical Security Controls for guidance.
Any CA Breach Can Hurt You
Consider that some CA you've never even heard of is breached and attackers start issuing counterfeit certificates claiming to be from your company, putting your customers at risk to MITM attacks. If you're Google and happen to run your own browser, you can help yourself out by yanking that CA from your trusted list, like they did with CNNIC. If you don't happen to be a developer with millions of customers, you can do... what?
"They could issue a cert for you and there would be nothing you could do," says Bocek. "You could be impaired by a breach at an organization that you have no relationship with. This is a new problem that we're only starting to understand."
Bocek says, "I think it's something that would scare board rooms."
Read more about:
Black Hat NewsAbout the Author
You May Also Like