Zero-day vulnerability found in open-source logging system Log4j poses a grave threat to the Internet and millions of devices at risk
Daniel Levi
Posted On December 15, 2021
On December 9, MITRE disclosed a previously unknown new zero-day vulnerability in the popular Java logging package log4j v2.x known as Log4Shell (CVE-2021-44228). Log4j is an open-source logging system widely used in a large number of enterprise systems. Hackers may already be taking advantage of this flaw as no one currently knows the extent of the vulnerability.
The US government and cybersecurity experts are also sounding the alarm the Log4j Zero-day vulnerability poses a grave threat to the Internet and could potentially affect millions of devices at risk as hackers attempt to drop ransomware.
According to MITRE, a not-for-profit company to provide engineering and technical guidance for the federal government, the vulnerability allows remote access to servers and code execution. Since then, security teams at companies large and small are now scrambling to patch a previously unknown vulnerability called Log4Shell, which has the potential to let hackers compromise millions of devices across the internet.
The log4j exploit was first noticed on sites hosting Minecraft servers, which discovered that attackers could trigger the vulnerability by posting chat messages. However, it appears that bad actors have already exploited the log4j vulnerability, according to security analysis company GreyNoise. In a post on Twitter, GreyNoise said:
“GreyNoise is detecting a sharply increasing number of hosts opportunistically exploiting Apache Log4J CVE-2021-44228. Exploitation occurring from ~100 distinct hosts, almost all of which are Tor exit nodes. Tags available to all users and customers now.”
GreyNoise is detecting a sharply increasing number of hosts opportunistically exploiting Apache Log4J CVE-2021-44228. Exploitation occurring from ~100 distinct hosts, almost all of which are Tor exit nodes. Tags available to all users and customers now. https://t.co/JF3tUkpIrq pic.twitter.com/CTMi0IWQ5j
— GreyNoise (@GreyNoiseIO) December 10, 2021
Marcus Hutchins, another prominent security researcher best known for halting the global WannaCry malware attack, also noted online that millions of applications would be affected. In a tweet, Hutchins said: “This log4j (CVE-2021-44228) vulnerability is extremely bad. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string. So far iCloud, Steam, and Minecraft have all been confirmed vulnerable.”
https://twitter.com/MalwareTechBlog/status/1469289471463944198
Meanwhile, since the news broke about a week ago, maintainers of the popular Java logging library Apache Log4j have rushed out a patch to fix the critical vulnerability that will prevent a remote code execution (RCE) in numerous Java-based applications.
Yesterday, US Cybersecurity and Infrastructure Security Agency (CISA) warned that hundreds of millions of devices are at risk from a newly revealed software vulnerability. “This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious,” Jen Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA) told CNN. She also added:
“We expect the vulnerability to be widely exploited by sophisticated actors and we have limited time to take necessary steps in order to reduce the likelihood of damaging incidents.”
Tech Startups will continue to monitor this news and keep you in the loop as things develop.
Below is a technical description of the Log4j2 vulnerability.
Apache Log4j2 <=2.14.1 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. In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
