Log4Shell: How to Mitigate Log4j Vulnerability
(CVE-2021-44228, CVE-2021-45046, CVE-2021-4104)
by Iryna Yamborska
What is Log4Shell?
What makes Log4j uniquely dangerous even though you seem protected
Which Version is not affected?
How to Mitigate the Log4Shell Vulnerability? First aid actions
Put a high priority on your IT/DevOps on patching/mitigating this vulnerability. This is worth immediate effort.
It was previously thought that to be not vulnerable to Log4Shell, it is enough to turn off the lookup substitution function. But after a few days, it came across that it doesn’t work like that. Generally, the main action now (on December 20th) is to update the Log4J library to 2.17, which is supposed to be safe and has lookups turned off.
“To my satisfaction, our programs are not written in Java,” – you might think. But the point is that you may have hundreds of different systems, and they most likely are not developed by the inside team but developed by third parties – as it usually occurs. Therefore, you might not even know what is inside these systems. In this case, you should look at the product’s website or contact support for instructions on what to do to be safe.
Constant Security Monitoring
Log4Shell vulnerability is one of many, critical vulnerabilities that were found during the past ten years. And the situation is constantly evolving. The only way to see what is happening inside your system is to have 24×7 security monitoring and threat remediation and response. It will help you identify your vulnerable internal and external assets, patch production, review your log files for any Remote Command Execution attempts. Security analytics can see attempts to exploit Log4Shell vulnerability in the logs and block them*.
*Only in one client, the UnderDefense Managed Detection and Response team blocked six attempts to exploit this vulnerability only a week after the vulnerability was discovered.
A firewall is not a panacea
A firewall can block the attempts to exploit Log4Shell vulnerability, but this is not a panacea because the firewall main task is “not to pass such text.” But the exploitation of this vulnerability can vary. Hackers can easily make it so that the text does not match 100%, writing the same code using different methods, but still works WAF bypass. Accordingly, WAF is not enough but still shouldn’t be neglected.
Enable blocking on Web Application Firewall through AWS WAF, Cloudflare, or any other WAF you have, or directly on your web-server, reverse-proxy, load balancer.
Since December 9th, developers have thought that user can just turn off lookups in the Log4J library to fix the vulnerability. But a few days ago came across that this method doesn’t work, and millions of systems still stay vulnerable. Developers told to update the Log4J v2 library to 2.16. And people did it. But recently, the vulnerability was also found in 2.16, and now there is a 2.17 version, which is supposed to be safe.
The situation is evolving. Log4Shell is something new, something dangerous, and something that is not studied enough. We recommend you to have your finger on the pulse and take care of your cybersecurity.
The UnderDefense Threat Detection and Response (MDR) team is helping existing customers and partners deal with the critical Log4j vulnerability, which affects millions of popular Java-based applications/servers. If you need help at any stage of protecting your business from attacks on Log4Shell vulnerability, please, contact us via email at [email protected] or drop us a call at +1.929.999.5101, and we will take care.