StartSSL domain validation vulnerability | Hacker News Reader

StartSSL domain validation vulnerability

oalmanna.blogspot.com

154 pointsbracewel73 comments

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?"

Was that an EV certificate? EV and DV certificates certify different things.

No, it wasn't an EV cert. It was whatever their level above the first level is (can't recall, it's been a while, but it wasn't for EV)

From their policy:

> Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only.

AFAIK simply taking donations counts as "commercial purpose". You are free to dislike their policy though.

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?

I think they just care whether or not you're making money with the site period. As in, money that could potentially go towards a paid certificate.

> 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...

RapidSSL does it too.

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.

A vulnerability of this level is inexcusable. StartSSL ought to be removed from all major browsers.

Agreed. The more I hear about StartSSL the more I want to run away.

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.

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/")

StartSSL only allows validation for top level domains. So you can't get a cert for me.blogspot.com unless you own blogspot.com.

I think you entirely missed his point.

What about blogspot.co.uk? Do you need to own that, or co.uk to get a cert?

What counts as a "top level domain" is, as Animats said, complicated.

Oh ok. I can't attest to how this is handled because I have never attempted to get a cert for a domain like this.

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.

[2] A great talk by moxie, filled with horror examples of CAs. The private key example is at 19:20. https://www.youtube.com/watch?v=Z7Wl2FW2TcA

Certificate Transparency with mandatory SCT delivery (as with EV certificates) will largely solve¹ the issue of fraudulent or compromised CAs.

¹ As long as you're monitoring CT log servers for anything involving domains you own.

Obligatory reference to my CT monitoring service:

https://ctadvisor.lolware.net/

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.

That seems appropriate. Google forced Symantec to do the same thing because of a number of misissued certificates[1].

[1]: https://security.googleblog.com/2015/10/sustaining-digital-c...

I'm guessing Sleevi is already dusting off his keyboard to write them a similar note.

This seems to an incredibly basic error for a company trusted to issue SSL certificates.

How long has this vulnerability existed? Can we trust any StartSSL certificates? Will they charge for revocation, as they did with Heartbleed?

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).

If this is genuine then it is absolutely inexcusable - this isn't some complex attack, that is web 101 stuff.

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.

They did the same thing to me!

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.

Awful customer service at StartSSL.

I had the same problem. They did not even sign the certificate after I changed the WHOIS record and yet they kept the money.

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.

Just to play devil's advocate, maintaining a CRL is quite expensive. Cloudflare detailed those costs here: https://blog.cloudflare.com/the-hard-costs-of-heartbleed/

Let's Encrypt avoided this by partnering with Akamai. Though StartCom really should have made an exception for Heartbleed.

> there's no reason to do business with these greedy losers

What makes them greedy? That they are charging for what they do? (Serious question I am curious why you label them "greedy" and further "losers").

https://www.startssl.com/Support?v=43

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?

It has been fixed according to the article:

> 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.

This post needs to be higher up in the thread, and not people overreacting and demanding having them removed from browser's CA-stores etc.

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.

    a CVE

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.

Could the hotmail address have been allowed because it's listed on his domain name's WHOIS?

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.

check this: https://www.startssl.com/NewsDetails?date=20160322

Yep, this was just a false alarm. Guy should update his blog to say he was mistaken.

Good to know StartSSL is just as shoddy as it's always looked. Good thing we have letsencrypt these days.

Yeah, I'm happy I moved all of my domains off them after they tried to nickel and dime me to death.

It's interesting to me that so many people strongly dislike StartSSL that they won't even use their product for free.

That really goes to show how bad their service is.

Did you remove StartSSL from your browser SSL CAs database?

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.

[0] https://news.ycombinator.com/item?id=11321184

It looks more like a confused report, as the email address used to verify the ownership was indeed listed as a legit contact in the whois database...

https://www.startssl.com/NewsDetails?date=20160322

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.

It's my understanding that pinning limits the damage of this sort of attack on those "big" sites.

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.

Yes, exactly. Thank you, I wasn't as clear as I could have been.

Frankly, I could have thought a bit more deeply before responding. Your meaning seems clear to me now.

Interestingly, this blog author hasn't activated HTTPS for his own blog yet, which can be done with a single click on the Blogger settings page.

Why is that interesting?

Maybe irritating would be a better word. Or irritating that this is considered normal.

The laid out attack cannot be used to attack the blog, because the blog is already so insecure.

What would HTTPS gain you or the blogger?

I have literally no idea who oalmanna is, so a third-party saying oalmanna is oalmanna would be completely useless for me.

I suppose it would keep a third party from knowing I read this blog, but I can't find a reason to care about that.

Well with the shit some carriers pull, from injecting personally identifiable information in HTTP headers (http://www.techrepublic.com/blog/it-security/why-are-website...) or code injection in the website content (http://www.infoworld.com/article/2925839/net-neutrality/code...), I sure benefit from an HTTPS connection everywhere...

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.

https://citizenlab.org/2015/04/chinas-great-cannon/

> this blog author hasn't activated HTTPS for his own blog yet,

Who the heck cares about HTTPS for a fucking blog?

and this news:https://www.startssl.com/NewsDetails?date=20160323 StartCom log all issued SSL certificates to public CT log servers

Reply on news.ycombinator.com