#31631 – Super User: name & password have been changed

Posted in ‘Akeeba Admin Tools for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 07 August 2019 08:53 CDT
Dear Akeeba-Team, Nicholas,

we experienced the weirdest issue:

On a plesk-auto-installed Joomla-Instance, we use only internally for testing new Joomla features, our super user account suddenly had a new username (AnonymousFox) and password. The website is though publicly available, no directory password protection, but there are only two persons in the company knowing the URL and the login for the only account - a super user with a fairly complex username, something like "admin_fgz55xy5". The website is nowhere linked, the URL never communicated externally. It has almost up-to-date Joomla & AdminTools versions installed. Unfortunately I cant tell for sure what versions were installed while the change happened (if this info is of any importance), because we did some updates after fixing the super user manually via the DB. Other than this, the website was not compromised (as far as we could tell). How could that happen?

My Questions:

1. Did you experience/heard of something similar before? Couldn't find any info on this online, the only thing that pops up and it is similar is about an "AnonymousFox" hack, but that was WordPress-only...

2. Shouldn't AdminTools have prevented this by default?

3. Is there any way to check in the Joomla backend for when updates were made, and from what version? Some kind of a update log? For Joomla itself, but also 3rd party extensions as AdminTools?

All best, με εκτίμηση,

Custom Fields
Joomla! version (in x.y.z format) 3.9.x
PHP version (in x.y.z format) 7.1.31
Admin Tools version (x.y.z format) 5.3.x
Wednesday, 07 August 2019 10:18 CDT
1. I have not heard of that before. I can speculate about what happened but I'd rather not until we resolve point #2.

2. It depends. Have you enabled the "Disable editing backend users' properties", "Disable creating / editing backend users from the frontend" and "Monitor Super User accounts" features in Hardening Options in the Configure WAF page? The first one prevents using the Joomla backend Users page or the Joomla API to create or modify any user with backend access privileges from the backend and frontend. The second option prevents using the Joomla API to create or modify any user with backend access privileges from the frontend of the site. The latter option is an added safety feature which immediately disables any user with backend access which was NOT created through Joomla's backend Users page.

If you had not enabled all of these and especially the third feature, no, Admin Tools could not have protected you because you told it not to.

If you had enabled everything then the attacker bypassed Joomla i.e. he already had a backdoor on your site (in a directory you chose not to protect with the .htaccess Maker or if you are not using the .htaccess Maker) or your server was hacked at the control panel or operating system level. Since these modes of attack completely bypass Joomla, PHP and your web server they allow the attacker to sidestep any protection. There is objectively nothing anyone could possibly do in that case.

Please note that just because your site is not deliberately listed on search engines does not mean that it cannot be found. There are other ways such as trawling whole IP ranges for specific kinds of server, looking for recently registered domain names etc. Not to mention that just because you didn't manually submit your site to a search engine it doesn't mean the search engine didn't pick it up. I am pretty sure that Google Chrome sends back telemetry including the URLs you are visiting.

3. No. You can use the User Actions Log to keep a log of actions initiated by humans logged into the site's backend. However, this feature cannot tell you about automated / out-of-site actions (e.g. Plesk auto-updating Joomla or myJoomla updating Akeeba Backup for example) and its utility is limited by extensions' support for it. We have added support in all our software and Joomla core extensions do support it.

In any case I would recommend that you reset all of your passwords (Plesk, FTP, database, Joomla) and that you make sure that both Joomla and Plesk itself are up-to-date. Regarding your passwords, I very strongly recommend using 32 to 64 character (a-z, A-Z, 0-9 and special characters !@#$%^&*()_+-={}[];:'"\|,<.>/? ) truly randomly generated by and stored in a password manager.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 07 August 2019 10:32 CDT
Dear Nicholas,

thank you for the quick reply!

On 2:
YES: "Disable editing backend users' properties"
YES: "Disable creating / editing backend users from the frontend"
NO: "Monitor Super User accounts"

So, if I understood correctly, the attack was not coming from Joomla, it was bypassed?
A server issue?
How can I verify if this happened?

Thursday, 08 August 2019 02:46 CDT
Since the third option was not enabled there was no way for Admin Tools to detect the Super User change coming outside of Joomla's API. The reason we added this feature was the fact that Super User changes can be applied directly to the database by an attacker exploiting a SQL injection or remote code execution vulnerability.

This does not necessarily mean that the attack did not come through Joomla. It is conceivable that a third party extension has a vulnerability which cannot be protected against by Admin Tools or that the relevant options are disabled. For example, if SQLiShield is disabled there's nothing stopping a SQL injection from taking place. Moreover, it is possible that you are not using the .htaccess Maker or have allowed direct access to .php files (select files or entire folders). In this case, a directly accessible .php script which does not go through Joomla may have a vulnerability; or the attacker may be able to upload and execute arbitrary .php files in a predictable location. In both cases the .php scripts are directly accessible from the web and do not go through Admin Tools which means that Admin Tools cannot protect you. That's why the .htaccess Maker blocks, by default, access to all .php files except Joomla's index.php and why the best practice for Joomla extension developers is to never, ever use directly accessible .php scripts with the sole exception of replacing Joomla itself (i.e. restoring a site or updating Joomla itself which limits that to basically backup extensions and Joomla! Update). What you should take away is that if a third party extension did something stupid or you allow access to arbitrary .php files on your site you can get hacked; enable Admin Tools' protection to mitigate these issues.

It can also be that the attacker guessed or stole your login information for either Plesk or FTP. As I mentioned before, just because you don't have search engines crawl your site or purpose does not mean it's "hidden". It is on a live server connected to the Internet. There are a myriad different ways finding it. At the very least, it shares an IP address with some of your live, indexed sites. If I were a hacker I'd look for Joomla sites, then do a search on their IP addresses to find other domains on the same IP which are probably going to be similar installations of the same vintage. Passwords can be stolen either by someone sniffing the network for traffic (not too hard on a public Wi-Fi such as hotel, cafeteria or airport) or via malware. Most usually it is guessed because the default account passwords in Plesk, cPanel etc are woefully insecure and only meant to facilitate novices. As I mentioned, change all passwords and use something really, really long and complex.

Regarding detection. I cannot tell you anything more as I'm not you :) Since you have the server logs you could check for any unusual logins or FTP connections. It would also be a good idea checking the web server's access logs around the time the change occurred.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 07 September 2019 17:17 CDT
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.