The Problem: A Default Setting
By default user registration is enabled.
It’s important to realise that even though links to the user registration page may not have been included in the design of a Joomla site the components are still present and they will be regularly targetted by automatic spiders searching for vulnerable sites. Check access logs for requests to paths like:
- /index.php/shop-login
- /index.php/shop-login?view=registration&layout=complete
- /index.php/component/users/?view=registration
- /index.php/component/user/?task=register
- /index.php?option=com_user&view=register
With user registration enabled scripts can use a Joomla site as an open mail relay by registering users with target email addresses and inserting spam/attack payload into the user details. The Joomla site will send a confirmation email to the target email address, and any email tracing of the source of the email will lead directly to the weakened Joomla server.
Disable User Registration
The method varies depending on the version of Joomla, in later versions it is done as follows:
“Navigate to Users → User Manager then click on User Manager. Once in User Manager Screen, click on ‘Options’ Toolbar button to show the pop up window, as in image above. Click to fill bubble next to Allow user registration, then click save.”
Reference : Joomla Documentation: Disabling User Registration
If a site has had to be disabled due to this problem the Joomla Control Panel will not be available so the above steps are not useful. It is possible to disable user registration manually by updating the chvnp_extensions table – for name=’com_users’ (updating the JSON in the params column).
User Registration Is Still Possible
Site administrator can still add new accounts using the Joomla Control Panel under /administrator/.
Restrict Access To /adminstrator/
Speaking of Control Panel, /adminstrator/ is a known target on every Joomla website. There is no need for anyone without administrative access to have any access to that directory so at the very least add basic authentication to that directory.
Better yet, protect accesses to that directory with HTTPS to encrypt both your authentication credentials and your administrative traffic.
Site Cleanup
Once the attack vector is blocked the site will still have the new accounts left over from the attacks. Depending on how long the attack has been going on there may be many (hundreds of thousands, perhaps more) of these accounts.
Unfortunately the Joomla Control Panel does not handle a large number of accounts (read more than a couple of hundred) at all well. The default maximum number of accounts listed “per page” is 100 and while this can be manually overridden by editing the site URL (eg. “&list[limit]=2000”) this doesn’t get you far with hundreds of thousands of accounts.
Also the process of deleting a user from a Joomla site is relatively involved with rows being deleted from a number of tables with a couple of different foreign keys in play, so just deleting the user manually is not an easy approach either.
Fortunately it’s quite easy to write a script to interact with the Control Panel (I used WWW::Mechanize) – select the user IDs that you don’t want to delete and then write a script which will remove all the others!
I’ve attached the perl script I used here: delete_joomla_users.txt
Site Modules Are Known Targets
As a footnote, and one which I’ve yet to fully explore – modules are known targets. This is not a Joomla-specific problem – once an attacker can identify the underlying system which provides a website (in particular content management systems which allow dynamic updates to content and so have more attack vectors than a static website) then known vulnerabilities can be targeted.
Other than keeping site software up to date, applying security updates and configuring the site such that it is not vulnerable (as described in this article) it’s important to keep auditing both the public contents (eg. web page contents, images, hidden embedded scripting) and private contents (eg. extra users registered).