WordPress All-In-One Security (AIOS) Plugin Has Been Logging User Passwords for Nearly Two Months
We recommend against using all-in-one WordPress security plugins for a number of reasons. One of them is that they likely include a lot of functionality that you don’t need, which, among other issues, can create additional security risk when you are trying to reduce it. Another is that a plugin focused on one thing should, theoretically at least, do a better job at providing the needed functionality. All-in-one plugins are rather popular, despite those concerns. The All-In-One Security (AIOS) plugin has 1+ million installs. That popularity is despite the previous and current developers having a pretty bad track record with security across the plugins they developing, including this plugin. That makes a security issue in the latest version of the plugin not all that surprising.
On June 23, a user of the plugin created a support forum topic with this concerning headline, “Cleartext passwords written to aiowps_audit_log“. They would appear to not be aware of the plugin’s poor track record, as their message started this way:
I was absolutely shocked that a security plugin is making such a basic security 101 error (not to mention being out of compliance with NIST 800-63-3, ISO27000, CIS, HIPAA, GDPR, ….)
The security 101 error they are referring to is that they found that when someone logs in to WordPress, the password they entered is stored in the plugin’s database table aiowps_audit_log. Passwords should never be stored like that. WordPress properly stores user passwords in hashed form (essentially one-way encryption), so that even if the database is compromised, an attacker wouldn’t gain access to users’ passwords. Part of the reason that is important is that it limits the damage if someone reuses a password across multiple websites.
A support representative responded the same day saying that “This is a known bug in the last release.” They also said that a fix will be “available in the next release which should be released soon”. That hasn’t been released yet.
Looking closer into this, we found that the latest version, 5.1.9, had introduced additional logging, which caused this. That addition was described this way in the changelog, “User registrations and successful logins are now recorded in the audit log”.
The audit log is enabled by default. In addition to storing more common things, including the username and IP address of a logged event, it stores the information returned from the PHP function debug_backtrace(). That data is referred to as a stacktrace by the plugin. In our testing, in the case of a successful login attempt, we found that it stores the password in plaintext twice. In responding to the question if the plugin is compatible with the EU’s General Data Protection Regulation (GDPR) suggests that reasonable data minimization is done with the plugin’s logging:
Web logs in this context are not a punishable offence under the GDPR, if you have a legal basis for retaining those logs and reasonable retention and data minimisation policies.
That seems like might not be true considering the storage of the stacktrace.
Confusingly, the changelog for the plugin lists the release date of version 5.1.9 as being May 9, but it was added to the WordPress Plugin Directory on May 22.
The user has followed up several times asking why this hasn’t been addressed without a satisfactory answer (or in some cases any answer).
There are multiple fairly easy methods to have quickly stopped more logging from happening, including disabling the feature until it can be better handled. Removing the already logged information would be slightly more complicated, but removing the stacktrace for the relevant logged events would resolve this.
Not having released a fix for this in over two weeks since the developer has clearly known about this shouldn’t be acceptable.