About three weeks ago, Joomla fixed a vulnerability in the Joomla content management system, patching a trivial to exploit access control vulnerability. The vulnerability allowed access to the Joomla username/password database.

The patch deployed to mitigate the issue tells us a bit about what happened:

ApiRouter.php:
// Remove the public key as it is only supported coming from the route definition
if (array_key_exists('public', $query)) {
    unset($query['public']);
}

Later the "public" parameter would have been used to bypass authentication:

ApiApplication.php
if (!isset($route['vars']['public']) || $route['vars']['public'] === false) {
   if (!$this->login(['username' => ''], ['silent' => true, 'action' => 'core.login.api'])) {
        throw new AuthenticationFailed();
   }
}

A typical URL used to probe the vulnerability is:

/api/index.php/v1/config/application?public=true

This URL, if vulnerable, returns database configuration data, including the username and password. Exploits for this vulnerability were made public pretty much the day the vulnerability became public.

In line with the availability of a simple exploit, we also saw the exploitation of the vulnerability in our honeypots. But these last couple of days, one source IP, in particular, started to scan for this vulnerability rather aggressively:

(see the data here)

The attacker, 95.214.27.107 appears to be scanning exclusively for this vulnerability and has had no reports in our database before the last two days. It does not appear to be associated with a known research group or botnet. The website returned by the attacking system is a default Plesk page, which may indicate a compromised, unmaintained system. It has now, however, been added to a few different blocklists.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|