On Sunday we had probing on our website for usage of the plugin WP Security Audit Log, which has 80,000+ installs according to wordpress.org, from what looked to be hackers. Considering that plugin is known to vulnerable we didn’t further check in to what was going on, which was a mistake, but one that other monitoring we do allowed us to rectify today.
One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that we caught a vulnerability a plugin with 10,000 installs (according to wordpress.org), Ultimate CSV Importer, that could allow an attacker to cause someone logged in as Administrator to fully disable the website just by getting them to access a page the attacker control’s (say with a link in a comment). With non-default settings the vulnerability could be exploited users with the Author or Editor role, or by getting them to access a page controlled by an attacker.
For not the first time this week our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins has caught an authenticated option update vulnerability in a plugin, this time in the plugin Essential Content Types. Like the one we mentioned yesterday this one could be used to disable a website, either by someone logged in to WordPress or if an attacker can get someone logged in to WordPress to access a page they control.
On Monday while disclosing another option update vulnerability we noted that in the wake of one of those being widely exploited recently we had focused on finding more of those vulnerabilities, while it appears no one else in the WordPress security has done that (maybe because they can get away with lying about failing to protect against the widely exploited one). And no sooner than the next day did we find yet another vulnerability. We spotted it during our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins, though the vulnerable code was not flagged by the software that we use to identify possible issues for us to review, instead that had flagged another possible instance of that same type of vulnerability in the same code and when we went to manually review the code we found the issue.
When it comes to the hackings of WordPress websites due to the software on them, those are largely due to security issues in WordPress plugins. So you would assume that a major focus of security companies involved in the security of WordPress websites would be based around those, but what we have found is that isn’t true. Often others in the industry are warning about vulnerabilities weeks after us (and often only after they have been wide spread exploitation attempts) and they spend a troubling amount of time making up threats that don’t really exist (maybe because it is easy to protect against non-existent threats). In the wake of an option update vulnerability in the plugin WP GDPR Compliance being widely exploited the response of one high profile company that failed to protect their paying customers was to lie about that.
Yesterday we noted that our newly improved proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins, which built on code we had developed for our Plugin Security Checker, an automated tool you can use to check if plugins you use contain possible security issues, had already caught a fairly serious vulnerability, one that could leave a website fully disabled. That vulnerability was yet another vulnerability due to insecure usage of the update_option() function that we have found in the wake of one of those being widely exploited. Today that monitoring caught a more serious vulnerability related to that function, since this vulnerability could be use to take full control of websites and while it requires the attacker to logged in to WordPress, the plugin in question, ARMember Lite, is a membership plugin, so it would be on websites that would probably allow for user registration.
In the wake of widespread exploitation of an option update vulnerability in the WordPress plugin WP GDPR Compliance the difference in our response to others in the WordPress security community has been a reminder that unfortunately we are largely alone in trying to actually make WordPress websites more secure against security issues in WordPress plugins.