The Log4Shell vulnerability: A postmortem

Did you miss a session from the Future of Work Summit? Visit our Future of Work Summit on-demand library to stream.

This article was provided by Ariel Asraf, CEO of Choralics

Log4shell Weakness was a fitting, panicked ending that was already a difficult year. Now that the initial panic is gone, and there are some trial and testing methods to detect and mitigate the vulnerability – it is important to stop and think about what happened in the last few weeks of 2021. What went well and what could have gone better. What is a better way than a postmortem?

Log4shell vulnerability overview and effect

Log4shell vulnerabilities were vulnerabilities between Log4j2’s JNDI lookup functionality, version 2.0 and 2.14. This allowed the attacker, who had control over what was printed in the log (for example, if the server printed an HTTP header), to execute any code they liked.

Log4j2 is ubiquitous in applications and libraries on which they rely, meaning that many applications are using it without using Log4j2. Applications not written in Java are also hosted in a web container, meaning the project has no apparent reliance on Log4j2 and may still be open. This has had a far-reaching effect on almost all industries.

The root cause of Log4shell vulnerability

The root cause was not a single incident for a problem like this. The original feature entered the release without a security check. Log4j2’s main contributors, no doubt, reflect on how they can improve their security evaluation processes.

Libraries like Log4j2 are also large and complex, meaning that most teams are not using sensitive JNDI lookup functionality. This malicious code makes its way due to the monopolistic nature of these dependencies. A more integrated approach to Log4j2 efficiency could significantly reduce the potential impact of Log4j2 vulnerabilities. However, it comes at the expense of ease of use for those engineers who relied on it.

So, what happened?

The industry response to Log4shell vulnerability was immediate and effective. Open source communities created resources, drafted blog posts, and implemented patches. This effort enabled organizations to actively mitigate problems rather than stay away from the curve and react arrogantly.

In addition, the major contributors to the Log4j2 library were extremely diligent in their publications. While it was a bit of a chore (more on this later), they quickly repeated a sensible release that was backwards compatible with all but poor performance.

This positivity speaks to the glorious beauty of open source philosophy-focused communities of experts working for a vast pool of organizations. Sometimes they make mistakes, just like any engineering effort, but those mistakes are quickly detected and corrected.

Isn’t that so good?

The obvious problem with Log4shell vulnerability is its nature. The code was backed up in thousands of applications, and each needed to be reduced, tested and deployed in production. For some organizations, this was normal. For others, they were still working on a slow release cycle, and this sudden change would greatly disrupt the way they worked.

There was also a bit of confusion about the true mitigation path during the incident as the understanding of Log4shell vulnerability was growing. Check out the timeline below to get a taste of this confusion. This meant that organizations that were active were then forced to go back and restart.

Timeline of events

December 9, 2021

The original Log4Shell vulnerability was found. It was suggested to reduce this problem by setting up LOG4J_FORMAT_MSG_NO_LOOKUPS or setting the corresponding configuration flag. At the same time, version 2.15 was released which disabled this functionality by default.

December 14, 2021

Version 2.15 of Log4j had another vulnerability. This was a “refusal of service” vulnerability, enabling malicious agents to slow down and eventually block targeted systems. Setting the configuration value has changed the advice to the newly released version 2.16. This CVE was initially rated relatively
The low, 3.7 / 10, but was re-scored at 9.8 / 10, meant that organizations that made more prudent risk-based decisions were forced to re-pivot and relocate.

December 17, 2021

Version 2.16 saw a third vulnerability. This was the second “denial of service” attack which had the same effect as the previous vulnerability. To reduce this, version 2.17 was released. Due to the relatively high score given in this CVE, 7.5 / 10, organizations were advised to transfer to version 2.17 as soon as possible.

December 28, 2021

Version 2.17 saw a fourth vulnerability. This vulnerability was less severe than its predecessor (6.6 / 10) and other parts of the target system already needed to be compromised. This latest vulnerability requires that the configuration be loaded from a remote server, which means that it will not be affected as extensively. This led to the release of 2.17.1.

So what’s next

There are some serious questions that need to be asked. First, the method of dependency management is appropriate for the purpose in the world of microservices, where similar dependencies are replicated in dozens, hundreds, or perhaps thousands of instances.

Second, do monolithic libraries need to be relocated to smaller, composable libraries that bring a lot of unwanted functionality? Most of the victims of this vulnerability did not use the JNDI lookup code in the first place. Engineers regularly smuggle in unnecessary and potentially dangerous code torrents into their binaries, especially for languages ​​like Java which often favors significant dependencies that can be heavily configured.

Ultimately, these criticisms need to be accompanied by some measure of acceptance. There will be zero-day vulnerabilities. That is the inevitable consequence of sharing code, which is undoubtedly risky. Your challenge is to decide which processes, technologies and tooling you want to take to the next level.

The trick is responding quickly, and there are things we can do to bring vulnerabilities to our immediate attention.

  • Automatic Log4shell vulnerability scan

You can use libraries like Snyk to automatically detect vulnerabilities in your dependencies. You can also configure this to automatically fail your CI / CD pipelines if you want to prevent critical vulnerabilities from being deployed as well. This is a very strong but powerful method to prevent problems from coming out.

The CVE Twitter feed is the best way for you to stay on top as vulnerabilities are released. This may be a lot of information for you to process, but you’ll find it awesome by all the likes and retweets.

Everything in all

Those few weeks were complicated for engineering teams around the world. However, if this vulnerability proves anything, the open source community is resilient, highly responsive and diligent to failure. While this was a serious weakness that will undoubtedly persist for years to come, it was quickly reduced and incorporated by a quick response from the community of focused and diligent engineers.

Ariel Asraf is the CEO of Choralics


Welcome to the VentureBeat community!

DataDecisionMakers is where experts, including tech people working on data, can share data-related insights and innovations.

If you would like to read about the latest ideas and latest information, best practices and the future of data and data tech, join us at DataDecisionMakers.

You might even consider contributing to your own article!

Read more from DataDecisionMakers

Similar Posts

Leave a Reply

Your email address will not be published.