The tech world was on the receiving end of a rude wake-up call this past week when a vulnerability affecting Apache Log4j versions 2.0 to 2.14.1 was disclosed on the project’s GitHub page.
This was a big deal, considering that a third of all web servers around the world use Apache. The flaw, dubbed Log4Shell, immediately became a top priority among IT teams.
The Cyber Security Agency of Singapore (CSA) has sounded the alarm, too, urging businesses to patch their systems. The agency is also working with Critical Information Infrastructure (CII) sectors (energy, water, banking & finance, to name a few) to shore up defences and mitigate any cyber-attacks, which points to the severity of the vulnerability.
What is Log4j
For the uninitiated, Log4j operates as an open-source Java logging library that is used in a vast range of software applications and services.
Log4Shell, then, allows threat actors to potentially take control of any Java-based, internet-facing server and engage in remote code execution (RCE) attacks.
See also: Testing QA New Section BDC Feature Winner 1
The issue lies in Log4j itself, specifically the way Java Naming and Director Interface (JNDI) can ‘look up’ commands, as well as how they are embedded in the data structure. This is not a wholly unique flaw to Log4j logs per se.
After all, other logging databases, such as Splunk, use different data structures and have different APIs and tools, making them similarly exposed to similar types of vulnerabilities. However, in the case of Log4Shell, other databases simply aren’t the target here — Log4j is.
The fallout from Log4Shell
See also: Unpublished article shouldnt be accessible testing
In a relatively short time, Log4Shell made itself known across the Internet.
Within the first 24 hours of the flaw being disclosed on GitHub, reports of threat actors started pouring in. Mass Internet scanning began almost immediately to identify potential targets.
What’s worse, a second vulnerability was discovered shortly after. Threat actors in countries like China and Iran leveraged the vulnerability to conduct widespread ransomware attacks.
In fact, threat actors were so quick to take advantage of the situation that the trend is expected to continue, as hackers ramp up their ransomware attempts.
Organisations have not been sitting idle, either. In fact, many have been rushing to patch and update their existing Apache implementations in order to address the vulnerability.
However, no matter the mitigation measures that have been shared thus far, hackers have been able to stay one step ahead. A researcher discovered a bypass for the built-in security feature, which prevents exploitation of the Log4j vulnerability in newer Java versions. With the odds stacked against organisations, it seems like nobody is safe — at least not for long.
Amid all the bad news, there were reasons to remain optimistic.
To stay ahead of the latest tech trends, click here for DigitalEdge Section
Developers created Log4j version 2.16.0, which completely disables JNDI by default. With that said, it is critical for organisations to assess the update, and it takes time to patch systems.
Moreover, it may not even be possible to patch some systems easily, if at all. In the meantime, organisations must assume that every system running a version of Log4j 2.16.0 or earlier is already vulnerable.
Positive news has also come in the form of a ‘vaccine’, known as LogOut4Shell.
Developed by cybersecurity researchers, this temporary workaround uses the flaw itself to set the flag that turns it off. Furthermore, LogOut4Shell prevents the exploits of Log4Shell, thus buying time for organisations to perform patches and updates.
As hackers continue to find new ways to exploit the system, this so-called ‘vaccine’ has become even more critical, as it disables the entire JNDI mechanism, prevents every scenario we have seen so far, as well as buys time for security teams to assess, test and patch.
The longtail impact of Log4Shell
Already, reports show that more than 1,000 attacks are happening every second on the internet. Cloudflare, too, revealed that attackers have been on the move, adapting quickly to mitigation measures and evading blocking by web application firewalls. It’s a cat-and-mouse game that will, unfortunately, have long-term repercussions.
The real question, though, is this: what are threat actors after? When they exploit Log4Shell, what are they trying to achieve?
We know that a successful exploit grants the attacker control of the affected system. However, for smart attackers, they tend not to show their intentions right away. Instead, many of them would gain entrance to the system, set up backdoors and ready them for future attacks. In short, it is a land grab for now, and they are merely prepping for a greater attack in the future.
In the meantime, focus on security hygiene: test to see if the organisation is vulnerable. Apply vaccines and update vulnerable systems, perform threat hunting on indicators of behaviour that reveal potential or ongoing malicious activity, stay vigilant and get ready to respond in the next wave of attack to protect business resilience operations.
Chin Kiat Chim is the APJ Vice President, Field CSO at Cybereason
Photo: Unsplash
