Another Comodo Partner Hit By SQL Injection Attack
Though no certificates were affected, a SQL injection attack exposed customer data for Comodo’s Brazil partner
Browser security is back in the spotlight as another Comodo partner suffered a security breach that allowed attackers to access customer data.
Brazil-based ComodoBR is at least the fourth Comodo partner to be compromised this year. In this incident, attackers used SQL injection to access certificate-signing requests and expose customer information from the ComodoBR database. The exposed data files were posted on the text-sharing site Pastebin under two different accounts on May 21 and May 22.
Nothing To Report, Claims Comodo
In a SQL injection attack, some database queries are inserted on the Website, often masquerading as a comment or in one of the fields on a form. When the information is submitted, if the Website does not process the text properly, it will allow the malicious queries to execute on the database and return the results to the attacker.
Comodo president and CEO Melih Abdulhayoglu told The Register Website that Comodo’s systems were not compromised. He also said no certificates were issued as a result of the breach and that the reseller had no access to Comodo databases.
“So as a summary: it’s a SQL attack [which is fairly common] on a company in Brazil who sells some of our products.” he wrote in an email. “Nothing to report really.”
The customer information included name, address, email, fax, phone number, order number, domain name and certificate request. The type of Web servers the customer uses, the Web server’s serial numbers and the private key file name were also leaked. Email addresses, user IDs, and password information belonging to ComodoBR employees were also exposed.
While the certificates themselves don’t contain any information that an attacker can potentially abuse, the log-in credentials belonging to ComodoBR employees remain at risk. While the passwords were all hashed, they appear to be unsalted and using MD5 encryption, which has been proven easy to crack.
In March, a Comodo reseller in Italy was hit by a SQL injection attack and had its log-in credentials stolen. An Iranian hacker claimed responsibility for the attack, during which he forged counterfeit SSL (Secure Sockets Layer) certificates for major domains belonging to Google, Yahoo, Skype and Microsoft. Comodo detected the breach fast enough to revoke the certificates before they could be used. Since the fake certificates had been signed with Comodo’s root signing key, they could have been used to intercept and compromise users trying to access those sites.
After two more Comodo registration authorities in Europe were compromised, Comodo revoked all partners’ signing privileges and implemented a mandatory two-factor authentication system for processing certificate requests.
Egg On Face
Developers on the Mozilla.dev.security.policy mailing group called the latest incident an “egg-on-face” moment for the certificate authority. However, Eddy Nigg, founder, COO and CTO of StartCom and StartSSL, wrote on the mailing list that attackers may be able to change content in the database itself, which could actually trigger a new certificate for a different site than the one that had actually been validated.
The March incident cast serious doubts over the certificate-verification process, which essentially relies on trust. Major browser makers are revisiting how they handle Web authentication and investigating mechanisms to secure certificate authorities. Each browser trusts as many as 321 certificate authorities equally, which can turn into a security nightmare if any of them ever decide to publish fake certificates for sites that they don’t work with.
One way to improve security is to allow each Website to announce what certificate provider it’s using, according to Peter Eckersley, a senior staff technologist at the Electronic Frontier Foundation.
Various organisations, Comodo included, are working on mechanisms that would allow the domain holder to specify which certificate authority has the permission to issue SSL keys for the site. Under the system, if the Website returns a certificate signed by a different company than what is specified by the domain owner, the browser would know it was fraudulent.
All the proposals are still in the discussion stages, leaving the current system vulnerable.
