Note on CVE-2021-44228 and CVE-2021-45046: 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).
Fortunately, the solutions described below address both CVE-2021-44228 and CVE-2021-45046, without the need to update the library and restart your Java instance.
There’s so much data going around about Log4Shell or CVE-2021-44228, so we wanted to follow up on our previous blog post.
The most recommended way to handle this situation is of course – using the official vendors’ advisories and patching the components for their fixed versions.
But even with all the remediation guidelines provided by vendors, many organizations will not be able to apply the appropriate security patches for their various applications – neither in the near future, nor at all.
Many of us are acutely aware of how hard it is to shut down production systems for maintenance, even for a short period of time.
This is especially common for companies’ critical production environments. In many cases they cannot afford loss of availability to their applications, and when we talk about patching a library, there is always the risk for potential dependency errors.
We will mention below two workarounds for CVE-2021-44228 that might be useful for those who find themselves lost with all the recommendations around the internet.
Those in our industry will know that many times – or even most of the time – mitigating actions don’t simply don’t work as expected, especially the first time. We urge you to test these workarounds on different test environments before production, to avoid unintended results.
Workarounds for CVE-2021-44228
Log4HotPatch by Corretto
Created first by simonis and later maintained in a new project by Corretto, the Amazon Corretto team provides an efficient way to remediate the Log4Shell without downtime for a Java-based application or service. The mitigation process demands actively building and running a simple Java program that will patch the vulnerable application in runtime.
The author supplies all the details for how to build and run the program. All you need to do is access the application host machine and the installed Java version on the machine on which the application is located.
How does it work?
The workaround utilizes Java Instrumentation API to inject a Java agent into Java applications and intercept them.
After the agent is attached to a JVM (Java Virtual Machine), the agent implements the ClassFileTransfomer interface class to retransform (or manipulate) the loaded JndiLookup class.
With the help of ASM library, the agent manipulates the vulnerable method Lookup() bytecodes and avoids the well-discussed dangerous JNDI lookup action.
If you cannot identify the JVM processes on the operating system, don’t worry, the program will request from the machine the current running JVMs’ process IDs.
Who is it good for?
As we mentioned above, if you cannot afford downtime for your application, and you can access the application host machine – this solution may fit your needs.
Caveats or disclaimers?
Remember the above demand for validating the installed Java version? Well, there are two main reasons.
First, the patch was tested on a Linux host with dedicated JDKs that are mentioned in the repository – so tread carefully and perform extra validation actions on this solution if your version is different.
Second, it is mentioned in the repository – and we also mention it here – that you might encounter some obstacles with building and running the program in case you use JDK version 17.
Why? One of the enhancements in the latest JDK 17 is strong encapsulation for almost all internal Java APIs, which restricts access to their classes. As a result, the command line option —illegal-access won’t help you anymore and you’ll need to explicitly export classes.
Logout4Shell by Cybereason
While most of us struggled with how to patch running vulnerable applications without restarting them, Cybereason thought to take the vulnerability and exploit it to immediate mitigation. We found it a very innovative and efficient way to deal with this particular CVE.
How does it work?
Let’s do a quick recap.
Successful exploitation of the vulnerability causes the vulnerable application to query a LDAP (Lightweight Directory Access Protocol) server for malicious Java class details (name, code base location, etc.), and then pull this Java class file and load it to the application.
With this workaround, you run your own LDAP and web servers, and instead of downloading a malicious Java class, the application will download and load the Log4jRCE.java class file that will patch the application instance.
How does the patch work? Just review the README file. Cybereason’s covers everything you need to know about the inner processes of this class.
Who is it good for?
This solution is a good choice for those who cannot access the application host machine. But an important prerequisite is that you must know the exact vulnerable points of your application (i.e. how to exploit the application) because Logout4Shell cannot determine this by itself.
One more point to stress is that Logout4Shell could be excellent for mitigation on a large scale. Meaning if your organization has a large number of vulnerable applications, patching with Logout4Shell is very convenient for automation.
Caveats or disclaimers?
Not much. Just follow Cybereason’s disclaimer in the project’s repository.
Stay ahead of CVE-2021-44228 – or any vulnerability
Dealing with CVE-2021-44228 is a race against time – threat actors around the globe scan the internet for targets and work to exploit them. It’s important to know your limitations and act as quickly as possible.
For the latest vulnerability information, fixes and actions, check out Vulcan Remedy Cloud – the free, comprehensive resource for everything you need to know about how to fix the latest CVEs.
The Vulcan Cyber platform is a valuable partner in mitigating the continuing threat of the Log4j vulnerabilities. See it in action.
Disclaimer: Vulcan Cyber is not responsible for the reliability of the remedies, patches, and mitigating actions above from the above-mentioned projects. This should go without saying, but please review and test in non–production environments.
