Comodo says VeriSign SSL processes vulnerable to attack (Update)

by Steve Ragan - Jun 24 2010, 18:51

Yesterday, The Tech Herald covered a story from Comodo who said that they had discovered a vulnerability that exposes a significant security concern for VeriSign’s customers. This update includes further details of the discovery, as well as additional comment from both vendors.

The original story is here.

We spoke to Comodo’s CEO, Melih Abdulhayoglu, who gave us a brief on the discovery, as well as answered our questions posed in the previous story. Comodo alerted the media to their discovery of a certificate request page used by Bank of America to generate SSL certificates.

VeriSign, who operates this request page as a hosted service, said that the discovery did not constitute a security vulnerability, and maintained that stance yesterday when we spoke to them on the subject for a second time.

What the certificate request page does is act as a place where someone inside an organization goes to ask their 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. We’ve added some images below of the portal. (Note: We have removed some internal references from the images.)

Our conversation with Abdulhayoglu started with a demonstration of what his company had discovered. While we were already familiar with the certificate request page used by VeriSign customers, it was interesting to hear the story of the discovery and see the search string used to locate the request pages themselves.

As it turns out, while VeriSign was implementing a robots.txt file to prevent search engines from indexing request pages, Google already had 32 listings. Along with Bank of America, there were request page links for state governments, financial institutions, and universities.

“First of all, Security 101, what the hell is VeriSign doing allowing Google to index this type of information? Having applications made public so people can use the Internet to access it, is one thing. Allowing Google to index is another. It is Security 101,” Abdulhayoglu said.

Based on conversations with VeriSign shortly after our talk with Comodo, we asked why Google was still showing the sites listed. As it turns out, another possible explanation for the indexing was overlooked. The organizations themselves allowed them to be indexed by placing links to the request pages somewhere within their forward facing websites.

In addition to using robots.txt files, VeriSign worked with Google to have the request pages removed from search listings. We confirmed that the 32 links discovered yesterday were gone as of 11:00 a.m. EST on 24 June 2010. Cache copies of these pages have been removed as well.

“If the customer chose to keep the page public, it’s not clear that VeriSign should have unilaterally chose to make it private,” VeriSign’s Tim Callan explained to us, when asked why Google was allowed to index the pages.

Abdulhayoglu questioned the logic VeriSign used when they denied that there was a problem with the request page being public, yet deployed a fix all the same.

“Now yesterday they put robots.txt in, yet they say that there was no problem. How can they possibly say there is no vulnerability, yet go ahead in fix it in the background? You lose trust lying to people the other hand, and going and fixing it,” he said.

For their part, when asked about Comodo’s question, Callan said that there are opportunities to make improvements to products without there being a vulnerability. “We agree that the robots.txt is a good improvement and are adding it back, despite the fact there is no vulnerability.”

In his interview, Abdulhayoglu addressed the risks that the request pages posed, by asking about revoking certificates, instead of attempting to generate false ones. In addition, the discovery of a domain list used to complete the Bank of America SSL request, as well as the administrator email link at the bottom of the request page, could be used for Phishing.

The domain lists are tempting, but they are already known to criminals for the most part given that Bank of America is still one of the top targets for financial Phishing. “The idea that these domains in any way increase the impact of Phishing is absurd,” Callan said, adding that the administrator email addresses are no more credible than the ones a criminal would already be using for Phishing scams.

In addition, the revoke option is a setting that the administrator has to choose to allow. Otherwise it can be disabled in the public view. When we viewed the direct link for Bank of America’s request page, we noticed that the revoke option has been removed.

Another level of risk Comodo’s CEO mentioned was that the passphrase, or VeriSign’s challenge phrase, could be incorporated into the CSR itself.

“We believe, we don’t know fully, but we believe that the passphrase could be incorporated into the CSR itself, which means that if you have access to the CSR then you know the challenge passphrase for verification,” Abdulhayoglu said.

When asked, VeriSign said that the only things used out of the CSR are the common name, the organization unit name, and the public key. “We never take the challenge phrase out of the CSR,” they said.

However, it is possible for a customer to ignore VeriSign’s advice and use the challenge phrase in a CSR. There is an option field available for this. The trick would be to get the CSR itself, which isn’t as easy as it sounds, but it is possible.

Once obtained, if the optional field of the CSR is used to hold the challenge phrase, it can be decoded using many different tools, some provided by vendors like Comodo and VeriSign.

Even so, there is no guarantee that the challenge phrase recovered is the one needed to communicate or authorize action from VeriSign. A criminal would have to risk trial and error, at the expense of being caught, to confirm the account controls.

Addressing some of our questions, we asked why Comodo used a former VeriSign employee to deliver the disclosure, as mentioned when they issued a media alert. It was a matter of the former employee being known to them.

“We knew him, and we needed a third-party in the industry,” Abdulhayoglu said. “It allowed us to have quick access to VeriSign people as well.”

The reason for not using a current employee is that CCSS, which is based on the NIAC disclosure framework, requires a neutral third-party. Also, the organizations impacted by the discovery were not tapped to alert VeriSign, Abdulhayoglu said, because he didn’t see it as ethical to do so.

When asked why they went public, after waiting a few days, Comodo said that they did so because VeriSign denied the vulnerability. “If they [had said] ‘yes we have a vulnerability’ we’d [would have] stopped immediately,” Abdulhayoglu commented. “It was not our intention to go public at all if they accepted the vulnerability, but knowing that all these people could be at risk, keeping it quiet as Comodo would be unethical.”

We also asked why Comodo was searching for these request pages in the first place. As it turns out, there is an interesting story to their discovery. They didn’t search for the request pages as a vulnerability check. They found them while working with a new customer.

Working in sales support, a Comodo employee was helping with a customer migration when he discovered the Jurisdiction Hash string. From there, he attempted to research more on the topic, and instead of locating the request page of the customer, he discovered Bank of America and the others.

As mentioned, the links discovered by Comodo have been pulled by Google, and VeriSign is working to keep them off for good. If there is anything more to come from Comodo’s discovery, we’ll update this story.

Around the Web