Security tool enables attackers to obtain SSL certificates for domains they don't own

Computest accuses StartCom of paying "too little attention to security" in design and implementation

A flaw in the implementation of a free security tool enables attackers to obtain SSL certificates for domains they do not own.

That is according to Thijs Alkemade, a consultant with Dutch security specialist Computest, which claims that StartCom's StartEncrypt tool contains critical security flaws.

"While there are some restrictions on what domains the attack can be applied to, domains where the attack will work include google.com, facebook.com, live.com, dropbox.com and others," it warns.

"StartCom, known for its CA [certificate authority] service under the name of StartSSL, has recently released the StartEncrypt tool. Modelled after LetsEncrypt, this service allows for the easy and free installation of SSL certificates on servers.

"[But] there is a lot that can go wrong with the automated issuance of SSL certificates. Before someone is issued a certificate for their domain, say computest.nl, the CA needs to check that the request is done by someone who is actually in control of the domain.

"For 'extended validation' certificates this involves a lot of paperwork and manual checking, but for simple, so-called 'domain-validated' certificates, often an automated check is used by sending an email to the domain or asking the user to upload a file.

"The CA has a lot of freedom in how the check is performed, but ultimately, the requester is provided with a certificate that provides the same security no matter which CA issued it."

In order to make the issuance of certificates easy, the tool runs on the server, detects the web server's configuration and requests domain-validated certificates for the domains in the configuration files.

"Then, the StartCom API does an HTTP request to the website at the domain you requested a certificate for, and checks for the presence of a piece of proof that you have access to that website. If the proof is found, the API returns a certificate to the client, which then installs it in your config'," it continues.

However, a security flaw in the client can enable an attacker to "trick" the validation step. "The API checks if a user is authorised to obtain a certificate for a domain by downloading a signature from that domain, by default from the path "/signfile". However, the client chooses that path during an HTTP POST request to that API.

"A malicious client can specify a path to any file on the server for which a certificate is requested. This means that, for example, anyone can obtain a certificate for sites such as dropbox.com and github.com where users can upload their own files.

"While this is serious, most websites do not allow you to upload a file and then have it presented back to you in raw format like GitHub and Dropbox do. Another issue in the API, however, allows for much wider exploitation of this issue: the API follows redirects. So if the URL specified in the 'verifyRes' parameter returns a redirect to another URL, the API will follow that until it gets to the proof. Even if the redirect goes off-domain. Since the first redirect was to the domain that is being verified, the API considers the proof correct even if it is redirected to a different website," claims Alkemade.

This means that an attacker can obtain an SSL certificate for any website that either allows users to upload files and serves them back raw, or has an "open redirect" vulnerability in it.

The researcher claims to have discovered a number of other security vulnerabilities, found on 22 June, but which StartCom claims to have fixed by the end of that month.

"StartCom made a mistake by publishing StartEncrypt the way it is. Although they appreciated the issues for the impact they had and were swift in their response, it is apparent that too little attention was paid to security both in design (allowing the user to specify the path) and implementation (for instance in following redirects, static linking against a vulnerable library, and so on). Furthermore, they didn't learn from the issues LetsEncrypt faced when in beta," conclude the researchers.