Log4Shell is a Remote Code Execution Class vulnerability denoted as CVE-2021-44228 disclosed as an exploit that affects millions of servers that run Java applications, or particularly the open-source Apache Log4j library.
If you are curious, a wide range of applications/servers and digital systems across the internet use Log4j for logging purposes. Even the back-end systems used by Steam, Minecraft, Cloudflare, and iCloud were found vulnerable.
Why is it one of the most significant vulnerabilities in recent times? Let me tell you more about it.
Yet Another Vulnerability, What’s the Big Deal?
If exploited by an attacker, the vulnerability can remotely allow them to add malware to your server. The CVSS severity level of this exploit is 10/10, which is the highest as it can go.
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.
Yes, it is the same harmless Apache Log4j library used by Java applications to log error messages, if you were wondering.
The vulnerability was discovered by Chen Zhaojun of Alibaba Cloud Security to Apache. It later came to the public spotlight as a zero-day vulnerability after Minecraft servers were found vulnerable to it.
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.
This vulnerability can be lurking anywhere in your server, even if the code does not face the network side of things. For instance, the place where your logs are kept.
Hence, it is not easy to detect the vulnerability considering many applications use Log4j to generate and keep logs. Even if the server is not 100% Java, there can be tiny instances where Log4j is used.
Overall, a vulnerability that is severely dangerous, easy to exploit, and time-consuming to detect, what a fine day for server administrators, right?
Log4Shell is a Security Nightmare
As of now, Log4Shell vulnerability is all over the internet. Of course, the major internet companies have the resources to patch it and resolve the issue quickly.
However, considering a proof-of-concept(PoC) is already available on GitHub, attackers are scrambling their way to find vulnerable systems to disrupt services. It does not matter whether it is Linux or Windows; it affects almost every server out there.
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.
Not to forget, we are also approaching the holiday week. So, several administrators and developers need to find the vulnerability in their systems and fix it as soon as possible.
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:
JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.
Recently, Apache pushed another update to Log4j that disabled the behavior that introduced the vulnerability and allowed remote attackers to execute code in your server.
So, it is safe to assume that you can only defend against this exploit for your applications and servers by upgrading to Apache Log4j 2.15.0 or 2.16.0 release. In either case, you can refer to some mitigation guides by cybersecurity companies like Sophos if you have a problem upgrading them right away.
Major tech companies have been working around the clock to get this sorted. However, it isn’t as easy as updating an app on a mobile device.
As of now, attackers have started compromising devices using this security flaw. We do not have an exact figure for it, but it may not be a peaceful holiday season for cybersecurity experts.