CVE-2016-8870 tracks a privilege escalation vulnerability in Joomla. This
vulnerability allows hackers to create users on the webserver running
Joomla even if user creation is disabled. A typical request to create an
user on server running Joomla looks like,
From the patch that’s made available to mitigate this vulnerability, it is seen that they have removed “register” method from “com_users/controller/user” class (https://github.com/joomla/joomla-cms/commit/bae1d43938c878480cfd73671e4945211538fdcf).
It is seen that this particular function doesn’t check whether user registration is enabled globally on the site and blindly creates a user when called upon. But the checks are available there in registration class as seen below.
Moreover this method is directly accessible publicly using “task=user.register” method. So using this information the above request can be modified to call “user.register” method. So the exploit now becomes like,
And the global configuration has been configured to disable registration of new users.
Running the exploit now calls user.register method directly and creates the user, despite the site not allowing to register new users.
But if the “New User Account Activation” doesn’t allow auto user enable, (which is I guess set to None by most of the admins) you can see that the user is not enabled or activated by default.
There's also further options that can be appended to the request to activate and register the user :)
References:
https://blog.sucuri.net/2016/10/details-on-the-privilege-escalation-vulnerability-in-joomla.html
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fpaper.seebug.org%2F86%2F&edit-text=
From the patch that’s made available to mitigate this vulnerability, it is seen that they have removed “register” method from “com_users/controller/user” class (https://github.com/joomla/joomla-cms/commit/bae1d43938c878480cfd73671e4945211538fdcf).
It is seen that this particular function doesn’t check whether user registration is enabled globally on the site and blindly creates a user when called upon. But the checks are available there in registration class as seen below.
Moreover this method is directly accessible publicly using “task=user.register” method. So using this information the above request can be modified to call “user.register” method. So the exploit now becomes like,
This is the user list before running the exploit.
Running the exploit now calls user.register method directly and creates the user, despite the site not allowing to register new users.
But if the “New User Account Activation” doesn’t allow auto user enable, (which is I guess set to None by most of the admins) you can see that the user is not enabled or activated by default.
There's also further options that can be appended to the request to activate and register the user :)
References:
https://blog.sucuri.net/2016/10/details-on-the-privilege-escalation-vulnerability-in-joomla.html
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fpaper.seebug.org%2F86%2F&edit-text=
Hey Thanks for sharing this blog its very helpful to implement in our work
ReplyDeleteRegards
HIRE A HACKER