Months on from a critical zero-day vulnerability being disclosed in the widely-used Java logging library Apache Log4j, a significant number of applications and servers are still vulnerable to cyberattacks because security patches haven’t been applied.
First detailed in December, the vulnerability (CVE-2021-44228) allows attackers to remotely execute code and gain access to systems that use Log4j.
Not only is the vulnerability relatively simple to take advantage of, but the ubiquitous nature of Log4j means that it’s embedded in a vast array of applications, services and enterprise software tools that are written in Java – and used by organisations and individuals around the world.
SEE: Google: Multiple hacking groups are using the war in Ukraine as a lure in phishing attempts
It’s why director of US cybersecurity and infrastructure agency CISA, Jen Easterly, described the vulnerability as “one of the most serious that I’ve seen in my entire career, if not the most serious”.
But despite critical warnings over the vulnerability, there’s still a large amount of Log4j instances operating in the wild that have yet to be patched and are still exposed to cyberattacks.
According to researchers at cybersecurity company Rezilion, there’s over 90,000 vulnerable internet-facing applications and more than 68,000 servers that are still publicly exposed.
The exposed instances were discovered by running searches through Internet of Things (IoT) search engine Shodan – and researchers warn that what’s been discovered is likely “just the tip of the iceberg” in terms of the actual vulnerable attack surface.
Log4j vulnerabilities leave organisations open to various cyberattacks from cyber criminals who can easily scan for vulnerable instances to exploit. Not long after Log4j was disclosed, attempts were made to deploy ransomware and crypto-mining malware on vulnerable servers.
State-sponsored hacking groups have also been spotted attempting to take advantage of Log4j vulnerabilities. These include Chinese state-sponsored espionage groups Hafnium and APT41, as well as Iranian-backed hacking groups APT35 and Tunnel Vision.
While state-sponsored hacking groups are likely to have deep pockets and plentiful resources, the ability to exploit common vulnerabilities is particularly useful as attacks are less likely to leave traces that could be tied to a specific hacking group.
One of the reasons why Log4j vulnerabilities are still lingering is because the flaw could be deeply ingrained in applications, to the extent that it might not even be clear that the Java logging library is even part of that system.
SEE: The Emotet botnet is back, and it has some new tricks to spread malware
But there are steps that can – and should – be taken to ensure the network is protected against attacks trying to exploit Log4j, the most vital of which is identifying and patching insecure instances of Log4j. The network should also be regularly examined to help identify potential vulnerabilities.
“You need to have processes in place that continuously monitor your environment for critical vulnerabilities with an emphasis on third-party code,” said the report.
If a vulnerable Log4j asset is identified, it’s recommended that information security teams act on the basis that the system has been compromised, to look for signs of potential malicious activity and to prepare to take action.
