Contact us
Request demo →
Contact us
search
close

Log4j vulnerability: the timeline & security recommendations

by Cybersprint Blog 14 Dec 2021

Last Thursday, a critical vulnerability in Apache log4j was published. Log4j is a software component, meaning that it integrates with a lot of Java applications: it is their most commonly used logging framework. It’s used in thousands of different applications, leading to systems at risk on a largely unprecedented scale.

We are aware that information sources on the topic are abundant now. That’s a good thing, as collectively sharing information and security best practices will help all of us mitigate the risks faster. This short blog contains an overview of our insights based on a more detailed webinar, as presented by Pieter on Monday 13 December. We advise security specialists to consult the website of the Dutch NCSC, as they track the vulnerability and mitigation actions closely.


What makes the vulnerability so dangerous?

The vulnerability was given the highest CVSS score, as it can easily be exploited remotely and can directly lead to a full compromise of a server. It is actively being exploited on a global scale. The real impact of the vulnerability is yet to be determined, as organisations will have to investigate their own systems’ integrity. It will become clear how many servers have been compromised as the weeks progress, organisations share their findings, and – sadly inevitable – reports of incidents and ransomware attacks come in. We know that’s theoretically possible, so it will happen.

The hardest part of the whole event is being able to rule out the vulnerability in your systems. It’s very hard to detect all possible areas of risk in your attack surface, and make sure you’re covering all angles. That’s because of two reasons.

  1. The vulnerable component can really be anywhere
  2. It can be abused in a variety of ways

For the bad guys, it’s easy to identify vulnerable systems. Mass scanning will basically brute force the entire internet, resulting in a full list of who is actually vulnerable. And consequently, it’s also relatively easy to exploit once you have the right path.


Event timeline

In July 2013, the component that is now being exploited was introduced as a feature request in the Apache Log4j codebase. Remarkably enough, the first reports describing how to exploit the JNDI implementations related to this vulnerability originate from a presentation at Defcon 2016.

After that, it’s slightly unclear when the first exploitations in the wild started. There are some Github repositories containing research on how to exploit the vulnerability from March this year, but it’s uncertain whether or not it was already being linked to log4j for Java.

Then, the first real signs of the exploit were found on Minecraft servers on 1 December. People tried to hack players’ computers through the in-game chat function.

On 8 December, the full vulnerability was publicly disclosed. After that, it quickly became known that this wasn’t a vulnerability such as the Microsoft Exchange from earlier this year, but much much bigger.

The following days, we saw scanning activities increase to a global scale. Security practitioners were on full alert, trying to accurately assess the impact on their systems. What are the indications of compromise, which systems are (potentially) infected, which are safe, and what about the supply chain? Though a patch and several workarounds have been released since, answering these questions is taking a lot of time.

 

How to identify vulnerable systems

  • Make sure you have an accurate overview. Don’t just look at your own systems, but contact your venders too.
  • Scan your infrastructure both from the inside-out, as well as from the outside-in. This approach will eliminate blind spots. The NCSC advises to use the following scanning tools:

NOTE: We recommend thoroughly reviewing the scanning scripts prior to running them against your infrastructure so you are aware of any potential impact.


Our recommendations

  • First and foremost: assessing the impact and securing your systems has probably been very demanding over the past few days. Please make sure you take your breaks every now and then. Keep in mind this event is now a marathon, not a sprint.
  • The most straightforward mitigation action is to upgrade log4j to v2.15.0 where possible, or implement the mitigation measures.
  • When upgrading is not possible, implement the mitigations measures:
    • Version 2.10 or higher: Set Java variable property: log4j.formatMsgNoLookups=true
    • Version 2.7 or higher: Use %m{nolookups} in the PatternLayout configuration
    • Alternatively: remove the JndiLookup and JndiManager classes from the log4j-core jar file

For Pieter’s full, free webinar and our research insights, click the link below.Watch the webinar >>

Disinformation: a certainty in uncertain times

Since the beginning of the internet, we have seen a near, if not an exponential, surge of information sharing amongst users in cyberspace. Not long after, we saw how the emergence of social media ushered an access to public online platforms where other internet users worldwide could share, discuss, promote, and consume information, whether by deliberate choice or not.

read more

Threat Report: Remote vulnerability in Confluence, fixes available

On 2 June, 2022 a critical vulnerability was identified in Atlassian Confluence (CVE-2022-26134). The vulnerability in question relates to active exploitation of unauthenticated remote code execution in Confluence Data Center and Server; meaning that the vulnerability could lead to code being executed remotely.  

read more

Looking back on the 2021 vulnerability: Log4shell

In December 2021 a critical vulnerability surfaced named Log4shell within Log4j, a widely used logging tool for java applications. Log4j is used globally by computers running online services, which meant it impacted a multitude of people, organisations, and government organisations. Since then, multiple fixes have been implemented in the hope to avoid such an outbreak in the future.

read more

Do you have a question?

Our experts have the answers

Contact us