StartSSL allows attackers obtain SSL certificates for domains they do not own
Thijs Alkemade, a security researcher for Dutch security firm CompuTest, has discovered several design and implementation flaws in StartEncrypt, a tool designed by Israeli company StartCom for giving out free SSL certificates.
The StartEncrypt project was launched by StartCom, the CA (Certificate Authority) behind the StartSSL service on June 4, which was motivated by the success of the Let’s Encrypt project.
Users who want to use free StartSSL certificates can take advantage of their StartEncrypt offering. They only need to download a Linux client that they are required to upload to their servers.
This client carries out a domain validation process, notifies the StartSSL service, which then distributes and installs an “Extended Validation” SSL certificate for the domain it has found running on the server it has just checked.
StartEncrypt comprises of design and implementation faults
This validation process is defective, and through a few wiles, it allows server owners to receive SSL certificates issued for other domains, such as Google, Facebook, Dropbox, etc., which can be sold on the black market or used in man-in-the-middle attacks, according to CompuTest.
Alkemade discovered the first issue in the StartEncrypt client, which was a design-related problem connected to the fact that users could manually organize the folder from where the client would download a signature from the server.
Holding the signature of another domain, an attacker would only have to direct the tool to a folder on their server. These domain signatures can be removed from any sites that let the users to upload files: GitHub, Dropbox, etc.
StartEncrypt bug joined with OAuth 2.0 protocol condition
The second problem is far graver because it permitted an attacker to get SSL certificates for even more domains than the ones before.
One of the API verification calls comprises of a parameter nicknamed “verifyRes,” which takes a URL as input, according to the researcher. This means the client was exposed to Open Redirect susceptibilities. In other words, an attacker could fake this request and direct the tool off-domain to a server not under their control.
However, this feature is not that simply usable. The domain URL to which the attacker needs to point the tool must (1) let the users to upload files and serve them back in raw format; or (2) to have an Open Redirect concern of its own.
While the first condition was quite uncommon, the second was not. All websites that support OAuth 2.0, a specification that controls social login features, must let open redirects for the protocol to function in the right way.
An attacker leveraging this OAuth 2.0 condition and the StartEncrypt client could trick the StartSSL service into giving out a free SSL service in their name for any site that offers OAuth 2.0 support, such as Facebook, Yahoo, Microsoft, Twitter, and so on.
Several other issues discovered as well
In addition, CompuTest also determined that StartEncrypt when connecting to the API doesn’t check its own server’s certificate for validity. This means that attackers could get verification requests and give out false SSL certificates for users trying to use StartEncrypt.
The API also doesn’t verify the content type of the file it downloads for confirmation, so attackers can get certificates in the name of third-party websites where users can upload their avatars. Simultaneously, the certificate private key, which must be private, is kept with 0666 permissions in a public folder, so everyone could read it.
Moreover, StartEncrypt is vulnerable to a Duplicate-Signature Key Selection attack just like Let’s Encrypt.
“In our opinion, StartCom made a mistake by publishing StartEncrypt the way it is,” CompuTest’s Christiaan Ottow explains. “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.”
StartCom has released a new version of the StartEncrypt Linux client, with the same version number 220.127.116.11. CompuTest says they reported other problems to the service, which are still being rectified and will be fixed in future updates.
StartSSL faced a similar issue with its general service back in March, which also permitted attackers to receive SSL certificates for domains they did not own.