There are two closely related information disclosure issues in Admin Tools. Installing version 5.1.0 addresses both of them. Most sites can not be hacked remotely but will very likely disclose privileged information to a hacker who has already infiltrated the site. People stuck in older versions should read through this document for mitigation procedures.
Please keep in mind that sites using our recommended configuration, as applied by the Quick Setup Wizard were only in moderate risk: some usernames and passwords were logged in the database and possibly the debug log file which are only available to Super Users and people with filesystem access to your site. While not ideal, it's not a huge risk, i.e. you can't be hacked remotely. On a minority of sites and only as a result of manual configuration it is possible that in some cases a remotely accessible log file may contain both usernames and passwords, leading to a serious security concern.
This document is published both on our site and as part of the Release Notes of the new Admin Tools version.
Discovery of the issues
During our internal GDPR audit we had already identified two possible security and privacy issues affecting Admin Tools versions at least as old as 3.1.0. These issues were discovered between March and April 2018 and we had already applied fixes for them between April and May 2018.
On May 8th and 9th, 2018 we were contacted by the Joomla! Vulnerable Extensions List (VEL) about these two potential security issues, including further information about use cases where they could raise serious security concerns. While for most sites mitigations put in place by other Admin Tools features, applied by default when using the Quick Setup Wizard, are adequate to minimize or completely mitigate the impact of these issues, the use cases identified by the VEL -unlikely as they are- are serious enough to warrant an immediate security release. For this reason we are releasing Admin Tools 5.1.0 today, May 10th, 2018.
We would like to thank the Joomla VEL for their contact, their time and their service to the Joomla! community.
Issue 1 - Logging of cleartext passwords of failed logins
If you had enabled the option to log failed login passwords be advised that they are stored unencrypted in the #__admintools_exceptions security exceptions log table on your site. This feature has been removed from the new version of Admin Tools but information may still be present on your site.
This information is automatically removed when updating to Admin Tools 5.1.0. If you cannot update Admin Tools we recommend that you go to the Security Exceptions Log page, filter by reason "Login failure" and delete all records presented to you. We also recommend that you automatically delete old security exception records by setting up the "Maximum security exceptions log entries" to a non-zero value in the System - Admin Tools plugin. A value between 1000 and 10000 should offer a good balance between data minimization and security for most sites.
This issue had been independently discovered by us in April 2018 during our internal GDPR compliance audit and had already been addressed when we were notified by the VEL.
Issue 2 - Possible information disclosure on misconfigured servers through the debug log file
Previous versions of Admin Tools stored a debug log with a .log extension in your Joomla! logs directory. By default, this directory is web accessible. However, if you were using Admin Tools' Administrator Password Protection or .htaccess / nginx.conf / web.config maker OR if you put your logs folder outside your web root your log files were never accessible over the web. The default configuration applied by the Admin Tools Quick Setup Wizard is to disable web access to the logs folder (which is always a great idea for security reasons). Please note that the debug log contains all of the information in the request being blocked. If the request being blocked contains usernames and passwords (e.g. you used the Treat failed logins as security exception, the Forbid frontend administrator login or the Forbid editing backend users features) these were logged as well. In version 5.1.0 of Admin Tools the debug log is turned off by default. Moreover, existing debug log files are deleted when you install an update to Admin Tools or when you disable the debug log in the Configure WAF page.
Further to the above, the debug log file type has changed to a .php extension and we have put a die() statement to prevent access to the file even if your logs directory is web accessible. However, this has a very serious implication on some hosts. The debug log file contains all of the informaton of the blocked request. If the blocked request is a legitimate hack attempt, i.e. what Admin Tools is designed to block, you will now have an inert log file with a .php extension containing hacking code signatures. Some hosts have automated scanners which might misinterpret that file as hacked or suspicious. Depending on the host you may get a warning, the file may be deleted or renamed or your site might be suspended. If the file gets renamed with a .1 extension it will be made web accessible, defeating the whole point of using a .php extension and potentially putting you at risk (unless you have already used the .htaccess Maker or the administrator password protection features to prevent access to the log file as explained earlier). In either case, if your host gives you grief about this file please ask them to read the header information on the file where we explain why the file is safe and that they need to whitelist it. If they refuse to do it you will have to disable the debug log file in the Configure WAF page (by default it's disabled) or go to a different host. There's nothing else you can do.
As a general rule we recommend that you DO NOT enable the debug log unless you are trying to troubleshoot something. Once you are done with troubleshooting disable the debug log.
This issue had been independently discovered by us in March 2018 and had already been partially addressed in May 2018 before we were contacted by the VEL. Upon VEL's contact we changed the extension of the log file to .php and introduced the automatic deletion of existing log files when this feature is turned off.
Mitigations in version 5.1.0
This section repeats some of the information in the previous paragraphs in a more concise format.
All the mitigations are automated. You do not need to do anything manually after upgrading to Admin Tools 5.1.0 or a later version.
- Version 5.1.0 no longer offers the option to log failed login passwords. This feature has a very limited use and it is a bad security practice.
- Upon installing an update the existing failed login records are removed if the option to log passwords had been turned on.
- Upon installing an update the existing plaintext debug log with a .log extension (and the rotated log with the .log.1 extension) is removed from your site automatically.
- The debug log file now has a .php extension and a die statement to prevent direct access. This MAY cause troubles with some hosts if it's enabled.
- Enabling the debug log file is now a separate option, turned off by default. In the past it was tied to the overall logging (log security exceptions in the database) which is however required to provide automatic IP blocking.
As a result new installations are secure by default and existing installations are automatically secured upon installation of the new version of Admin Tools.
Mitigations for older versions
If you cannot upgrade to Admin Tools 5.1.0 we recommend that you take the following actions manually to mitigate any security impact of the aforementioned issues:
- Turn off the Include password in failed login email feature in the Configure WAF page
- Use either the .htaccess Maker's Backend protection feature or the Administrator password protection feature to prevent access to the logs directory
- If you want to completely disable the debug log file you can edit the
plugins/system/admintools/util/exceptionshandler.phpfile, find theprivate function logSecurityExceptionToFile($reason, $extraLogInformation, $txtReason, $tokens)line and add a new line AFTER the first curly brace readingreturn;Please note that this completely disables the debug log file.
General considerations on the security of Joomla log files
Joomla! stores plaintext log files in its logs directory. By default this is located in the administrator/logs folder of your site. Since it is under your web root it can be accessed over the web on a default Joomla! installation.
Joomla! stores its own log files as .php files with a predictable filename and a die statement on top. While this prevents direct web access to each file, it poses a major security risk. For example, there are two security concerns regarding this practise:
- It allows for log discovery by trying to access each log file's predictable URL over the web. Even though this does not sound important, it allows an attacker to determine with very good certainty whether your site's Debug mode is on. In turn, this can be abused to exploit the difference in Joomla behavior when Debug mode is enabled.
- Even more seriously, if your server is misconfigured to dump the contents of .php files instead of executing them you have a serious information disclosure vulnerability. This can happen either for the entire web root or just for the logs directory due to a wrong .htaccess / nginx.conf / web.config directive, a misconfiguration on the host's part etc. These mistakes can last anywhere from a few seconds to several days in the real world.
- Since the log files are in a predictable locaation and a predictable name, an attacker can exploit a file access vulnerability in an unrelated extension or script running on your site to dump the contents of the log files, triggering an information disclosure event.
For these and other more esoteric reasons we consider that the default logging behavior of Joomla is inherently insecure. What we have been always recommending is to move your Joomla logs directory outside the web root, i.e. in a directory above public_html. This mitigates all of the above issues. Sure, log files can still be dumped if the attacker has the ability to execute arbitrary PHP code on your site. However, in this case they have "pwned" your site, that is they have full access and can do whatever they want, including adding code to intercept logins and send the username and password to their server. Therefore we can safely say that moving your site's logs directory outside the web root is the most practical, fully adequate mitigation.
A partial mitigation can be provided by blocking web access to the logs directory completely at the web server level. When you use the .htaccess Maker in Admin Tools with its Backend Protection feature this is what you do; web access to the logs directory is completely blocked. The Password Protect Administrator feature also works to that effect. Since you need a password to access the /administrator folder (and all its subfolders, including logs) you are effectively blocking direct access to the log files over the web. Moreover, if you use our logs and temp directory fixer feature you also get the same kind of protection even if you do not use the .htaccess maker or the password protect administrator features: a .htaccess file to prevent direct web access will be written in the logs folder. If unsure, use this feature to provide basic mitigation for Joomla's logs directory behaviour.
Arguably, the best mitigation is something that most sites cannot do: using a separate log server. This will be possible with Joomla! 4 and its support for the PSR-3 logger technology. However, this is complicated to setup. Those of you who need it already know what this means. Everyone else should just focus to the practical, fully adequate mitigation of using a logs directory outside the web root. You can configure that through Joomla's Global Configuration page.
We'd like to point out that our documentation has stated, since 2010, that the default Joomla logs directory is insecure and must be secured.