Incident response teams across the world are scrambling to patch their systems against the latest Log4Shell vulnerability. This newly discovered zero-day vulnerability in the highly popular open-source Apache Log4j logging library enables attackers to gain full control of affected systems.

Systems and services that use the Java logging library, Apache Log4j versions 2.0 – 2.14.1 are all affected, including many well known applications from Twitter, Tesla, Apple, Minecraft and many more.

Unfortunately for Chief Product Security Officers (CPSOs) and Product Security Incident Response Teams (PSIRTs) at device manufacturers, they too may well be affected.

While media attention is focused on Log4Shell’s impact on popular enterprise and consumer web applications, Java is widely used in the embedded space, so the vulnerability’s impact can span cyber-physical systems such as vehicles, industrial equipment and medical devices. The real challenge is – which ones?

Log4Shell demonstrates once again the importance of software supply chain security and the devastating effects insecure open source code could have on the products and services we all use, especially in medical devices.

What’s the potential danger?

Dubbed Log4Shell, CVE-2021-44228 is a remote code execution (RCE) class vulnerability that received the maximum possible CVSS score of 10.0. If attackers manage to exploit it on a target system, they can execute arbitrary code and potentially take full control of the system in order to disrupt operational usage, leak sensitive info or enable a ransomware attack.

What makes it so dangerous is its ease of exploitation – even inexperienced hackers can successfully launch an attack using this vulnerability, as they only need to force the application to write a single string to the log, and after that they can upload their own code into the application (due to the message lookup substitution function). As such, Java applications with a user interface are highly susceptible for a Log4Shell attack.

Proofs of Concepts for the attacks are available on the Internet and are already used in the wild. Many companies report massive network scans for vulnerable applications as well as attacks on honeypots, and agencies all over the world urge users and admins to apply the recommended mitigations “immediately”.

This should not come as a surprise – Log4j is an extremely popular open source library used for over 20 years in numerous Java programs developed for both server and client applications, and as such, the attack surface is huge.

How to mitigate Log4Shell?

The good news is that the Apache Foundation has already issued patches for the vulnerability, but before moving on to patching, consider the following process to make sure you address all impacted devices.

Step 1 – Impact Assessment

First you’ll need to check if your products contain the vulnerable Log4j software packages, or if any of the software components you use are dependent on it. Having a repository that you can query with all of your product Software Bill-of-Materials (SBOM) would be really handy.

Once all affected products/devices have been identified you can move to the next step.

Step 2 – Patching or Reconfiguration

While patching may be difficult, it is still the number one action to take. Apache released patched versions and users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). Do note that guidance around this could change as more information is uncovered.

If patching is not possible for some reason, Apache suggested alternative workarounds (see here).

Step 3 – Continuous Monitoring

We often see that once a major vulnerability has been discovered, hackers find new ways of leveraging it or find similar (or related) security holes that could further compromise products (as is the case with CVE-2021-45046 and CVE-2021-45105 that where discovered shortly after the original Log4Shell vulnerability).

It is therefore recommended to monitor threats over time to ensure that the vulnerability has been eliminated.

Check out this video by Cybellum’s VP of Research, Roman Kesler, for more info.

Looking ahead

Third-party software used in connected devices such as medical devices, pose a variety of security challenges, made worse by the complexity of the software libraries, operating systems and drivers of proprietary, open-source, and commercial nature. Log4Shell is a painful example of these security challenges.

With Cybellum you can find affected devices in no time – see how in this short video clip.

Cybellum’s product security lifecycle management secures your software supply chain, with SBOMs and monitoring that validates the security of your device’s software from design through post-production.

Our experts can show you how. Talk to us or book a demo.

About the Author

Guy Gilam

Did you find this interesting? Share it with others:

< Back to Blog