Send to Kindle

SSL securityUPDATED: A major issuer of secure socket layer (SSL) certificates acknowledged on Wednesday that it had issued 9 fraudulent SSL certificates to seven Web domains, including those for Google.com, Yahoo.com and Skype.com following a security compromise at an affiliate firm. The attack originated from an IP address in Iran, according to a statement from Comodo Inc.

Comodo, of Jersey City, New Jersey, said, in a statement on its Web page, that an attacker was able to obtain the user name and password of a Comodo Registration Authority (RA) based in Southern Europe and issue the fraudulent certificates. The company said the hack did not extend to its root keys or intermediate certificate authorities, but did constitute a serious security incident that warranted attention.

SSL Certificates are the Internet equivalent of drivers’ licenses, said Paul Turner, the vice president of products and customer solutions at Venafi, an Enterprise Key and Certificate Management firm. The bogus certificates could be used in phishing or man in the middle attacks against organizations that haven’t updated their certificate revocation lists, he said. They could also be used to sign applications and plug ins, he said.

Registration Authorities are subordinate to Certificate Authorities, which issue SSL certificates. RAs are entrusted with the responsibility of authenticating the identities of parties who are being issued a certificate by the CA. In the latest Comodo incident, the attacker were able to falsely attest to the authenticity of the parties requesting the cert using the stolen RA login information.

The Mozilla Foundation, Microsoft, Google and other firms rushed out patches to their Web browsers on Tuesday to block the fraudulent SSL certificates. In an incident report filed on March 15, Comodo said the nine certificates were issued to seven domains, but that no attacks using the certificates had been seen in the wild.

Public attention to the breach started with researcher Jacob Appelbaum of The Tor Project, which noticed revisions to Google’s Chrome and Mozilla’s Firefox Web browsers on March 17 followed by an announcement of updates to the certificate blacklists. A key Mozilla Website, addons.mozilla.org, was one of the nine forged certificates issued.

In a statement published on its Web site, The Mozilla Foundation said that that it had updated Firefox 4.0, 3.6 and 3.5 to recognized the forged certificates and block them automatically. Mozilla said that users on a compromised network could be directed to phishing Web sites that used the forged SSL certificates and fooled into revealing personal information or downloading malicious programs. Google issued a patch for its Chrome Web browser on March 17th.

The compromise was detected last week and was believed to have lasted only hours before being detected. Attackers were still using the account at the time it was discovered and the certificates in question were revoked immediately, Comodo said. The IP address used in the attack was traced bay to an Internet Service Provider in Iran. In its statement Comodo didn’t rule out political motives for the hack.

“It does not escape notice that the domains targeted would be of greatest use to a government attempting surveillance of Internet use by dissident groups. The attack comes at a time when many countries in North Africa and the Gulf region are facing popular protests and many commentators have identified the Internet and in particular social networking sites as a major organizing tool for the protests.”

The breach raises serious questions about the system of checks and balances used to issue and monitor SSL certificates, which are the most common tool for attesting to the validity of a Web site and secure traffic to and from it. While media attention in the last year has focused on tools like FireSheep, which extol the security benefits of using SSL to harden insecure Web sessions, security researchers have long called attention to inherent weaknesses in the infrastructure that supports SSL. The Electronic Frontier Foundation has a project, the SSL Observatory, to investigate the authenticity of SSL certificates used to secure Web sites.  In particular, EFF says that Certificate Authorities, or CAs, are a weak link in the chain of trust – most browsers support a long list of CAs, but not all do a thorough job of ensuring the integrity of those requesting certificates.

Turner of Venafi said that the compromise poses huge challenges for organizations that rely on Comodo certificates. Most large organizations might store hundreds- or thousands of unique certificates on Web servers, application servers, mainframe systems and end user workstations. However, organizations typically do a poor job of keeping track of which certificates they use and where they are stored. The Comodo breach will force organizations that might replace one or two certificates in a year to swap out nine certificates in a matter of hours – a painstaking and multi-step process that is often handled manually.

Comodo may be the poster child for the vulnerability of the certificate infrastructure, but the company is hardly alone.
“Just as RSA showed they can be compromised, Comodo shows that this is something that can happen with any Certificate Authority. In fact we have no idea that it hasn’t happened to others,” he said.

Send to Kindle
Categories: Data Breaches, Government, Malware, Web Security

Comments (32)

  1. Anonymous
    2

    Typo 7th paragraph:

    The IP address used in the attack was traced bay to an Internet Service

  2. Anonymous
    3

    FUD: “The attack originated from an IP address in Iran, according to a statement from Comodo Inc.”

    IP addresses can be spoofed or routed through a proxy to make it appear as if the attack originated in Iran.  See Tor.  Any respectable hacker/cracker/script kiddie uses at least one proxy server…

    Look, my IP says I live in Ohio!

  3. anarcat
    5

    There’s a lot to say about this, but i’ll just state for the record that we should migrate away from central authority systems and everybody should adopt the monkeysphere for distributed authentication:

    https://web.monkeysphere.info/

  4. Anonymous
    6

    Typo in the 6th too.

    The Mozilla Foundation said that that it had updated Firefox 4.0, 3.6 and 3.5 to recognized the forged certificates and block them autuomatically

     

     

  5. JD
    8

    This doesn’t surprise me. I considered using Comodo for our SSL certs at one point, but besides their foreign headquarters and some arrogant statements by their CEO, what really changed my mind was the fact that on one of their own certificate sites – instantssl.com – the order checkout form (that takes passwords and contact information) is on a non-SSL page!

    The form submitted to an SSL connection, but the user didn’t know that in advance. It was too sketchy for me to trust them with my web security.

  6. Anonymous
    9

    My Skype account was hacked by people who than used all the credit to make calls to a Taiwanese number. I do use long passwords and make use of the available character set.

    Passwords stored with the Chrome Browser also if they are a portion of the Windows OS Userdata kann be decrypted. 

    My advise, don’t store any Passwords with you browser application!!! Even if you are running a firewall, virus software etc..

  7. Anonymous
    10

    The world’s become totally dependent on certs for security and auth–but there’s no way to manage to volume. 

    This can’t bode well for the future of PKI–once one CA’s been hacked, they’re all vulnerable.

    And here’s to the recent RSA hack… ugh

  8. jroysdon
    11

    The problem is that SSL certs are not tied to domains and therefore not limited to any Root CA.

    In other words, any Root CA can issue SSL certs for any domain. That includes the CN-NIC and plenty of other less-than-trustworthy Root CAs.

    In fact, if you have a way to intercept/view email for a domain, you can issue an SSL cert for that domain via StartSSL. StartSSL relies on an email sent to [postmaster|webmaster|hostmaster]@domain.com and if you can get that you can then be trusted to issue certs for that domain.

    The root CA model is fundamentally broken. It needs to be scraped and DNSSEC used to bootstrap the way we trust SSL certs.

    Then all you need is the root DNSSEC Trust Anchor and you can verify all the way down to any domain that is DNSSEC-secured. Once you have that (a secure way with a single piece of information (DNSSEC root trust anchor), you can put information into DNS and verify it is not compromised. You can then put SSL CAs for a given domain and/or SSL Signatures/Keys into DNS.

  9. John Gerber
    13

    As far as the client side is concerned, activate your Trusted Platform Module (TPM) and store the VPN certificate in this hardware container from which i can not be lifted by rogue software.

  10. Anonymous
    15

    If you look at a cert issued in the US it frequently has c=US in the distinguished name, meaning you could navigate the c=US directory to find that cert. You were able to do that in the past and should be able to do that soon when NSTIC is finalized and a X.500/LDAP infrastructure is back in place that list certs, contacts, attributes.Trying to track down a fake cert is better done by the Perspectives program from CMU which relies on notaries.

  11. Anonymous
    16

    As someone that worked as an RA for a different CA, I can tell you why this hasn’t happened to them. 

    1. Multi-factor authentication. The fact that a CA is using simple passwords is laughable. 

    2. Internal tools. None of the issuance tools were accessable externally. 

    3. Fraud lists. Any cert with an obvious phishing-related term in the domain is flagged and needs additional approval. 

    The scare quote at the end of the article is stupid. Comodo got hacked because they were being careless. 

  12. Jacob
    17

    What about OpenID? Both Yahoo and Google are OpenID providers… could these certificates be used to trick relying parties? 

  13. Jacob
    18

    Yahoo and Google are both OpenID providers…. could these certificates be used to trick relying parties? 

  14. Gary
    19

    This is down to Comodo allowing their resellers to ‘vet’ orders placed. They have been dragged down before due to this problem.  They have no phishing checks involved when orders are placed.  Surely they should of learnt last time this happened. 

    If they ‘Comodo’ had a proper vetting team, to vet ‘suspicious orders’ this would not of happened.  Other SSL providers have this, which can sometimes annoy customers, getting caught for phishing and delay the certificate being issued.  But alteast these SSL providers do not issue certificates to anyone for any domain!!!

    Comodo, as  a company, there Cheap and Cheerful. The price they charge for certain SSL, there is no way the relevant checks etc could of been done correctly before issuing it for the amount they  charge!!

    I would from experience of all Certificate Authorities avoid Comodo like the plague!!! Thats if you value your potential customer’s and the image you wish to portray online.

  15. Anonymous
    20

    > value your potential customer’s and the image you wish to portray

    I would avoid apostrophes for the same reason

  16. Anonymous
    21

    FUD: “The attack originated from an IP address in Iran, according to a statement from Comodo Inc.”

    Comodo was fooled into issueing certs without vetting the requester properly, so we should blame the muslims on this one.  It must be them!  They hate our freedom and security!

  17. Anonymous
    22

    Comodo is a joke. Have they not heard of a client certificate? Considering they can generate them, that could have stopped it right there apart from the terrible vetting process, the use of IP restrictions, or other small safeguards. 

    Having used several other CAs before, when my certificate comes up for expiration, they call me up and tell me lies about competitors to get me to switch. This story does not surprise me at all! 

    AVOID COMOMDO

  18. Anonymous
    25

    i been dealing with this sort of problems since aug 2008.   if follows the same pattern where my ip now shows coming from bejien china.  all i know is its apnic(asia tele com company), but originally, it was from a microsoft ceo.   i know that hotmail also should be on the list, but why isnt it.  it goes directly to dep of trans at pentagon.   the confusions is set so everyone points fingers.    some hacker info is correct, but they wait till a similar attack happens, and dump the load onto that hacker.  

  19. Anonymous
    29

    Just to make your day, the reverse is quite possible too. The form could be at an https link, but submission of the data could be via http.

     

     

  20. Anonymous
    30

    Once you have that (a secure way with a single piece of information (DNSSEC root trust anchor), you can put information into DNS and verify it is not compromised.”

    Unless, of course, the DNS provider has been compromised.  I guarantee DNS providers (registrars, 3rd parties, private systems, etc) are far less secure than CAs are.

  21. Anonymous
    31

    The actual statement was: “The circumstantial evidence suggests that the attack originated in Iran. “

    So, they only said it suggests it originated in Iran. They’ll obviously find out more as they keep digging. However, they did say the one certificate was actually tested there as well.

    The site in Iran on which the certificate was tested quickly became unavailable.”

    So, getting a site up on another country’s IP is a neater trick. Not saying it’s not possible, it just makes it less likely a proxy was used is all. Furthermore, one only bounces off a proxy if they care to hide their identity. In a state-driven attack, that’s not necessarily the case. Besides, this information is only useful if the DNS is poisoned/under control. In a state-driven attack, this is entirely possible and gives clear motive (control or spy on the people). Given what’s currently going down in the middle east, it wouldn’t surprise me one bit.

     

     

  22. Anonymous
    32

    Any hacker/cracker/script kiddie from the ’90s uses at least one proxy server…

    Fixed. Any *respectable* one knows that it doesn’t matter how many proxy servers you use, you can still trace the packets if you take the time to do so. Yeah, you might spoof your IP for a website (still visit LiveJournal?), but you’re talking about CAs here, companies that kiiiiiiiiinda have a little bit more experience with IPs.

Comments are closed.