by Iryna Yamborska
What is Log4Shell?
The Log4Shell is a vulnerability in the open-source logging library, Log4j version 2, which is used by millions of Java-based applications/servers to log error messages. Such digital giants as Tesla, Twitter, Apple iCloud, Amazon, and millions of other companies use the Log4j library.
There is a lookup substitution function in the Log4j library. Log4Shell vulnerability exists because lookup substitutions are not protected enough when dealing with user-controlled input. Unauthenticated users can exploit this vulnerability via a web request to execute arbitrary code with the permission level of the running Java process.
The first worldwide famous target was Minecraft. On December 10th, people started sharing videos showing that, while playing online, they could just insert code to chat on the server and seize power over the server. But most likely, everything started earlier. Cloudflare -Content Delivery Network and DDoS mitigation services provider – checked their systems and noticed that the first attack on their clients with Log4Shell vulnerability had been tried to conduct on December 1st.
What makes Log4j uniquely dangerous even though you seem protected
One more point which makes Log4Shell as dangerous as it is the simplicity of exploitation. Even “junior” hackers can use this exploit. To gain control over the victim’s system, a hacker inserts the code anywhere this library handles – fill the form the website, modify website URI or Browser user-agent, or text in the support chat – and it will lead to code execution.
The whole java-world is trying to deal with Log4Shell and emphasize that it is the highest possible priority for all-sized businesses. Cisco, Apple iCloud, Microsoft, and so many other huge technology companies have already stated that some of their systems were vulnerable, but they are fixing it. But for small-sized companies without a cybersecurity department, it might be quite hard to mitigate the attack independently.
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.
Update
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.
Penetration Testing
After remediating this vulnerability with your DevOps team, it is worth running a penetration test to ensure external and internal systems are patched correctly, and other old vulnerabilities are not exploitable. Generally, pentesters will do the same as hackers do – try to conduct an attack on the vulnerable system. But don’t forget about other vulnerabilities that existed before Log4Shell and didn’t disappear. It is the same as having 12 bad teeth, but to treat only 1 of them. So, conducting a pentest, it is better not to choose only one vulnerability test.
Conclusion
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.
Contact us
The UnderDefense Threat Detection and Response (MDR services) 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.