Risk
9/2/2011
10:37 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Breached CA Underscores Need To Examine Who You Trust

Companies need to know who their software is trusting to close vulnerabilities

The latest breach at a certificate authority (CA) demonstrates how companies need to keep track of who their software is trusting so they won't be vulnerable to a host of attacks enabled by false digital certificates.

On Tuesday, Dutch security firm DigiNotar acknowledged that a July breach led to the issuance of false digital certificates. The grudging admission came three days after an online post showed that the company issued a certificate for Google, possibly allowing fraudsters to create fake websites mimicking the online search giant's services or to insert themselves in otherwise secure communications.

While browser makers scramble to revoke all of the certificates, companies need to survey their software and systems to minimize the impact of such attacks in the future, says Jeff Hudson, CEO of Venafi, a maker of certificate management systems. More than half of all companies have little idea of the extent that they rely on certificates to secure their systems, according to a recent survey by the firm.

"Now companies are saying, 'Holy mackerel, we have this stuff everywhere, and we are not prepared to deal with a third-party compromise at an organizational level,'" Hudson says. "This is not something that you want to leave to a system administrator who is managing 40 systems -- it is an organizationwide issue."

Breaches at third-party trust providers have become a major issue this year. DigiNotar is the latest CA to acknowledge a breach of its systems. In March, online security company Comodo acknowledged it had issued a number of high-value certificates to fraudsters. The admission came the same month that security giant RSA discovered a breach that leaked sensitive information about the company's SecurID tokens, which secure a variety of online transactions and communications.

Security experts estimate than more than 270 certificates were falsely issued in the DigiNotar case, but it's unknown for which domains or whether the attackers created an intermediate CA, which would give them the ability to issue a large number of untraceable certificates. The discovery of the fake Google certificate came because the company's Chrome browser is coded with knowledge of the limited number of real and valid Google certificates.

"Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services," Google said in a statement on Monday. "The people affected were primarily located in Iran."

The attack appears to have been aimed at eavesdropping on Internet users located in Iran, which has fueled speculation that the attacks were conducted by that nation's government. The issuance of certificates for the pro-privacy Tor network appears to support the theory, as well.

"What is unusual here is not that a CA was compromised, but that someone noticed -- this is happening all the time," says Moxie Marlinspike, CTO and co-founder of Whisper Systems, a firm focusing on securing mobile communications. "The only reason we noticed was the attacker was not smart enough to fingerprint the browsers they were attacking."

If certificate breaches are occurring without being detected, then a company's best defense is to limit its exposure to CAs that might not have adequately secured their systems and processes, Venafi's Hudson says.

"You have to know where all the certificates are installed, so you know the people that you trust," he says.

In addition, companies should not just deal with a single CA, but have multiple backups. Even those firms that self-sign their certificates should have some redundancy built in, he says. Finally, companies should have mechanisms in place to allow certificates to be replaced quickly in the event of a breach at a trusted third party.

That's not always simple, however, Whisper Systems' Marlinspike says.

While companies might only use a few CAs to sign their own systems, online transactions through the browser have a broad list of more than 600 CAs, leaving their trust models in the hands of the least secure third-party company. Removing untrusted third parties from the browser can lead to problems, he says.

"You can go into the trust database and remove companies you don't trust, but if I go in and say I don't trust VeriSign -- and I don't -- I still can't remove them because it breaks the Internet," says Marlinspike.

With all of the breaches in the past year, the browser trust model needs to be fixed, he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: LOL.
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6213
Published: 2014-04-19
Unspecified vulnerability in Virtual User Generator in HP LoadRunner before 11.52 Patch 1 allows remote attackers to execute arbitrary code via unknown vectors, aka ZDI-CAN-1833.

CVE-2013-6214
Published: 2014-04-19
Unspecified vulnerability in the Integration Service in HP Universal Configuration Management Database 9.05, 10.01, and 10.10 allows remote authenticated users to obtain sensitive information via unknown vectors, aka ZDI-CAN-2042.

CVE-2012-0871
Published: 2014-04-18
The session_link_x11_socket function in login/logind-session.c in systemd-logind in systemd, possibly 37 and earlier, allows local users to create or overwrite arbitrary files via a symlink attack on the X11 user directory in /run/user/.

CVE-2012-6646
Published: 2014-04-18
F-Secure Anti-Virus, Safe Anywhere, and PSB Workstation Security before 11500 for Mac OS X allows local users to disable the Mac OS X firewall via unspecified vectors.

CVE-2013-4279
Published: 2014-04-18
imapsync 1.564 and earlier performs a release check by default, which sends sensitive information (imapsync, operating system, and Perl version) to the developer's site.

Best of the Web