Hall of old abandoned aircraft — Photo by Matheus Bertelli on Pexels.com

On Thursday, Friday 16th at 16:00 UTC Joomla released version 4.2.8 with a major security fix. The vulnerability, they warned, was a very serious one and you would all need to update. However, the necessary information gap which follows a security release —so as not to tip off miscreants— has let rumours spread in such a way that they make people risk unnecessary damage to their site, or at least give the false impression that all Joomla sites have been “magically” hacked like we're in some Hollywood movie. That's not how the world works, so please let us explain exactly what is going on and you should not freak out.

Discovering the nature of the vulnerability

As I said above, the Joomla project decided to do exactly what every organisation pushing out a patch for a major vulnerability does: would not provide any information on the vulnerability fixed for weeks after the security fix so as not to tip the hand of any attacker.

However, this particular vulnerability is very serious, very straightforward, it has a trivial two line patch which was made publicly available at the same time as the security patch.

I would urge the Joomla Security Strike Team to not stick to an inflexible doctrine of delayed information sharing in situations like this. I would argue that forewarning the community is the better strategy, especially when you can simultaneously provide mitigation information for something attackers will figure out within minutes of the security release — a security release announced days in advance, getting the attention of literally everybody, be it a 3PD writing security software like us, site integrators anxious to protect their sites, or attackers eager to exploit sites.

Mitigation

The recommended course of action to mitigate this attack is, of course, to install the Joomla 4.2.8 update.

If you are on an older Joomla version family, e.g. 4.0 or 4.1, and cannot update for any number of reasons you can do one of three things.

Option A: Modify the libraries/src/Router/ApiRouter.php file

Find the line

$query = Uri::getInstance()->getQuery(true);

Add the following code below it:

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

This effectively applies the security patch from Joomla 4.2.8 and “inoculates” your site against the vulnerability.

Option B: .htaccess code

Assuming that you are using Apache or LiteSpeed as your web server, you can add the following code to your .htaccess file, right below the RewriteRule line:

RewriteCond %{QUERY_STRING} public=
RewriteRule api/?. - [F]

These two lines will block any request to Joomla's API application which would trigger the vulnerability.

Option C: disabling the Joomla API

Unpublish all plugins in the webservices group. Do remember that by doing this you are disallowing all access, legitimate or not, to the Joomla JSON API which can and will break things in the future. This is only meant as a temporary solution.

To do that, go to your site's administrator backend and click on System, Manage, Plugins.

In the Plugins page click on Filter Options above the list.

From the “- Select Type -” dropdown choose the webservices option.

Select all items (use the checkbox at the top row of the list) and click on Disable.

Which Joomla version are affected?

Joomla 4.0.0-Beta2 up to and including Joomla 4.2.7.

Older versions of Joomla are not affected as they did not have the API application.

Newer versions of Joomla are not affected because the vulnerability has been addressed there.

Have I been hacked?

Apparently, releasing a security fix for a vulnerability that scores 10 out of 10 in the WASP scale (I would rate it a 9, as 10 is meant to be used for direct arbitrary code execution, but whatever) is like shouting “FIRE!” in a crowded theatre.

It caused a stampede.

People filled the information void with hearsay, wild conjectures, and —not to put too fine a point on it— utter rubbish. The number of people I have seen changing their database and email passwords in sheer panic is stupefying. However, I would argue that the vast majority, if not totality, of these people have not been hacked and need not do anything as drastic.

If you want to be sure you have not been hacked download your raw access log and look for the following regular expression:

api/(.*)(\?|&)public=

You can download your raw access log in cPanel through the Raw Access menu item. This downloads a .gz file which needs to be extracted first e.g. using 7-Zip.

If you are on a Linux, macOS, or *BSD system and you're handy with the command line you can scan the entire compressed file for signs of an attack like so:

gzcat akeeba.com-ssl_log-Feb-2023.gz|  grep -E -e "api/(.*)(\?|&)public=

If you get no hits you're golden. If you only get hits with a 403 status code like this below you're also golden:

192.168.1.1 - - [17/Feb/2023:09:17:18 +0200] "GET /api/index.php/v1/content/articles?public=1 HTTP/2.0" 403 66 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0"

The line above was me verifying the fix works.

You should only worry if you receive hits like this:

192.168.1.1 - - [17/Feb/2023:06:17:42 +0200] "GET /api/index.php/v1/content/articles?public=true HTTP/2.0" 200 583 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"

Note that the date (the first bold part between brackets) must be BEFORE the date and time you applied the mitigation AND the status code (the second bold part) must be 200. If you have hits like that then yes, you have been hacked.

What should I do if I have not been hacked?

Make sure you have a mitigation in place.

To check your mitigation try accessing the URL https://www.example.com/api/index.php/v1/content/articles?public=1 in your browser, where https://www.example.com is the URL to your own site. If you get a Forbidden message or an error message your site is safe.

What should I do if I have been hacked?

The URLs in your access log file tell you which information the hackers have accessed.

At the very least you should change all passwords present in your configuration.php file such as your database password, mail server password etc.

You should also change your site's secrets. The easiest way to do that is take a backup of your site with Akeeba Backup (the free version will do just fine) and restore it again back on your site; this always changes your site's secrets.

If you have evidence that the attacker accessed your user's information you need to notify your users that a data breach has occurred and an unknown attacker has the name, email address (plus whatever other information you collect), and a hashed version of their password. Depending on your jurisdiction you may need to disclose the data breach to your local authorities, e.g. your country's Data Protection Office if you in the EU.

Do I need to change my database and email password?

Not unless you have POSITIVE confirmation that your site has been hacked.

If you are not absolutely certain that you can check for that, despite the information above, you can always change your database and email password. Do keep in mind that by doing so you may break your site so please do take a backup. Akeeba Backup Core is free of charge and can save your neck if things go pear-shaped.

Isn't Joomla insecure?

NO!

Just because there is a serious vulnerability found and fixed doesn't mean that the software is insecure. This kind of major vulnerabilities have been found in the last decade in WordPress, Drupal, Typo3, Microsoft Windows, Apple macOS/iOS/iPadOS/tvOS/watchOS, Google Chrome OS, Android, and Linux. Vulnerabilities are bugs, and bugs are a fact of life.

If you want to be unexposed to software vulnerabilities you have to live completely off the grid, as a luddite, in a cave.

Should I disable the Joomla API altogether?

No, please don't!

The API is a very useful feature in Joomla 4.

Disabling it will eventually break useful features in the core and third party applications.

I know many of the people reading this will not listen to me and disable it anyway. I know the same people will moan, groan, and complain about something not working at a later point in time because they disabled the API application. Look, people. If you sabotage your site it will come to bit you in the posterior. If it happens, undo your changes.

Eventually, the Joomla project will change how the API applications work. Right now, the API is only accessible if you authenticate as a Super User and the assumption was made that if you're authenticated you must be a Super User, therefore you can see everything. This was supposed to be a conservative approach, but it also enabled this vulnerability to have a big impact. In the future, the core API components will be modified to have finer grained control over what information they display and allow changing, checking the actual permissions of the authenticated user. This means that even if somehow in the future such an authentication bypass were to happen again, the attacker would have Guest user permissions, therefore they would only be able to see what they can already see in the public HTML site, making it a non-issue.

You see, the solution to finding a problem is not nuking the entire useful thing which sprang a leak from high orbit. It's working on the darned thing to make it resilient and secure. This is a universal truth in security, be it IT security or physical security. Let me put it a different way. If you found out that your door's lock can be bumped and overridden would you remove the door and replace it with a brick wall, or would you invest in a better, more secure lock? Disabling the API application is the computer equivalent of replacing your front door with a brick wall; congratulations, you've buried yourself in a tomb of your own making.

Bonus question: does this affect Akeeba Backup Professional's API? Do I need to regenerate its secret word?

No. Akeeba Backup Professional's JSON API does not use the Joomla API application. We implement our own thing which is not affected by the vulnerability in Joomla 4's API application. You do not need to regenerate your secret word.

3 comments