AppSec and software community respond to Log4j

Application security and open source software communities have responded to the Java Log4j vulnerability challenge, patching the software, sharing information, and providing mitigations and tools. We’re not out of the woods yet, but their actions so far have been inspiring.

What happened?

The new Log4j vulnerability, dubbed Log4Shell, has put the world on red alert. The vulnerability was first reported to the Apache Software Foundation on November 24, 2021 by an employee of the Alibaba Cloud security team and an exploit was anonymously posted to Twitter on December 9, 2021.

Shortly after the exploit was published, active attacks increased significantly. Evidence quickly followed that exploits using this vulnerability had been active in the wild for up to two weeks before it became widely known. Given a public exploit for this vulnerability, the situation turned into an arms race over the weekend of December 10, 2021 to December 12, 2021 with many members of the security community, including our teams, passing by. their weekends and the following late nights rushing to get a better understanding of how the vulnerability works and how best to detect and protect yourself from it.

How bad is it?

This Log4j vulnerability is as severe as it gets. In a briefing, America’s top cybersecurity defense official Jen Easterly said the flaw is “one of the most serious I have seen in my entire career, if not the most serious.”

Due to the ease of exploitation of this vulnerability, the possible impact of a successful exploit, and the widespread use of Log4j (the vulnerable Java library), the vulnerability was assigned a maximum criticality score of 10 in the common vulnerability scoring system (CVSS).

It is likely that this vulnerability will affect hundreds of thousands of organizations and hundreds of millions of devices worldwide. Like other high impact vulnerabilities such as Heartbleed and Shellshock, the number of known vulnerable products will continue to increase in the weeks and months to come, and the impact of this vulnerability will last for years.

Vulnerability summary

This vulnerability is designated CVE-2021-44228 by MITER and has been dubbed “Log4Shell” by the application security community.

At a high level, vulnerability combines:

  • The “search” functionality of the Apache Log4j 2.x package
  • The Java Naming and Directory Interface (JNDI) API to run a Java object
  • LDAP and RMI, used to retrieve remote Java objects
  • DNS query + variable resolution to extract sensitive data.

These are combined into a malicious string which, when scanned by a vulnerable Log4j library – in the simplest case – can be used to read environment variables from the attacked system to retrieve sensitive information and, in worst case scenario, can be used for remote code execution (RCE) leading to full system support.

There are already plenty of good articles like this one discuss the technical details of what is currently known about this vulnerability, so we will not go into it here.

What is at risk?

This vulnerability can quite easily give an attacker the possibility to execute arbitrary code on the compromised system (called remote code execution, or RCE). The ability to perform an RCE on a target system is an attacker’s goal. Even though the remote command will run with the restricted privileges that Log4j runs with, once an attacker has gained a foothold in a system, they are much more likely to be able to elevate their privileges and do more damage.

But it is not only the systems directly attacked that are at risk.

Not just Edge systems

The vulnerability can also give the attacker access to any of the call chain systems on the path to the target Log4j system (provided that they also log in using the vulnerable Log4j logging library ). And this system can be a backend system behind a firewall, an intermediary third-party service, a client application, an IoT device, a mobile application, etc. Basically wherever the Log4j library is used to capture logs.

And that’s part of what makes this vulnerability so dangerous. An attacker does not need to be precise in his targeting. They can send their exploit payload at random and wait for an affected system, even behind perimeter protections like WAFs, API gateways, and firewalls, to come back to their malicious server to execute the malicious code. Then they will know they have a successful victim that they can control remotely.

Data is also at risk

So definitely if your software is running a vulnerable Log4j library you are at risk, but what if it is not? Are you safe from being exploited?

Unfortunately the answer is no, you are still not safe. Your communications and data are always at risk. For example, let’s say you have a Go service that shares data with a Python service that shares data with a Java service that uses Log4j. An attacker sends an attack string to your Go service which forwards it to the Python service which forwards it to the Java service.

While your Go and Python services are not vulnerable, the Java service that uses Log4j could. Now, if this Java service managed any of your sensitive data, that sensitive data could now be compromised.


There are generally three mitigation measures that everyone should consider implementing as soon as possible to protect their applications from this Log4j vulnerability. These are not mutually exclusive and we recommend practicing defense in depth by implementing several of them.


The first mitigation measure is to protect all your applications in order to save time to put in place the other mitigation measures. Other mitigation measures require knowing where you are vulnerable and then implementing the changes. To make room for this discovery, set up a shield that can detect and block attacks by identifying their signature at runtime and stopping traffic.

While this is the easiest, fastest, and least intrusive mitigation (no changes to the code or application configuration), the downside is that it may not detect all of them. associated exploits or produce a high number of false positives. This of course depends on the quality of your execution defense solution.


The best and most efficient solution, which everyone should implement as soon as possible, is to patch their Log4j libraries to the latest non-vulnerable version (Log4j 2.17.0 at the time of writing this article). This is the only real resolution to this vulnerability that will persist.

However, this is the most difficult mitigation to achieve in depth, as the vulnerable Log4j library can be hidden deep in your application in different ways and finding it can be very difficult. A good software composition analysis (SCA) tool, such as Snyk, can help to speed up and simplify this process in the development phase.

However, even once vulnerable libraries are found, it can take time to test changes everywhere before they go into production. This is why the “shield” step is important.


The last, but not the least, mitigation is to implement a set of temporary countermeasures that essentially disable vulnerable abilities either by disabling lookups (by setting a configuration in environment variables or in invocation properties Java) or by removing the JNDI libraries from Log4j package altogether. In any case, these modifications can be interrupted for some applications and can be undone accidentally and without knowing it, since these are not the default configurations.

Cross-functional communities come together

The software and combined application security communities have collectively answered the call to address this vulnerability and continue to do so. I’m extremely proud of how quickly these two communities came together and sacrificed time and sleep to research, inform, build and share tools, update packages, and help protect apps in the days following the release. publication of the first exploit. Their efforts, their collaboration and the sharing of information are inspiring.

And we can’t let go. We have to keep pushing to patch every Log4j package everywhere. Today more than ever, we must continue to work together for secure software.

In an increasingly interconnected world, we must work as one community (development, security and operations) to protect not only ourselves, but also our neighbors and their neighbors who all constitute our largest software ecosystem.

Next steps

As we come out of this crisis – and we will be come out of this crisis — we will have the opportunity to apply lessons learned and reduce our exposure to future vulnerabilities. I think there are five things we need to do as industry leaders, and by ‘we’ I mean business, government, researchers, and suppliers alike:

  • First of all, we need to realize that this is really a form of attack at the API level, and we need to collaborate and share the lessons learned from this crisis.
  • Second, we need to collectively create a framework of educational resources to help educate the industry on how to mitigate and block vulnerabilities in APIs like this.
  • Third, we need to educate engineers on API security design and coding models to effectively shift API security to the left.
  • Fourth, we should increase our investment and commitment to bug bounty programs to uncover other hidden vulnerabilities early so that we can proactively fix and mitigate.
  • Fifth, vendors must develop tools that unify development, security, and operations into a single team to measure, manage, and improve their API security exposure.

I discuss more details of what we are doing to help solve our current crisis in a separate blog.

Recent articles by author

Sam D. Gomez