log4j security flaw

Log4j Security Flaw Puts Millions of Devices at Risk, But Not if They’re Protected by Firedome!

Recognized as possibly the most serious vulnerability that the Director of CISA has ever observed in her entire career, the Log4j security flaw has set waves in motion that are only starting to be felt across the cybersphere. Jen Easterly, Director of CISA (US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency) said, “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 damage.”

Log4j is a frequently used Java library for logging error messages in applications. This critical flaw lets an attacker remotely take control of another device connected to the internet if it’s running Log4j version 2.0 to 2.14.1.

How bad is bad?

This critical vulnerability received a severity score of 10 out of 10 for its ability to take descriptions from anywhere, the observance of it already being exploited in the wild, and that this vulnerability is present in hundreds of major enterprise products. Think of almost any product from software applications like IBM, Cisco, Oracle, and Splunk to cloud services like AWS, Google Cloud, and Microsoft Azure – they’re all susceptible. 

The Apache library is also found in security applications like VMware and a range of developer tools. Many of these companies are in the process of investigating the impact of the Log4j on their products and services and are looking to deploy immediate fixes. 

In response, the Apache Software Foundation has since released version 2.15.0 to mitigate the flaw. Yet product vendors and IT security teams will still be in a race against attackers to apply the fix in their products and have end-users update their devices before hackers get the chance to take advantage of the vulnerability.

What can be done to protect against the flaw?

Your first port of call is to immediately update to the latest version of Log4j 2.15.0, per the Apache foundation recommendation.

If it isn’t yet possible for you to upgrade, and you are still using any version between 2.10 and 2.1.41 you can apply the following mitigation that involves a configuration change to the vulnerable system.

Set the log4j2.formatMsgNoLookups system property to true, or set the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

For earlier releases, from 2.0-beta9 to 2.10.0, remove the JndiLookup class from the classpath

So, is there any good news?

Well, there is for those using devices protected by Firedome. None of Firedome’s components are impacted by this vulnerability, if attempted, the security agent will detect the launch of malicious code and stop the attack chain.

Any zero-day vulnerabilities, even those as severe as Log4j, can be detected by Firedome’s signature-based protection engine and behavioral-based protection engine, which is designed to detect remote code execution shellcodes attempts and block them. The Firedome agent constantly monitors for activities of every running process, alerting and responding to malicious behaviors spawned by vulnerable binaries, such as an execution of a malicious shellcode/binary via the Log4j attack surface.

Firedome’s cloud-based IoT threat intelligence database and security analytics system can also detect large-scale attacks, malicious IPs reaching devices, and unusual patterns that surface across the device fleet. The agent automatically responds to these threats and blocks them from penetrating further across the fleet.

In this case, it’s certainly recommended to push the update as soon as possible, because the best security practice is to eliminate the attack surface entirely. But the next best thing is for product managers to make sure their IoT devices are protected by Firedome because that will keep their devices protected this time, and the next time.

Book your personalized product demo today

We use cookies to ensure that we give you the best experience on our website.