Should we distrust Comodo after issuing a rogue SSL certificate for Windows Live?

About a year ago, I wrote an article why I no longer trust StartSSL. Back then, I said I switched to a paid certificate issued by Comodo under the PositiveSSL brand instead. A reader now brought a recent issue with a Comodo certificate erroneously issued for Microsoft’s Windows Live to my attention and asked whether I would still prefer them over StartSSL.

Arno wrote this comment (link):

Do you still trust Commodo to be more trustworthy than StartCom just because they asked for money to handle revocations? Think twice – a guy from Finland managed to get a valid certificate from Commodo for “live.fi”, (Microsoft Live in Finland), just because he was able to register “hostmaster@live.fi” as his e-mail-address:

http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/

I started to type my answer as a comment as well, but soon I realized my explanation just became too long to be a comment, so I turned it into an article on its own.

Futher information on the issue can be found in a follow-up article. It confirms a third-party registered the mail address hostmaster@live.fi at Windows Live and then requested a domain control validated SSL certificate from Comodo for the domain name live.fi.

The domain control validation issue demonstrated here is not really new and I remember the same thing happened years ago with other free mail hosters, but I can’t seem to find any big news reports. However, this issue was actively discussed about 5 years ago already.

In this case, it is Microsoft running the Windows Live service that is to blame. They allowed to register a special local part on their domain by an arbitrary user. Some local parts are commonly used as administrative contacts for domains and are in use for this purpose pre-dating the internet. For example, RFC822 from 1982 reserves the name postmaster, while RFC1034 from 1987 first used the hostmaster name as the recommended example. RFC2142 explicitly defines more common local part addresses such as webmaster and abuse as administrative contacts and recommends to use them for this purpose only. For some of them, the document even states they MUST be used if the service is offered at this domain name.

If you give out access to administrative adresses to your users, you are the one to blame. In the past, certificate authorities allowed to use even more local parts for domain control validation. About 5 years ago, security researchers warned of the problem and CAs such as VeriSign recognized the problem and reduced the number of accepted addresses to counter this problem.

Today another article was published on Ars Technica. Microsoft was actually notified 4 years ago. That is a pretty long turn around time for such a critical vulnerability.

Now I am getting back the initial question. StartSSL also uses these generic addresses such as hostmaster@ for domain validation. Since domain validation for SSL certificates is a fully automated progress, the attacker being in possession of such a local part could have requested a certificate from any SSL certificate authority. There are no further restrictions to get such a SSL certificate, you only need to be able to receive mails at one of the special local parts recognized by the CA you choose.

For this vulnerability, StartSSL is in no way better than Comodo or any other certificate authority.

Discuss on Hacker News

8 thoughts on “Should we distrust Comodo after issuing a rogue SSL certificate for Windows Live?

  1. Razvan Mihaiu

    When I heard about this first time, I thought that Comodo fucked it. Your explanation makes it clear that this is not their fault at all. In fact, this could still happen today if some webmaster is smart enough to allow customers to use email addresses such as “hostmaster@”.

  2. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware - Securelist

  3. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware | VIRUS.COM.AR

  4. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware | Digitpol

  5. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware | ThreatRavens

  6. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware – f1tym1

  7. Pingback: Hoạt động AppleJeus: Lazarus truy cập trao đổi tiền điện tử với trình cài đặt giả mạo và phần mềm độc hại macOS | Top - Tin tức an ninh mạng nhanh nhất Việt Nam

  8. Pingback: Operation AppleJeus: Lazarus hits cryptocurrency exchange with fake installer and macOS malware | Deep Security News

Leave a Reply

Your email address will not be published.

ERROR: si-captcha.php plugin: GD image support not detected in PHP!

Contact your web host and ask them to enable GD image support for PHP.

ERROR: si-captcha.php plugin: imagepng function not detected in PHP!

Contact your web host and ask them to enable imagepng for PHP.

This site uses Akismet to reduce spam. Learn how your comment data is processed.