This blog is focused on Latest Joomla Exploit. Working as a Security Consultant, more often than not, you come across vulnerabilities that are peculiar & at the same time important to be fixed soon. Something of the sort recently happened with me, while looking for new Joomla exploit and attacks in Joomla Security.
I came across a vulnerability in Joomla that would give privileges to non-superusers making it possible for malicious actors to exploit Joomla.
But before we go ahead to that, let’s first talk a little about Joomla and what it is.
Joomla is the third most-used free open-source Content Management System (CMS) after WordPress and Shopify. It is used to build websites & publish web content. Its user-friendly format has made it highly popular among the masses. Joomla uses object-oriented programming techniques along with software design patterns and written in PHP. It stores its data in the MySQL database.
Joomla maintains an ACL (Access Control List) to control:
Recently published Joomla security advisory disclosed a vulnerability that caused the ACL violation in the Joomla versions from 1.7.0 to 3.9.22. A security patch has released to fix the same under the latest version 3.9.23. Since Joomla is an open-source CMS making it possible for us to spot the differences in the vulnerable and patched versions of the code using Github’s comparing releases feature.
Vulnerable Version: 3.9.22
Patched Version: 3.9.23
We can find the difference between the code of both the versions of Joomla using Github’s compare tags feature. If you check this link, you will notice that the latest version of the Joomla CMS has 213 modified files from the last version. While closely scrutinizing the code from the modified files, a new function validate that was introduced by the Joomla developers in the core parts of the Joomla CMS.
validate function checks the following things:
On line 371, it checks whether the logged-in user is a super-user or not. The code
JFactory::getUser()->authorise('core.admin', $data['extension']) returns a boolean i.e. true or false which leads to the following two cases:
truecase: If the logged-in user is a super-user, then this code returns true and the code jumps to line 379 which further validates the supplied form data and returns an array of filtered data if valid, or false otherwise.
falsecase: If the logged-in user is not a super-user, then this code returns false and the code jumps to line 373 which checks whether the user has supplied any ACL ruleset while submitting the form. If the ACL ruleset has been supplied then it just removes that ACL ruleset and executes the parent’s
validatefunction to filter the valid data from the form.
Now the question arrives, what is the need to `unset` the ACL ruleset? Does it even matter?
You can read the complete code on category.php.
While I was reading this code, I noticed that the function at Line 505 is responsible to save the category form. It can be noticed that at Line 567, the code checks whether the user has supplied any ACL ruleset. If the ACL ruleset has been supplied, then it sets the new ACL ruleset.
Now, we know that the
save function sets any supplied ACL ruleset in the submitted form. As the vulnerable version of code is not using the above-discussed validate function to validate the form data, it will mean that even a non-super user can also submit the form with any ACL ruleset and that ACL ruleset will be processed by Joomla.
For a simple attack scenario, let’s create three users with different privileges, e.g. super-user, manager and administrator.
As this vulnerability affects multiple core views, so we will only target
category for this
TESTand gives all permissions to the Manager. However, all the permissions are set to
Deniedfor the Administrator.
2. Now, when the Administrator logs in to his/her account, we noticed that he/she can’t perform any function on
TEST due to lack of valid permissions.
3. Once the Manager logs in to his/her account and edits the category
TEST. The Manager does not have access to set any permissions for any user. However, while submitting the form, the Manager maliciously sets a new ACL ruleset which authorizes all the permissions to the Administrator.
Now, in Joomla, every user group has a unique ID.
In Joomla, every user group has a unique ID.
GROUP ID Public 1 Registered 2 Author 3 Editor 4 Publisher 5 Manager 6 Administrator 7 Super Users 8 Guest 9
The format of ACL ruleset in POST request form is
jform[rules][core.create][ID] jform[rules][core.delete][ID] jform[rules][core.edit][ID] jform[rules][core.edit.state][ID] jform[rules][core.edit.own][ID]
Now, if we set these POST request parameters to value 1, we will basically be setting those specific permissions to
As discussed above, we wish to authorize all the permissions to the Administrator whose group id is 7. So, we need to append the following POST data while saving the form.
4. Now, the administrator has all the permissions on
TEST category and he/she can
even edit the category details.
To know more about the Joomla exploit vulnerabilities details and more detailed steps to reproduce the vulnerability, do watch the below video proof of concept.
The Last Word
Joomla is a popular platform that allows easy Content Management for its users, but with vulnerabilities as discussed above, it can become troublesome. We recommend that the Updating Joomla CMS to the latest version (v3.9.23) that comes with the security patch for the vulnerability mentioned above.
[…] securelayer7 and also as a technology enthusiast, it is my job to suggest you keep a track of your exploitable vulnerabilities and removing risks thereby maintaining a safe environment I specialize in Network, Mobile, API
sort recently happened with me, while looking for new Joomla exploit and attacks in Joomla Security.