Last week the Joomla! Project released Joomla! 3.7.4, a release that included 2 security fixes, one of them rated as a "high severity" issue related to the installer application of the CMS. In the initial bulletin published in the Security Centre, no further details on the actual attack vector have been disclosed - but as the vector has now been disclosed by the initial reporter Hanno Böck in a talk at the Def Con conference, I would like to share some insights from the perspective of the Security Team.

The good old days

So far, installing a web-based application like Joomla! has been a more or less straightforward process: upload the files to your web server, fire up the installer application in your browser by calling the right URL, enter your database credentials and other configuration details and you are ready to go. During that process, no "proof of ownership" for that web server was necessary, no authentication happened – and this was perfectly fine so far, because any attacker needed two key pieces of information:

1. The attacker needs to know when the application is completely uploaded but not yet installed - normally, the application won't be in that state for longer than just a couple of minutes, which makes it even harder
2. The attacker needs to know the exact location (URL) of the web application in order to run the installer

If an attacker would be able to get those two pieces of information, an exploit is a rather easy thing:

1. Run the installer using an external database that's under your control because you won't be able to brute force working database credentials on the victim's web server
2. Use the installed application to upload a backdoor (for Joomla! this could be easily done with a malicious extension package uploaded in the backend)
3. Use your backdoor to reset the application (i.e. by removing the configuration.php and restoring the installation folder of Joomla) to make the victim think that nothing bad has happened.

These steps can happen in less than a minute if automated by a script - however, this has been a purely theoretical problem, because there simply was no way for attacker to gain the critical pieces of information (when and where). Because of this, almost no major web application has implemented a verification process and this was perfectly fine so far.

Dark clouds on the horizon

Unfortunately, a new protocol used to improve the security of the web changes this status quo as it works as new source of information. The protocol, called Certificate Transparency (CT) is a real-time log of all SSL certificates issued by a certificate authority (CA). The basic idea behind the protocol is to detect the issuing of rogue SSL certificates, which would improve the general security on this very crucial part of the web.

However, if we think about the protocol, it has a side effect: imagine you want to build a new site using Joomla. You open your favourite web host's site, purchase a new hosting account and register a domain - and as it's 2017 and we have awesome services like LetsEncrypt, you'll get a free SSL certificate for this new domain that's enabled by default. A couple of minutes later your domain is ready to go and you upload your Joomla! - and boom, you are hacked! Why? Because your web host got a SSL certificate for your new domain automatically and because of the CT protocol, this new certificate (including your domain name) got shared with the rest of the world instantly. An attacker that monitored the CT stream found your domain and started to probe it every few seconds until you finally uploaded the Joomla! files - and once that happened, the attacker executed the exploit mentioned above.

Keeping the balance

This attack vector is a great example of the conflict between security and usability that we, as a security team, are facing on a regular base. Improving the installer's security would require an additional "proof of ownership" step that asks the user to remove a file generated by installer. This additional step might be challenging especially for unexperienced users and affects the usability negatively. So, at the end of the day we often ask ourselves: is this attack vector a plausible real-world scenario that justifies the negative usability impact, or is this a theoretical problem?

With Certificate Transparency, a theoretical threat became a real world issue and required a solution that was implemented by the security team right away. We shared our solution with the initial reporter (and other CMS') and chose a release date that was as close to the Def Con talk (which publicly disclosed the vector) as possible.
So far, Joomla! is the one and only major web application that adjusted its installer to this new threat - and all of this is brought to you by a small team of volunteers working behind the scenes of Joomla, constantly fighting for the optimal balance, keeping the CMS safe.

The Joomla! Security Strike Team.