SQL Injection Attack Exposes Comodo Partner Customer Data

A SQL injection attack exposed customer certificate information and employee log-in credentials for a Comodo reseller in Brazil. No certificates were issued or compromised.

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.

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 doesn't 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 Comodo systems were never
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.
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
organizations, 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.