Welcome to the Patchstack Weekly Security Update! This update is for week 50 of 2021.
It is mid-December, and we are still waiting to see the total impact of a vulnerability reported in the open-source component: log4j. This is a library used in a large number of java applications and I will get the details later during this week’s knowledge share.
In WordPress security news this week, there are a few plugins that have serious vulnerabilities reported in them, including unauthenticated attacks that may affect tens of thousands of websites. So, let’s get to that right away….
Vulnerability News
Multiple Option Table update vulnerabilities.
I mentioned the unique WordPress vulnerability named “option table update” just last week. This week there are 2 plugins that have released patches for this same vulnerability class to report.
I can not emphasize the risk of this vulnerability enough, as this vulnerability is commonly used to hijack websites and have their traffic redirected to scam/spam websites, this certainly will ruin the site’s reputation and certainly is worth patching as soon as possible.
The plugins affected by an unauthenticated option table update vulnerability this week are:
Image Hover Effects Ultimate
Unauthenticated Arbitrary Options Update leading to full website compromise discovered by mirphak aka John Castro (Pagely) in WordPress Image Hover Effects Ultimate plugin (versions <= 9.6.1).
Update the WordPress Image Hover Effects Ultimate plugin to the latest available version (at least 9.6.2).
* Patches by the developer do not completely eliminate the vulnerability. If possible protect your site with vPatches.
Accordions – Multiple Accordions or FAQ Builder
Both of these plugins are allowing unauthenticated requests to update the site’s WordPress options tables. I recommend if you’re running these plugins after you update be sure to also review the site’s options table values to ensure they have not been manipulated already.
Unathenticated SQLi in The Plus Addons for Elementor Pro
Site owners who have this premium plugin installed should make sure it has been updated to version 5.0.7, it only takes a few minutes and is well worth the time.
Privilege Escalation and Authenticated SQLi in All in One SEO Pack
Last, but not least, I need to give you a heads up that a popular Search Engine Optimization plugin with millions of installations on WordPress websites worldwide has two authenticated vulnerabilities.
Site owners running the All in One SEO pack plugin should update to version 4.1.5.3. Since these vulnerabilities require authentication, the risk is not the same for everyone, but you should still update soon.
Sites that have any sort of user base, including subscriber accounts should update as soon as possible, the privilege escalation bug could result in a random user taking over the whole website.
Weekly Knowledge
We will be talking about log4j, I will share how quickly this vulnerability was weaponized, so you think about how quickly your patches need to be getting applied.
Understanding the timeline
2021-11-24 Security Researcher Chen Zhaojun privately reports a critical security vulnerability in the log4j software to the project’s security team.
2021-12-06 log4j version 2.15.0 released, includes a patch for the critical security vulnerability.
2021-12-09 Minecraft server admins begin reporting potential compromises related to this vulnerability. The impact is not yet fully understood some people believe it only affects Minecraft. The first Proof of Concepts are published on GitHub later this day.
2021-12-10 The vulnerability gains traction online, as security researchers, defenders, and bug bounty hunters share simple detection methods with each other. It starts becoming apparent that attackers could reach a lot of potentially vulnerable systems.
2021-12-11/12 A mad rush has already begun … bug bounty hunters, hackers, and security researchers use the knowledge shared over the last few days to detect vulnerable Java applications across the internet.
When a potential insecure system is found, bug bounty hunters report the issue, botnets installed crypto-mining tools, hackers did who knows what, and some chaotic-good white hat hackers released code to auto-patch compromised systems using the exploit they’re vulnerable to. That’s right, they wrote code to break into insecure systems and fix the problem.
2021-12-13 log4j version 2.16.0 released this release completely disables the functionality that lead to this vulnerability in the first place.
Why is everyone trying to uncover insecure log4j instances?
The vulnerability is simple to attempt, it turns out some Java applications log close to everything and pass that data through the log4j library.
Usernames, Wifi SSID names, any form field in web or mobile applications, pretty much any HTTP header or request data, and a whole lot more. People and bots are putting the attack string everywhere just to see if they can get an application to process the attack payload through log4j.
What can we learn from all this?
Track software components for security updates.
The biggest delay in patching log4j was caused by a lack of awareness of log4j’s location within an organization’s infrastructure.
Vulnerability management is typically concerned about the packages and applications running, not so much the components therein. Tracking the security of libraries and components is an emerging field and something Patchstack specializes in.
If the defenders have detailed insight into internal components, their versions, and potential security risks in the components, then it is much easier to track them down and ensure they are patched.
The timeline you have to patch
It took only a few days after the patch was released before this vulnerability was weaponized, and a few days after that before close to everyone knew about the risk.
This is an important metric to track, as the time it takes you to patch a system makes the difference between getting compromised or not. If you patch the same day, you are likely safe. If you patch on a schedule, maybe weekly or slower, then you may want to look into how to improve your processes or look into how to apply vPatches to buy you some time.
The conclusion to remove risky functionality
The log4j developers chose to re-evaluate their patch, and on the 13th decided that the functionality that JNDI provided was not worth the risk. So they ultimately removed the functionality altogether from being enabled by default.
I agree with this decision, because, sometimes a feature brings on too high of a risk compared to its value. Something WordPress site owners may want to consider, if they’re not actively using a component on a website, maybe it’s better to remove it entirely?
Thanks and appreciation
This week’s thanks go out to all of the defenders who have been working tirelessly to hunt down, and patch, their Java applications running vulnerable versions of log4j. Your efforts do not go unnoticed.
Thanks also are given to the plugin developers in the WordPress ecosystem who released patches for security vulnerabilities this week.
And a special thank you to the Patchstack Alliance (formerly Red Team) who are finding and reporting these vulnerabilities responsibly before they get abused by malicious parties.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update! Thank you for reading or listening.
