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.
BROUGHT TO YOU BY OUR SPONSOR
Application Security Across Top 1 Million Sites
Curious about the state of application security across the top 1 million web sites? Read this report for cybersecurity analysis outlining trends in HTTPS, Certificate Authority, Permissions Policy and more. VENAFI
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
