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.
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.
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.
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.
This section repeats some of the information in the previous paragraphs in a more concise format.
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.
If you cannot upgrade to Admin Tools 5.1.0 we recommend that you take the following actions to mitigate any security impact of the aforementioned issues:
plugins/system/admintools/util/exceptionshandler.php
file, find the private function logSecurityExceptionToFile($reason, $extraLogInformation, $txtReason, $tokens)
line and add a new line AFTER the first curly brace reading return; Please note that this completely
disables the debug log file.
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:
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.
SECURITY RELEASE. Please read our security bulletin in these release notes or our site's News section.
Added option to choose if Admin Tools should write the log file or not (required by GDPR). We recommend turning this option off under normal operation of your site. You should only turn it on for troubleshooting, i.e. when you are trying to identify whether Admin Tools is blocking something on your site and why.
Added option to allow only specific email domains during user registration. This is useful if you have an organization website which should only allow users with organization-provided email addresses to register a user account.
Added feature to check if user password is inside any dictionary of leaked passwords.. This feature is disabled by default. GDPR advisory: this feature sends a hash of just a part of the password when the user logs in to a third party service. This information is anonymized and cannot be traced to a real user's identity. We therefore understand that it's GDPR compliant. If unsure, please ask your lawyer. This advisory is not a legal advisory and should not be treated as such.
Bug fixes. We have addressed a few more low priority bugs. Please consult the CHANGELOG.We only support Joomla! 3.6 or later, including 3.7 and 3.8. We strongly advise you to run the latest available version of Joomla! for security reasons. Older versions of Joomla! have known major security issues which are being actively exploited to hack sites.
This version of our software has preliminary support for Joomla! 4 (only tested with Joomla! 4.0.0 Alpha 2), released in November 2017. Please note that Joomla! 4 is still in its early development stages. As a result we cannot guarantee that our software will work problem-free on future testing or stable versions of Joomla! 4. Please bear in mind that just like Joomla 4 itself, our support for it is currently work in progress.
Support for PHP 5.3 has been discontinued. PHP 5.3 has been end of life since August 2014 and widely considered a security risk, unfit for production sites. Our software requries PHP 5.4 or later and is compatible with PHP 5.4, 5.5, 5.6, 7.0, 7.1 and 7.2. We strongly recommend using PHP 5.6 or 7.1.
We'd like to remind you that Joomla! 3.4 does NOT support PHP 7. PHP 7 is only supported by Joomla! 3.5.0 and later versions. Akeeba Backup will work perfectly fine (and very fast!) on a Joomla! 3.5 or later site running on PHP 7.0.
HEADS UP! The next version family, Admin Tools 5.2, will no longer support PHP 5.4 and 5.5.
Disclaimer: this is not a legal advisory. Please consult your lawyer if you are unsure.
On May 25th, 2018 the European Union's General Data Protection Regulation (GDPR) comes into effect. We have been asked about how Admin Tools complies with it a few times. The following is our understanding of it but it does not constitute legal advice of any kind.
While storing IP information may be considered personally identifiable information, the GDPR makes an exception for IP information stored in the context of security. As such the Admin Tools' security exceptions log and related IP whitelist, IP blacklist, automatic IP blocks and automatic IP blocks history is outside the scope of personal data protection.
Text log files may, however, contain privileged information as they capture the entirety of the request sent by the user to your site. We therefore recommend that you DISABLE the "Keep a debug log file" option in the Configure WAF page. Please note that if your logs directory is under your web root and you have not used Admin Tools' features, such as the .htaccess Maker, to secure these directories all your logs may be publicly accessible. We recommend that you always make your logs and temporary directories inaccessible to the web for security reasons.
Furthermore, the GDPR calls for data minimization. To comply with this requirement we urge you to set the "Maximum security exceptions log entries" option to a non-zero value in the System - Admin Tools plugin. Typically, a value of 1000 to 10000 provides a good balance between data minimization and security.
The Project Honeypot and "Warn about use of well-known passwords" features do transmit information to third parties. However, this information is anonymous and should, therefore, fall outside the scope of the GDPR.
Finally, it is possible that in the past you may have enabled the faeture to log failed login passwords. This might be a security concern or a violation of the GDPR. We have now removed that feature but you may still have information stored in your database. We recommend that you go to the Security Exceptions Log page, filter by reason "Login failure" and delete all records presented to you.