31 May 2022
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.
BROUGHT TO YOU BY OUR SPONSOR
Architecture
for Machine Identity Management.
What will your PKI look like when fast application development triggers an explosion of new machine identities?
Read this reference architecture to learn new strategies for orchestrating machine identities in data center,
cloud and edge environments. 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 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.
This subscription is just for the newsletter; we won't send you anything else.
Here are some things that caught our attention since the previous newsletter:
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.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.