Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Maintained by Hanno Böck.

Recently in the community forums of WordPress and Let's Encrypt, reports have shown up about webshells on freshly installed WordPress blogs that were later used for DDoS attacks. These attacks were also covered in an article at the Daily Swig.

The attack scenario in these reports was quite familiar to me. I realized this was a possibility early on when Certificate Transparency was introduced. I presented the attack in a talk at the DEF CON conference in 2017 and also covered it in an article back then. Independently, H. D. Moore also described this attack around the same time at the BSides Las Vegas conference.

Most of you will be familiar with Certificate Transparency, which is a system of public logs of certificates. Since 2018, Google Chrome requires all publicly trusted web certificates to be logged.

Certificate Transparency has largely been hailed as a major security improvement of the TLS ecosystem. It allows website owners to spot potential malicious certificates and researchers to look for certificates violating security policies. Countless incidents where certificate authorities have breached existing security policies have been uncovered with the help of Certificate Transparency.

But Certificate Transparency also introduced a data source that can be abused by attackers. Because certificates contain host names, by monitoring the logs a person can get a stream of host names for freshly issued certificates.

This is what attackers are abusing against WordPress installations now. A common way of installing PHP applications is that you first upload the application to a web host and then access a web installer. WordPress is not the only application with such an installer, but it is the most popular one.

These installers usually come without any authentication. Whoever accesses a web host with a WordPress installer can finish the installation. The idea here is that an installation will usually be performed quickly and thus it should pose little risk. But this is no longer true in the modern web ecosystem.

A very common situation is that a user will first configure a web host with a certificate, often using automated tools like Certbot, and then start the installation of a web application like WordPress. The certificate will show up shortly after in one of the public Certificate Transparency logs; this process takes only a few minutes.

If an attacker monitors newly issued certificate hosts for unprotected WordPress installers, it is very likely that the attacker will spot the WordPress installation before the user finishes it. By automating this process, an attacker can install WordPress first. With an administrator account, it is easy to upload malicious code via the WordPress plug-in mechanism. To hide traces, the attacker can then revert the installation process while leaving a webshell that can be used by the attacker in the future. The user will continue with the WordPress installation but will not notice that anything malicious happened.

Back in 2017, I contacted the developers of WordPress and several other affected PHP applications. I recommended that installers need an additional authentication step to protect against this attack. The installer could, for example, ask the user to upload a file to the host with a random token generated by the installer session to proceed.

Most web application projects I contacted did not implement such an authentication. The only application that implemented a protection against this scenario is Joomla. When using an external MySQL host, it introduces an additional authentication step. This is not perfect protection, as an attacker may be able to have access to the same database host—for example, in shared hosting environments. But it should at least prevent most automated attacks. WordPress is still vulnerable with the latest version, 6.0.

Short news

Here are some things that caught our attention since the previous newsletter:

• A research paper published at NDSS discusses whether there could be a system for client certificates akin to Let’s Encrypt, which they call Let’s Authenticate.
• Researchers have published an analysis of the security of TLS connections in IoT devices at the Internet Measurement Conference (IMC). They explain their results in a blog post at APNIC.
• NSS released version 3.78, including some bug fixes regarding TLS 1.3 length checks.
• Google Chrome had deprecated some Certificate Transparency logs that were still in use in active certificates, causing a temporary rollback of the deprecation. Andrew Ayer explains the issue on Twitter.
• OpenSSL published a security advisory, fixing two medium-severity vulnerabilities, one regarding the c_rehash script and the other related to OCSP verification.
• A research team has published attacks on the OpenPGP private key storage format. While the threat model is somewhat unusual, the underlying issue—like for previous vulnerabilities in the PGP ecosystem, such as efail—is the lack of authenticated encryption.
• A signature validation flaw was found in ecdsautils, a set of tools used by the Freifunk open Wi-Fi community in its updater. The flaw is almost identical to the ECDSA flaw recently found in Java, which we covered in our April Newsletter.
• Michael Driscoll created a web page visually explaining the X25519 key exchange.
• The European Commission proposed a controversial regulation that would undermine end-to-end encrypted communication. The German IT politics site netzpolitik.org has a detailed article in English. Eric Rescorla also discusses the details in a blog post.
• Microsoft announced DANE verification support for outbound SMTP.
• Google Project Zero released a technical report analyzing the security of the AMD Security Processor, including descriptions of some cryptographic flaws, such as invalid curve attacks.
• Changes in Chrome on Android regarding Certificate Transparency make it more difficult to intercept TLS traffic on rooted devices, as the HTTP Toolkit blog explains.
• GnuTLS released version 3.7.5, with some changes regarding the handling of session tickets.
• Mozilla explains policy changes regarding the use of revocation reason codes in OCSP.
• A blog post by Chris Siebenmann points out the difficult-to-debug problems that can arise with missing intermediate certificates.
• Bruce Morton explains changes in the CA/Browser forum rules regarding code signing certificates.
• In a detailed blog post, Let’s Encrypt describes the database technology behind its Oak Certificate Transparency log.
• Soatok discusses different elliptic curve signature algorithms and the reasons for choosing certain curves.
• Google announced PSP, a protocol allowing cryptographic hardware offloading that Google uses for datacenter traffic.
• Theo von Arx and Kenneth Paterson have published a paper analyzing security flaws in software implementing the Telegram protocol.
• A group of researchers has published TCPLS, a protocol to more tightly integrate TCP and TLS. A blog post at APNIC explains more details, and a draft is also available.
• Jason Donenfeld continues to make major changes to the Linux Kernel’s random number generator. He also started a discussion about the so-called premature next threat model. The discussion led to the conclusion that this is an unlikely scenario and the countermeasures may introduce more problems than they solve. Subsequently, Donenfeld has removed the countermeasures.
• Bruce Morton writes about the deprecation of SHA1 in timestamp authorities.

Interesting jobs

Here are some interesting jobs we've come across in the last month:

If you know of similar jobs that our readers might be interested in, for example cryptography, TLS, or PKI, let us know and we may add them to future newsletters.