Note on Log4shell: On December 14, 2021 Apache foundation released a new advisory for patching new CVE-2021-45046. This new security advisory instructs Log4j users to update their libraries’ versions to either 2.16.0 or 2.12.2 (depends on the Java version).
If you are about to follow the vendors’ advisories and update your product – great – you’re halfway there. Consider reviewing your vendors’ advisories to patch for the latest versions that will remediate both CVE-2021-44228 and CVE-2021-45046.
It’s not every day that we see proof-of-concept zero-Day exploits in gaming applications such as Minecraft. But that’s exactly what was happening with CVE-2021-44228. Known as Log4Shell or LogJam, this vulnerability, which first emerged in the popular RPG Minecraft, has since struck a huge number of ubiquitous apps, websites, and services.
The vulnerability was first reported to Apache on November 24, and since the first proof-of-concept was published on December 9, threat actors have been scanning the internet for opportunities.
Here’s everything you need to know:
What is the log4shell vulnerability?
This vulnerability is a critical unauthenticated RCE vulnerability that allows for full system takeover on systems with Log4j 2.0 up to 2.14.1. This vulnerability gives an attacker who manages to inject strings into the system logs the ability to gain code execution rights, meaning every free text field in the system could be an entry point for remote code execution.
It also impacts default configurations of a huge number of ubiquitous apps, websites, and services which use this logging framework by default.
Does it affect me?
Almost certainly. Even though it’s still early, we classify the Log4j vulnerability as very critical and among the top-three worst vulnerabilities of the decade. It wouldn’t be a stretch to say that every enterprise organization uses Java, and Log4j is one of the most popular logging frameworks for Java.
Connecting the dots, the impact of this vulnerability has the reach and potential to be substantial if mitigation efforts aren’t taken right away.
Has log4shell been actively exploited in the wild?
YES. The Log4j vulnerability is very easy to exploit and we’ve already seen verifiable reports that bad actors are actively running campaigns against some of the largest companies in the world.
Was I exploited?
While fully verifying past exploitation could be a very hard task, we would recommend any security or IT team to check their logs and search for any of the following keywords in order to check for past exploitations:
- jndi
- ldap
- rmi
- JndiLookup.class
Fixing the Log4shell vulnerability
Hopefully, every organization running Java has the ability to secure, configure and manage it. If Java is being used in production systems IT security teams must prioritize the risk and mitigation campaigns and follow remediation guidelines from the Apache Log4j project as soon as possible.
It is important to acknowledge that this vulnerability can be also exploited via a vulnerable third-party application. We urge you to check with each one of your vendors for their security advisory regarding this issue.
Alternatively, you check here for an index of these kinds of advisories
As a first step, we recommend blocking all outbound traffic over LDAP and RMI protocols in order to minimize the available attack surface.
We recommend that you browse our Remedy Cloud to see recommendations for how to mitigate this vulnerability.
The Log4Shell vulnerability is just the latest evidence of how important it is to keep up with emerging vulnerabilities. Get free access to thousands of vulnerabilities and get fix done with the Vulcan Cyber Remedy Cloud.
The Vulcan Cyber platform is a valuable partner in mitigating the continuing threat of the Log4j vulnerabilities. See it in action.
