The Apache Log4j vulnerability (CVE-2021-44228) affects somewhere between 0 and 3 billion-plus of the devices currently running Java. The vulnerability could allow a remote attacker to execute arbitrary code on a system with software using the log4j2 Java library to log information and messages.
The vulnerability was initially reported through Minecraft gaming sites. The sites were warning that threat actors could execute malicious code on servers and clients running the Java version of Minecraft by manipulating log messages via well-crafted chat messages. The security community quickly realized that the root cause was deeper and it had a far wider impact than just Minecraft. On December 9, the vulnerability started tacking as CVE-2021-44228 and coined as Log4Shell.
Why is it one of the most significant vulnerabilities in recent times?
CVE-2021-44228, also named Log4Shell or LogJam, is a Remote Code Execution (RCE) class vulnerability. If attackers manage to exploit it on one of the servers, they gain the ability to execute arbitrary code and potentially take full control of the system.
Unlike many other vulnerabilities, this is a bug (as a result of a feature) by design. So, it was a flaw in Log4j logging from the get-go. It is a highly dangerous exploit that even inexperienced hackers can follow through and affect hundreds of applications without much effort. To make things worse, it isn’t easy to detect whether your system is vulnerable or not.
Unfortunately, hundreds of millions devices are at risk. So, this is not a security flaw that can be fixed in a day or two. It will take months or years to identify every device that includes the vulnerable Log4j library, as per a report by CyberScoop.
Researchers at Microsoft have also warned about attacks attempting to take advantage of `Log4j` vulnerabilities, including a range of crypto-mining malware.
How Can You Prevent the Security Vulnerability?
Apache released the initial patch with Log4j v2.15.0 to prevent the attackers from executing arbitrary code as described officially, The simplest and most effective protection method is to install the most recent version of the library, 2.15.0 and install security solutions on your servers.
If for some reason updating the library is not possible, Apache Foundation recommends using one of the mitigation methods. In case of Log4J versions from 2.10 to 2.14.1, they advise setting the log4j2.formatMsgNoLookups system property, or setting the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.
To protect earlier releases of Log4j (from 2.0-beta9 to 2.10.0), the library developers recommend removing the JndiLookup class from the classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.