On December 9th, 2021, the Apache Software Foundation announced a vulnerability in Log4j.
Tenable, Inc. called the issue “the single biggest, most critical vulnerability of the last decade”. In this article, we’ll provide the basics of the Log4j vulnerability, and dive into the responses to the vulnerability that we’ve received from some of the major players in the WordPress ecosystem.
Log4j Background
Apache is a very well-known software, used by many servers that host websites. Its status as a free and open-source software is part of the reason for its widespread adoption. The Log4j application is a Java logging framework used within Apache to log errors and other issues at the server level.
Logging errors is a ubiquitous task for Java, and Java is a very popular language, so the Log4j library is widely used on websites and applications around the world. The vulnerability itself made it possible for a threat actor to execute code on servers that had the affected version of the Log4j application installed.
Once a threat actor has the ability to run their own code on your server, there’s not much limit to the amount of damage they can do, or the amount of data they can gain access to.
These factors in tandem made this a critical vulnerability, classified at the absolute highest severity rating by the Common Vulnerability Scoring System (CVSS), a framework used by cybersecurity experts to conduct risk analysis.
Without getting overly technical, the main takeaway here is that Log4j is a severe vulnerability that demanded prompt action from the entire web community. As of January 2022, the Log4j vulnerability has been widely addressed, and affected applications have released patches to fix the issue.
Was Your Website at Risk?
Everyone should be asking their hosting company, IT provider, and web services provider about their response to Log4j, and whether their business is at risk.
The good news is that if your website is hosted with WordZite, your web server is not at risk. The servers we use run on Nginx, which is a competitor to Apache and does not use Log4j.
As for WordPress itself: it runs on PHP, not Java. So, the majority of WordPress websites were not affected by this vulnerability at all. However, some WordPress plugins do use Java. If a website had a vulnerable plugin installed, a threat actor could still potentially exploit that plugin.
We’ve done our best to check with the developers of major plugins that our clients’ sites rely on. We’ve also taken the time to review various published lists that show which plugins may have been affected. The list of affected plugins is essentially a list of less popular and less widely adopted plugins. The most popular WordPress plugins were not on the list. And not a single one of our clients had any of the affected plugins installed. In the case of Log4j, all but 2 of the affected plugins responded to the issue promptly, releasing updates and patch fixes. But even that doesn’t mean we’re free and clear.
We decided to take our due diligence a step further, and we’ve reviewed the Log4j statements released by some of the most popular service providers within the WordPress ecosystem. The statements from these providers are collected below. (Text in italics indicates a direct quote from the provider’s website.)
You may note that some service providers did not release a statement. This doesn’t necessarily mean that they weren’t aware of the issue, but more likely means that they were not affected and thus did not need to release any updates.
The following are the statements from various players starting with WordPress itself.
- WordPress
Multiple people within the WordPress community have made statements reiterating that WordPress was not affected.
Log4j is JAVA code. WordPress and its plugins use PHP and so are not affected by log4j issues.
WordPress is not using any Java components (don’t confuse Java with JavaScript! It is different). This vulnerability is not applicable.
Note that these are forum comments and not official responses from WordPress.com or WordPress.org. Likewise, note that WordPress did not release any security updates or patches in December. We believe it’s safe to say that the WordPress core is not at risk.
- SiteGround
A vulnerability was discovered in the Log4j Java library. You are completely safe from that exploit because we use NGINX as the client facing web server for our systems and there’s no Log4j library configured anywhere on your hosting account. In addition to that, we do not use any additional or 3rd party service that uses the vulnerable library to provide a certain service.
- Kinsta
No official response
- WPEngine
No official response
- WordFence
Due to the severity of these vulnerabilities and the massive campaign targeting them, it is incredibly important to ensure your site is protected from compromise. If your site is running Wordfence Premium then it is already protected against any exploit attempts targeting any of these vulnerabilities. If your site is running the free version of Wordfence then it is protected against any exploits targeting any of the vulnerabilities, with the exception of the recently patched vulnerability in PublishPress Capabilities. Sites running Wordfence Free will receive the firewall rule for PublishPress Capabilities on January 6, 2022, which is 30 days after Wordfence Premium users.
Regardless of the protection that Wordfence provides, we strongly recommend ensuring that any sites running one of these plugins or themes has been updated to the patched version. We have the affected versions of each product outlined below. Please ensure that your sites are running a version higher than any of the ones listed. Simply updating the plugins and themes will ensure that your site stays safe from compromise against any exploits targeting these vulnerabilities.
The following are the affected plugins and their versions:
- PublishPress Capabilities <= 2.3
- Kiwi Social Plugin <= 2.0.10
- Pinterest Automatic <= 4.14.3
- WordPress Automatic <= 3.53.2
The following are the affected Epsilon Framework theme versions:
- Shapely <=1.2.7
- NewsMag <=2.4.1
- Activello <=1.4.0
- Illdy <=2.1.4
- Allegiant <=1.2.5
- Newspaper X <=1.3.1
- Pixova Lite <=2.0.5
- Brilliance <=1.2.9
- MedZone Lite <=1.2.4
- Regina Lite <=2.0.4
- Transcend <=1.1.8
- Affluent <1.1.0
- Bonkers <=1.0.5
- Antreas <=1.0.4
- Sparkling – No patch known. Recommended to uninstall from site.
- NatureMag Lite – No patch known. Recommended to uninstall from site.
How Do I Know If My Site Has Been Infected and What Should I do?
As previously stated, the attackers are updating the users_can_register option to enabled and setting the default_role option to `administrator` in most cases.
To determine if a site has been compromised by these vulnerabilities, we recommend reviewing the user accounts on the site to determine if there are any unauthorized user accounts. If the site is running a vulnerable version of any of the four plugins or various themes, and there is a rogue user account present, then the site was likely compromised via one of these plugins. Please remove any detected user accounts immediately.
It is also important to review the settings of the site and ensure that they have been set back to their original state. You can find these settings by going to the http://examplesite[.]com/wp-admin/options-general.php page. Please make sure the `Membership` setting is correctly set to enabled or disabled, depending on your site, and validate that the `New User Default Role` is appropriately set. We strongly recommend not using `Administrator` for the new user default role as this can lead to inevitable site compromise.
- Sucuri
If you are a website owner or operate a VPS or other server, be sure to update any software you use that makes use of log4j to the most recent, patched version. You may also want to query your file system for files modified recently, or possibly roll back your server to a safe snapshot before any potential compromise took place and then update the vulnerable software right away.If you wonder if any software you use on your server or home/work network may be at risk, please take a look at this handy list kept by Nationaal Cyber Security Centrum from the Netherlands.
If you use a VPS, employing the use of an intrusion detection system such as OSSECHIDS on your server would also be advisable. This will help keep track of system file changes and other potential indicators of compromise on the server itself (rather than just your website). To prevent your website from being a vector for this server exploit you can also put your website behind our firewall and we will shield it from this attack and many others.
- Google Workspace
Based on our findings, Google Workspace core services for consumer and paid users are not using Log4j 2 and are not impacted by the issues identified in CVE-2021-44228 and CVE-2021-45046.
- AWS
Responding to security issues such as this one shows the value of having multiple layers of defensive technologies, which is so important to maintaining the security of our customers’ data and workloads.
We’ve taken this issue very seriously, and our world-class team of engineers has fully deployed the Amazon-developed Java hot patch available here to all AWS services. The hot patch updates the Java VM to disable the loading of the Java Naming and Directory Interface (JNDI) class, replacing it with a harmless notification message, which mitigates CVE-2021-44228 and CVE-2021-45046. We will shortly complete our deployment of the updated Log4j library to all of our services. More information about the Java hotpatch is available at https://aws.amazon.com/blogs/security/open-source-hotpatch-for-apache-log4j-vulnerability/.
Even with this hot patch deployed, customers should still deploy an updated Log4j library as quickly as they safely can, like we’re doing across AWS.
- CloudFlare
Was Cloudflare compromised?
While we were running versions of the software as described
[in the full blog post], thanks to our speed of response and defense in depth approach, we do not believe Cloudflare was compromised. We have invested significant efforts into validating this, and we will continue working on this effort until everything is known about this vulnerability. Here is a bit about that part of our efforts.As we were working to evaluate and isolate all the contexts in which the vulnerable software might be running and remediate them, we started a separate workstream to analyze whether any of those instances had been exploited. Our detection and response methodology follows industry standard Incident Response practices and was thoroughly deployed to validate whether any of our assets were indeed compromised. We followed a multi-pronged approach described next.
- GoDaddy
As of January 3rd, 2022, all GoDaddy services and products have been patched to protect against the Log4j vulnerability.
- CPanel
The same day the vulnerability was announced, we published an update with the mitigation for CVE-2021-44228 to the cpanel-dovecot-solr RPM in version 8.8.2-4+. The only service provided by the cPanel software that uses the logging utility Log4j is cpanel-dovecot-solr. If you do not have this installed, then your server is secure. This patch will automatically be applied during the nightly updates if this package is installed. On new installations of Dovecot_FTS it will include the patched RPM by default. You can join the discussion on the cPanel Forums log4j-cve-2021-44228 thread. You can check if this RPM is installed by running the command below.
Conclusion
What isn’t mentioned in any of these comments is the amazing response time and hard work of the people behind these brands. We know that a lot of talented folks spent their holidays investigating and applying patches to log4j. In that vein, we would like to acknowledge and thank the hardworking people within the web community who gave up their holiday time to help make the internet a little bit safer.
We hope you all get some much-needed time off this January.
- WordFence
preprovoked