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?
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”.
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
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
Their are a few ways to detect if this vulnerability is being exploited in your system:
- 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.
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 = false
A 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.
It is a long established fact that a reader will be distracted