Comodo says VeriSign’s SSL processes vulnerable to attackby Steve Ragan - Jun 23 2010, 20:00
Comodo issued a press release yesterday that said it has alerted VeriSign to a security vulnerability that exposes a significant security concern for VeriSign’s customers. What Comodo found is open to debate when it comes to risk level. Also, the method of disclosure raises some eyebrows.
Update: More information here.
Comodo managed to locate the certificate request page for a single VeriSign customer -- which is indeed a major financial institution. What the certificate request page does is act as a place where someone inside the financial institution goes to ask their certificate administrator for a new certificate. From there, the administrator will need to approve or deny the request and select the type of certificate to issue.
The reason this portal exists in the first place is business convenience. Administrators can control the certificate environment, they can watch certificate expiration dates, assign certificates to various jobs, manage bulk purchases, as well as access several backend tools VeriSign offers to Enterprise customers that operate in scale.
Comodo was able to discover this site, which is hosted by VeriSign, due to a missing robots.txt file. VeriSign has since fixed the issue, but takes all the blame for not having the proper file in place. The discovery leads one to wonder why Comodo was searching for items related to VeriSign in the first place. When asked, VeriSign said it doesn't have a similar practice for its competitors.
The Tech Herald spoke with Tim Callan, Quentin Liu and Rick Andrews from VeriSign, to talk about the Comodo press release and the disclosure method itself. We started by asking what they made of the press release from Comodo.
“We do not agree with that assessment of the situation on a number of points. The first of which is, there is no major security flaw,” said Callan.
“There is arguably a minor esoteric security flaw, which really gets into the realm of how much you want to lock [certificate management] down or open it up. It’s more a thing that security people have interesting debates over rather than anything that is cut and dry,” he added.
So what about attack vectors? If an attacker knew the proper format for the certificate request page, and discovered one online, could it then be immediately used for malicious means?
The URL formatting for the certificate request page is uniform for each customer using VeriSign’s services. However, “part of the URL is a long semi-random looking string called a Jurisdiction Hash, which is specific to the customer and it’s not really guessable,” Andrews told us.
Adding to that, Liu mentioned that it isn’t guessable and “it’s also not a secret either.” At the same time, even if the Jurisdiction Hash was known, the attacker would still face the layered mitigations that the customer and VeriSign have in place.
How could an attacker generate rogue certificates without alerting the administrator? They couldn’t, and even if they hijacked the administrator’s credentials and approved themselves, the generation would be noticed by VeriSign and duly flagged.
On top of that, if they had access to the administrator’s credentials, there is far more to worry about, as that would mean a potential network compromise. At that point, why would a criminal bother with fake certificates?
From there, the real harm would be pure annoyance. An attacker could flood the request page with data, or request hundreds of certificates. Both would essentially create a denial of service, assuming it worked.
Because the VeriSign certificate request process is two-tiered, access to the request page isn’t enough to have certificates issued at will. The process for a new certificate to be issued for an Enterprise customer requires the input of several people and manual confirmation.
Financial institutions, such as the one discussed by Comodo, and any other large Enterprise customer for VeriSign, each have a multi-step verification process in place to manage certificate creation. An attacker can flood the request page all day long, and it would work right up to the moment that the data center managing that portal blocked them.
Comodo mentioned in press interviews with other media outlets that another risk its discovery exposed is that an attacker would view all of the certificates a company has. “Our response to that is that those certificates are a matter of public information. So yes you can,” Callan told us. Is this a security risk however?
Comodo claimed that it had notified VeriSign using “the Vulnerability Disclosure Guidelines of the Common Computing Security Standards Forum (CCSS) by using an independent third-party as a medium for disclosure. It provided a disclosure document to VeriSign outlining the vulnerability.”
The CCSS disclosure entailed Comodo giving a PDF document to a former VeriSign employee who agreed to pass it along to people within the company. At the same time, one of the guidelines in CCSS is that the reporting party and the vulnerable party would discuss and work out a method of public disclosure and mitigation.
When VeriSign saw the PDF from Comodo, it simply stated that Comodo would go public with the discovery, and offered no timelines. Comodo alerted the media seven days after the former employee was dispatched to VeriSign. Is this truly following CCSS?
CCSS allows the reporting party to go to a coordinator, but is a former employee the best option? Why wouldn’t they use a current VeriSign employee? Why couldn’t they have used the financial institution where they discovered the request page? Other third parties out there could have allowed CCSS to be maintained as well. Why were they passed up?
“Comodo did not make VeriSign aware of the planned timing of this morning's press release or the content of that release. If Comodo had briefed us on the content of this release in advance, we could have corrected the egregious errors the release contained,” Callan wrote on the VeriSign blog.
We’ve reached out to Comodo for comment on its press release, as well as asked for a copy of the CCSS report. We have had no response to emails or voice messages at this time. If we get a chance to talk with Comodo, asking the questions we posed in this article, we’ll be sure to update the story accordingly.