The Log4j Vulnerability and Failing to Protect WordPress Websites Against Relevant Threats
Over the last few days, there has been quite a bit of news coverage of a vulnerability in a Java library named Log4j. From monitoring we do to keep track of discussion of vulnerabilities in WordPress plugins for our service, we have noticed that there are questions among some about the impact this has on WordPress website and WordPress plugins.
WordPress and WordPress plugins are written in PHP, so a vulnerable Java library won’t impact them. That they are not impacted doesn’t mean that hackers won’t try to exploit the vulnerability on WordPress websites, since hacker will try to exploit vulnerabilities without knowing what software underlies a website. (That is one of the reasons that the many WordPress security plugins that try to hide usage of WordPress are not really providing security.) As an example of that, here are some of the attempts that were blocked by our new firewall on this website so far:
While the firewall isn’t designed to block exploit attempts for this vulnerability, its general protection will stop some of the attempts, since the attacker is passing invalid data as part of request.
Exploited Threat Missed
While this doesn’t impact WordPress websites unless they were somehow connected to a Java application, the WordPress security space has been focused on this, while not focusing on a threat that was being exploited on WordPress websites in the past few days.
The Pareto Security plugin for WordPress is marketed with some bold claims about the protection it provides:
Had enough of the security theatre presented by the raft of WordPress security plugins? Time to put a stop to the attacks!
Firstly WordPress and most other CMS\’s are built using PHP. PHP is a very insecure programming language, even worse in the hands of amateurs.
WordPress has been plagued by plugins authored by amateurs that bring with them security vulnerabilities.
Security plugin designers mostly focus on cleaning up attacks rather than stopping them dead in their tracks.
Pareto Security class acts as a Central Security Hub checking all inputs from users, preventing bad requests from executing on your website.
- Real Attack Prevention that can be achieved via a plugin
Yet, in our testing of WordPress security plugins, we have found that it provides fairly limited protection. The explanation for the discrepancy might be explained by the developer not being focused on the threats that WordPress websites are facing.
While the plugin has had four updates over the last few days involving adding protection against the Log4j vulnerability, it hasn’t had any updates for a zero-day vulnerability in a WordPress plugin that was exploited recently.
Looking at the changelog for the two most recent versions of the plugin Tabs – Responsive Tabs with WooCommerce Product Tab Extension you probably wouldn’t guess that a security vulnerability that was already being exploited was being fixed:
3.6.0
*Update Rest API Hooks
*Import Export Options3.5.4
Fixed Admin Bugs
But, as we warned our customers on Sunday, prior to those changes, the plugin contained an option update vulnerability that had been found by hackers and exploited to give them control of the hacked websites.
The vulnerability appears to have gone unnoticed by other security providers. The WPScan Vulnerability Database, for example, still hasn’t listed it:
At the same time, it isn’t a secret as to what happened there, as we found about this because the exploitation was discussed on WordPress Support Forum.
The most recent version of the Pareto Security plugin, 3.0.2, doesn’t protect against the vulnerability.