10:37 AM
Connect Directly
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
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web