Certificate Transparency: Hacking web applications before they are installed

The certificates used for HTTPS are saved in public logs with Certificate Transparency. This leads to better security in the TLS ecosystem, but it brings surprising risks for web applications like Wordpress.

Dieser Text ist auch auf deutsch verfügbar.

Certificate Transparency is a system developed by Google that has become a crucial part of the TLS ecosystem. Certificates are stored in public and cryptographically verifiable logs where everyone can see and analyze them. That has helped to uncover security incidents like the one where Symantec issued illegitimate certificates multiple times.

But Certificate Transparency has consequences that haven't been fully considered yet. Certificates contain information that is valuable for many reasons. And that information is also available to attackers.

No more secret host names

A certificate usually contains a host name. Therefore certificates reveal domains and subdomains. One can use the Certificate Transparency search engine crt.sh to search for subdomains belonging to a domain. This can be used to find all subdomains used by a company in order to search for security vulnerabilities.

This means that most subdomains aren't secret any more - with the exception of wildcard certificates and certificates that use the controversial redaction labels for Certificate Transparency.

To run internal services under a "secret" subdomain was a bad idea all time time, as subdomains can always be revealed by observing traffic. But Certificate Transparency makes this more obvious.

Some certificate authorities already submit all certificates automatically to public logs. Symantec was forced to do that by Google after a security incident in 2015. So-called Extended Validation certificates have to be submitted to logs. The certificate authority Let's Encrypt and the CDN company Cloudflare submit all certificates to logs voluntarily.

But even certificates that aren't logged by their certificate authority or hoster usually end up in the logs quickly, because Google's search engine crawler automatically submits all certificates of sites it finds.

Soon all certificates will be logged. The Chrome developers had announced that they would require logging of all certificates in September, but the deadline has been moved to April 2018. But in practice most certificates are already logged.

For self-hosted web applications like Wordpress, Joomla, Nextcloud and others Certificate Transparency can become a problem. The installation of web applications usually works this way: A user uploads the PHP code on a web server and runs the installer afterwards via the web page. Settings like the database credentials and an initial administration account are configured.

The risk here: This Installation usually comes without any form of authentication. If an attacker finds such an uninstalled web application he can usually trivially gain code execution on the server.

Until now, unprotected installers weren't a big problem because attackers would have to know the exact moment when a webmaster installs the application. Problematic were mainly abandoned installers that sometimes could be found via a Google search.

But Certificate Transparency changes this. It gives attackers a feed of new hostnames that have just been created. Many web hosters support HTTPS by default these days and automatically create new certificates for new hostnames.

Uploading a Backdoor with a Plugin

An attacker can now observe the Certificate Transparency logs and check all the webpages corresponding to the certificates. These pages get compared to installation routines from common web applications. With some luck the attacker hits the right moment between uploading of the files and the installation.

For example, if an attacker finds an installer of Wordpress then he can directly take over that installation. First he installs the applications himself. The attacker usually will need credentials for a MySQL-database, but he can simply use one from a free MySQL hosting service. After the installation executing of code is no problem. Usually this works by installing a plugin. An attacker could upload a plugin that contains a PHP shell.

After that, the attacker can revert the installation. This usually simply requires to delete the configuration files that have been created by the installation. If all of this happens quickly - and it can be automated - the owner of the web application doesn't notice anything, as the installer is available again after the attack.

The attacker now has a backdoor which he can use to execute code. This can be abused for all kinds of things, for example to send spam or host phishing web pages on the web server.

5,000 Wordpress installations in three months

The author of this text ran a test script that observes transparency logs and checks the corresponding web pages for installers for three months. The last step of the attack, the takeover of the applications, was obviously skipped.

The most common installer that was found came from Wordpress. Around 5,000 Wordpress installations could've been taken over. Also about 500 Joomla installations and 120 Nextcloud installations could've been attacked. Other web applications were only found in low numbers.

Such an attack could be optimized further. The script checked each host only once. But an attacker could also check all new certificate host names regularly for several days. Also the test script had a short timeout, which caused it to not find many Drupal installations, because their installer was relatively slow in answering.

Installers without Authentication are a risk

To protect against such attacks, web applications should authenticate the user as part of the installation routine. There are different options for that, an installer could for example create a file with a secret token and ask the user to download it and paste the password into a form. But many web applications are reluctant to add an additional authentication step, as they want to keep the installer as simple as possible.

It is noteworthy that some applications are not vulnerable to such an attack because their installation mechanism works differently. One example is Mediawiki, the software used by Wikipedia. The installer from Mediawiki creates a configuration file. But this isn't installed directly, ithas to be be downloaded by the user and then uploaded into the web directory.

However, the Mediawiki installer allows the use of SQLite. The installer creates the SQLite database file. Therefore an attacker who finds a Mediawiki installer can create SQLite files on the filesystem. But it is unlikely that this can be exploited.

The author of this text has reported this issue to various important developers of web applications several months ago. The reactions were limited. The developers of Typo3, Drupal and Owncloud didn't answer at all. Wordpress and Nextcloud showed interest in a discussion, but nothing has been changed until now.

Only Joomla has changed its installation mechanism. The Joomla installer now has an extra authentication step, but only if the MySQL database is stored on an external server. In this case the user has to remove a directory that gets created by the installer with a random name in order to continue the installation.

The idea here is that an attacker usually has no database credentials for the local MySQL server. But this solution isn't totally secure. An attacker could already have credentials for several servers from popular web hosting providers and with some luck hit a vulnerable Joomla installer on one of those servers.

A combination is also possible: An attacker uses this attack against various web applications. If he can attack one application that is still vulnerable then he can steal the database credentials from that application and use it to attack Joomla installations on the same server later.

Protection as a user is nontrivial

It is not always easy for a user to protect himself against such a scenario. On Apache web servers it's possible to upload an htaccess file that will provide password protection. However, many web applications use htaccess files themselve. Thus it is possible that these interfer with each other. This can be avoided by uploading the htaccess file into the upper directory of the web root. But this is only possible if a web hoster allows access to that upper directory.

It is also possible to install the application on a local test server first and then upload it to the real server. But this requires a lot of effort.

In theory one could also try to just finish the installation very quickly. Usually it takes around half an hour until certificates are public. But that's not reliable and of course it's possible that future certificate logs will simply operate faster.

No signs of attacks

The question remains whether attackers already know about this possiblity and use it. The author has set up various random subdomains with Let's Encrypt certificates.

Apart from the access of the test scripts there were only accesses by Netcraft, a company creating statistics about the web. Netcraft seems to use Certificate Transparency logs for this.

Access attempts that indicate an attack weren't in the logs. However, this could change soon. It is hardly justifiable that the majority of web applications don't protect users against such attacks.

The author of this text has presented this attack at the Def Con conference in Las Vegas.