When prompting for "postmaster", "hostmaster" or "webmaster", the values in that form should be just those and StartSSL should then put the two together ($MASTER_EMAIL + "@" + $DOMAIN.) They shouldn't assume that the "sendToEmail" value wasn't tampered with or overridden. If the original poster didn't include his screenshots or his steps then I wouldn't believe such a stupid mistake, especially one made by a certificate authority.
Back before I found Gandi.net I came across StartSSL (I was looking for basic SSL certifications.) At the time StartSSL's website was horrible, and I mean ugly, it turned me away because it felt so unprofessional. I see now, even with a new flashy website, that they still remain unprofessional (maybe not in their looks, but obviously in their practices.)
Your solution is still vulnerable in cases where someone's able to control postmasterfoobar@example.com. Admittedly, that's a bit far-fetched, but the correct solution would be to have an enumeration of allowed emails and only accept those (or, more generally: whitelist things).
It's amazing that their web component is even allowed to dictate what verification addresses are permittable. That should be the concern of a completely separate component of their infrastructure. Says a lot of about their security architecture, I guess.
Sorry, I made a bad implication that the backend would check to see if $MASTER_EMAIL was one of the three, as you called them, white-listed values ("postmaster", "hostmaster" or "webmaster") and if not then to stop processing the form.
For a while, I ran a small non-profit gaming site. This was well before Let's Encrypt, so we looked to StartSSL for a free certificate. They denied us.
Why?
Because we had links to a Paypal account set up to take donations. Even though PayPal had its own security, and we were only providing a link to it, that was enough for them to deny us the cert. They refused to understand that WE would be conducting no financial transactions using their service; or that PayPal was a separate entity.
It was maddening, and we ended up abandoning the whole idea of having SSL. Would that LE had existed.
Conversely, when I went for an SSL cert for my company, they called me (from Israel) on a phone number for our company taken from public sources, in order to verify we were who we were. Compare this to some other SSL providers, whose certification process is "can you give us $600?"
Sure, okay, but the certificate would never have been used to transact those donations. If you own a car, and you don't want dogs in your car, what does it matter if I put my dog in someone else's?
> This method is rarely used, instead for the domain validation most certificate authorities ask the domain owner to place a certain file in their websites.
This statement strikes me as odd. Email-based validation is the most common validation method used by most CAs for DV certificates. The only exceptions that come to mind are WoSign and Let's Encrypt.
The vulnerability is pretty bad, though. Good catch.
I work for a hosting provider that acts as a reseller of certs and we use the DV file option the author speaks of. It's easy for us because we can automate the entire process for the customer.
Whenever I've bought a cert for myself I've used the same process. I never thought email verification seemed like a great idea.
It's certainly easier for automation. I think the security implications are mostly the same - you're vulnerable to DNS spoofing and BGP hijacking either way. With email validation, a misconfigured or breached email server is enough to get a certificate, while with http validation, it's your web server or web app that could be vulnerable.
And a vulnerability in your website permitting an attacker to create a file opens the possibility for an attacker to get a certificate for your site too, and without certificate transparency you'll possibly never even know it even happened...
Maybe they meant that it's rarely used even though it's widely available. Anecdotally, I think that every certificate authority I've used allows for email validation but most offer options, of which I myself prefer the file or DNS record options.
Right now, StartSSL needs to do a quick search on their database to see which certs had email sent to a domain other than the one for which the cert applies. All such certs should be revoked immediately, and the owners of the domains involved notified of the breach.
Also, did they check properly for TLD and subdomain issues? If I have "me.blogspot.com", can I get a cert for "blogspot.com"? (What's a TLD today? It's complicated. See "https://publicsuffix.org/")
You would soon be left without any CAs. [1] People are pretty stupid when it comes to security, and this includes people working for CAs. There have been cases where the CA private key is publicly accessible to the internet without any password. [2]
--
[1] Yes, plenty of smart people have been advocating moving away from the current CA system. It's fundamentally broken.
I agree. What certificates have been issued until now fraudulently like this? Does SartSSL submit certificates to Certificate Transparency? And if it does, who knows if there is a bug in that code too, and certs have not been submitted?
Mozilla, Google, Apple and Microsoft should remove this CA ASAP. If it breaks some sites, even better. Maybe it will make some noise and fix all this CA bullshit for good.
IMHO this could be handled more safely: suspend or remove the acceptation of any StartSSL certificates issued after a given date. This should give them some more accountability.
Amongst it's repsonse, StartSSL should start logging every granted certificate to a Certificate Transparency log. From now on they need to provide the transparency so that site owners can verify there are no phony certificates being issued for their domains.
If someone has fraudulently issued a certificate for a domain you own using this (or any other) vulnerability, you're not actually a client of theirs and I don't see how they could force you to pay for revocation. Issuing such a certificate would obviously be a violation of CA/B Baseline Requirements.
Then again, I'm not exactly sure how one would go about reporting such a thing. Browser vendors have done most of the blacklisting for cases like this in the past (either by blacklisting individual certificates, or removing the root certificate completely for massive breaches). I guess I'd try my luck on one of their mailing lists or bug trackers.
If you have a regular certificate from StartSSL, there are no security implications for you because of this. (As in: for you specifically. For the CA system as a whole, this is a "Set-Your-Hair-On-Fire-And-Run-Around-Screaming-Loudly"-scenario.)
Well it was originally found 5 years ago. However StartSSL redesigned their site less then a year ago where I would guess the vulnerability came back (not that I have any knowledge to back that up).
I came on the website expecting some complex XSS attack and I just found a form validation exploit straight from the 90's, I can't believe it was not checked...
I do not have appropriate words for this. What a terrible nightmare. And even worse the second time they did this. I mean what kind of company is this? I am seriously shattered that they are so careless with so much responsibility. I never liked the trusted CA system on the web but always thought you would need to be at least some state actor or serious professional in order to be able to get hold of certificates from them without validation. They should all be required to get some real security audit on everything involved, and do it again whenever there is a change or some time passed. Without they should be dropped from the list of trusted CAs. I really do not get how this happened. It is like someone did this on purpose. I am sad now.
Meanwhile, when I tried to use them for a client's domain after actually paying $$$ for business validation I was refused because the names on the WHOIS records didn't match our business name.
So, I corrected my WHOIS records... After which they complained that the legal disclaimer posted on the website served from the domain in question was not identical to the registered identity that they had on file for me.
So, I updated that legal disclaimer (since I have root on my own server), and afterward, they STILL refused to validate the domain on grounds that it may only be validated as a business -- a service which they tried to sell me.
15 minutes later, I was up and running with my first Let's Encrypt-issued cert.
This is basically a worst-case scenario. The entire public Certificate Authority trust model depends on the validation of ownership of domains that certificates are being issued for. If an attacker can get a trusted certificate for facebook.com, then they can silently man-in-the-middle connections and pretend to be Facebook.
Now that Let's Encrypt is a thing, there's no reason to do business with these greedy losers.
That's not just an off the cuff insult either - I find very few charitable words to describe a company that charges $25 to rekey a certificate for reasons outside the user's control, i.e. heartbleed.
More to the point, in my arrogant opinion, now that a good, free alternative exists, users in the know should pressure the browser makers to come down a lot harder on companies that let this kind of issue fly. There's no need to work through the CAB bureaucracy when, say, Google and Mozilla are probably a lot more amenable to dealing with bad (be that by ignorance or malice) actors by refusing to recognize their crappily-validated certificates.
They're the CA that wanted to charge $25 to revoke free certificates that were potentially compromised due to Heartbleed. Yes, it wasn't their fault, so they wouldn't be legally responsible for it, but they're acting in bad form by not offering those revocations for free for such a major issue.
Until LE, StartSSL was the cheapest option all around. Note that with their $59/year option you would get unlimited wildcard certs, amongst other things. I am not happy about this bug, and am glad I moved to LE a few weeks ago, but in the past StartSSL has saved me a ton of money, even though their website had been godawful at the time.
Sure, and all that may be true, but I was specifically responding to what makes them greedy. Recommending people revoke their certificate and then hitting them with a $25 fee when they try to do so is practically the definition of such. They knew it was a serious problem, they knew all certificates could be affected (and even called it out) but then they didn't care to waive their policy in this one case even with all that taken into account. A CA who actually cared about the integrity of the system as a whole would have made a one time exception for this serious bug.
OK, so this seems like a terrible vulnerability. Does anyone know if (a) StartSSL has been notified and (b) what has been their response. This seems like such a severe vulnerability that publishing it on Blogspot seems too low key. Shouldn't there be a CVE about this?
> In 9 March, 2016 During my research I was able to replicate the attack and issue valid certificates without verifying the ownership of the website which I will explain later in my post, the vulnerability was reported and fixed within hours.
It's absolutely not an overreaction if it really happened. However, no hard evidence has been presented yet. I'm seeing screenshots and a story that anyone could have cooked up.
What would be the practical use of issuing a CVE for a vulnerability in custom code in one website? It's not like I'm going to run Nessus to scan my own network for this.
Maybe. StartSSL used to allow using E-Mail addresses from WHOIS records for domain validation and it's possible that this code was still in place on the backend.
Arguably this vulnerability is serious enough to see StartSSL dropped from the trusted root store, or at least see browsers taking action to block DV certs from StartSSL issued before a certain date. It/they won't be, of course, since the whole system is a farce.
I'd lament again how we still need to push DANE, but I was doing that 2 days ago here on HN[0] and I'm tired of it.
Nevermind, maybe the next bug we see will be in one of the other DV methods, like tricking the validator to access a http uri of your choosing rather than '/.well-known/', for instance. Or authoritative DNS poisoning.
Too bad the author didn't issue certificates for, say, google.com, microsoft.com, and/or mozilla.org. That'd be a more likely way of getting those browser makers to put some restrictions or "sanctions" on them like Google recently did with Symantec.
I think what jlgaddis was trying to say is that by getting certificates issued for the major browser vendors, you're much more likely to get them to pull this CA out of the trust store.
Well China injected javascript malware into http pages, joining people into a botnet that launched a DDOS attack on the github pages of human rights organizations, causing github downtime.
Back before I found Gandi.net I came across StartSSL (I was looking for basic SSL certifications.) At the time StartSSL's website was horrible, and I mean ugly, it turned me away because it felt so unprofessional. I see now, even with a new flashy website, that they still remain unprofessional (maybe not in their looks, but obviously in their practices.)