Understanding the Log4j Exploit


An Update on an Evolving Cybersecurity Situation

Without a doubt, we’re only beginning to see the implications of one of the most insidious security exploits in recent memory: The Log4j vulnerability in unpatched Apache web servers running this common error-logging backend software. In fact, it’s one of the worst exploits ever discovered – and it happened just in time for the 2021 holiday season, too, when many hacker groups usually unveil new tactics, techniques, and procedures to use when less people are in the office to notice malicious activities. 

However, we understand that not everyone has the technological familiarity into why a Log4j-hacked web server is one of the worst situations for a company. We’ve put together a quick update on this evolving situation to keep you informed and provide insight into why this was and still is such a big issue.

What’s the deal with Log4j vulnerability in the first place?

For starters, we’ll give you the raw facts about what’s going on with Log4j at a high-level According to the emergency directive issued by the Cybersecurity Infrastructure Security Agency (CISA) on December 17th, 2021:

 

The “exploitation of one of these vulnerabilities allows an unauthenticated attacker to execute code on a server remotely. Successful exploitation can occur even if the software accepting data input is not written in Java; such software is able to pass malicious strings to other (back end) systems that are written in Java.”

 

Cybersecurity researchers discover hundreds of vulnerabilities every month, but we’ll explore why this specific one requires immediate action and spurred as much news as it did.

This is one of the worst exploits discovered in recent years. Why?

In short, anyone with a basic working knowledge of web code can use Log4j to run arbitrary code remotely on a server on the other side of the planet – and with no user interaction at all. This means that if there is a vulnerable web application that can be accessed via the internet, an attacker can inject their own code into the application without requiring administrative rights to the system. What attackers inject can range in severity, but once compromised the attacker has free reign over the system to do anything they may want, and if an admin was not reviewing for this activity, likely the attacker would go unnoticed.

 

You may not know it, but any device that connects to the internet has a backend system, so when malicious actors discover a flaw that impacts a large range of systems, they have free reign to ply their trade until someone alerts the IT community. In this case, a member of the Alibaba Cloud Security Team discovered the flaw and reported it to Apache.

Are hackers and known cybergangs already using the exploit?

Yes. There are numerous public reports of potential Log4j-related cyberattacks, mainly with a new ransomware strain called Khonsari. This ransomware itself may be basic, but its use may indicate that hackers are using it as a probing tool rather than a blatant exploit, which is a typical tactic when zero-day exploits, an exploit previously not known the manufacturer or the public, become public.

 

But this is only one example, due to timeframe of this exploit, at this point attackers will be scanning for vulnerable systems that are still in the wild to use them as easy targets. Due to the nature of this exploit, it can be assumed that anything an attacker wants to load to a system, they will be able to. This carries a large risk in organizations that have poor patch management practices, or do not know what is currently on their systems. This will likely remain a common initial attack vector, a way attackers get into your environments, for many years to come.

 

Interestingly, there have also been cryptojacking attacks, the embedding of software on vulnerable systems to “mine” cryptocurrency, that many believe stem from this vulnerability.

How much damage might this vulnerability cause?

It’s an evolving situation. Time isn’t on the good guys’ side because once infosec pros identify an exploit in the wild, it’s a reasonable assumption that sophisticated malware authors are already using it too.

 

Although patches have been released to fix portions of the vulnerability, and even some of the functionality of the application removed to stop the exploit, this is only efficacious if the patches are applied. The true damage that this will cause will be seen for many years to come, as companies are hit by this vulnerability because they either do not have good patching practices in place, or they do not know they are vulnerable.

 

Even though we are past the explosive release of this vulnerability, do not assume that you are safe from it. Ensure that your company has good cyber hygiene practices in place, and that patches are applied to applications, especially externally facing systems, as soon as you can. It is also recommended that companies implement a vulnerability management program, that involves regular scanning of their environments to alert when issues like this arise.

Read more about technology trends and information on our blog.

For more information on how Bridgehead IT can support your business through the evolving technological landscape, contact us.

(210) 477-7900

emergency directive issued by the Cybersecurity Infrastructure Security Agency (CISA) on december 17th, 2021:

The “exploitation of one of these vulnerabilities allows an unauthenticated attacker to execute code on a server remotely. Successful exploitation can occur even if the software accepting data input is not written in Java; such software is able to pass malicious strings to other (back end) systems that are written in Java.”