Log4Shell - A Large-scale Exploitable RCE Vulnerability and Rising Dragon of Concern

This Type of Remote Code Execution RCE Vulnerability is Concerning

In less than a month, the Log4J vulnerability has literally ignited across the Internet.  Some even said the Internet was on fire and could experience a mini-meltdown as a result of this vulnerability.  

While there is some hype, the warnings are concerning - especially when nearly half of all global companies were said to have been probed within a few days of Log4J vulnerability disclosure according to Chekpoint and Computer Weekly. 

I like to refer to the Log4J vulnerability as analogous to a Dragon, in terms of fire and fury it could bring in the very near future.  I believe the fire caused by this Dragon will only grow.

What Makes the Log4J Vulnerability a Dragon?

The Log4J Vulnerability can result in Remote-code execution or “RCE”.  Any RCE is like a Dragon waiting to “hatch from its shell” and has the potential to become powerful and furious quickly.  In simplest terms, it provides a super-easy entry-point into an internal network by an external, non-privileged attacker. 

Anytime an RCE is exploited in the wild, this becomes an immediate priority to fix, above all others.  An RCE is also like an unlocked door into the network waiting to be opened to let a burglar in.  Attackers now have a trivial beachhead into the network that can get past firewalls and traverse laterally.   External hackers simply use code to trigger the door open. 

One might say, “just patch it and move on.”  Unfortunately, this one is not so simple because there is too much to be patched.  There are also too many unknowns, and this is why many in the security community predict this will take a long time to fix.

Widespread Log4J Attack Surface

Basically, when Java ads bragged that “Billions of Devices run Java”, by consequence this means if Java becomes vulnerable, billions of devices may also become vulnerable.  That’s pretty much what happened with the Log4J vulnerability.

In response, many scan tools have been created to help discover whether organizations are vulnerable.  I believe attackers will try to beat organizations to the punch and gain valuable attack telemetry first.  Defenders must discover their vulnerabilities before the attackers do, and prioritize their efforts quickly.  

Scope and Implications

A Log4J attack seems easy, and the attack surface is very large because a lot of programs use it.  The nature of Log4J seems to allow for many possibilities.  This includes "connected cars and charging stations" as well as IOT, and a wide variety of other possibilities.  

There is also talk of Java for microcontrollers, and it is said to be found in: Android apps, web apps, IoT, big data, desktop apps, game development, literally everywhere imaginable.  Java, like many coding languages in heavy use today, was developed nearly 30 years ago - long before there were thoughts about Advanced Persistent Threats (APTs) and advanced malware and exploits.  

The implications of this situation are obvious.  30 years ago, older programming languages were never originally designed for strong security of protection against the anticipated capabilities and creativity of APTs of the future.  This means security is a process of bolting on fixes afterwards, as a never ending series of patches. 

Since Java is so widespread, anytime it is impacted by patches and security issues, this also means there is the potential of effects that could impact all things that have a Java dependency.  Usually this is fixed by a single patch of a single issue or Java version that applies to all (one-to-many fix).  

However, things are not always so simple.  This is especially true with the Log4J vulnerability - which requires separate and individual patching everywhere Log4J is used, if a vulnerable version is used.  Essentially, one patch fixes only one of hundreds if not thousands of possibles.  

How a Threat to One Can Become a Threat to All

Knowing and finding every place this needs to be addressed is itself a severe challenge.  Java continues to be used widely and will probably continue to be.  There's just too much dependency on Java today.

This is how "a threat to one can easily become a threat to all".  This is a cybersecurity issue I've been concerned with for over 12 years now - an issue not easily solved, and seems to be getting worse.  We can only think of the implications for this type of vulnerability when we see things like this:

CISA has published Apache Log4j vulnerability guidance and provides a list of software known to be affected.  "Known to be" is key, there could be many others out there that will not be known unless it is attacked or tested.  Just take a look at these 8-year old slides about Java ubiquity and imagine every place this vulnerability has the potential to persist today.

A Potential Catalyst for Ransomware 3.0 and Beyond?

I also believe Log4J could be used to accelerate the rise of what might be called Ransomware 3.0 and 4.0 attacks.  Roger Grimes wrote his thoughts about such next-level ransomware attacks worth looking at.

I agree with some of these views regarding what’s to come in 2022 and beyond with newer ransomware attacks.  RCE exploits are a prime entry method.  Attackers are constantly innovating, and defenders must always keep up.  

APT and Ransomware groups are already using the Log4J vulnerability in their exploit chains to gain entry and move laterally per Bleeping Computer's Log4Shell article.

Fortunately for defenders, once attackers gain entry, the post-exploit kill chain is still at play (lateral movement, escalation of privilege, etc.)  This means established detection and response methods should still be followed and should work.

However, Log4J might bring surprises and unknowns.  Stealthy entry and lateral movement could keep defenders blind long enough to conduct successful attacks. 

Assume Breach Now and Fix Immediately!

Most experts are saying “assume breach” and “hunt for indicators of compromise” in the network.  That is also my advice, assume attackers are already inside the network.  The goal is to find their footholds and eradicate them from the network.

I call this one a Dragon in terms of scope, scale and potential.  Anytime I designate any cyber risk as a "Dragon" please accept that as code to consider prioritizing above other risk.  This doesn’t mean to ignore other vulnerabilities.  Other RCE and Ransomware attacks are still dangerous.  However, the Log4J vulnerability is being exploited and must also be addressed.

Step One – Seek to Understand

Seek to understand the basics of this vulnerability, so the scope and scale is understood.  This will help to understand what all is involved in order to manage the risk.

This includes understanding:

• What the attack is
• How it works and what’s possible 
• What’s known and what’s vulnerable 
• What’s not known
• What fixes the issues
• What doesn’t fix the issues
• How certain defenses may be bypassed
• What to look for in an attack
• What to prioritize first, second etc.
• How large-scale efforts may still not fix all
• Potential long-term and long-tail of issues
• How other attacks might arise based on this
• Longer-term solutions to fix root issues more effectively 

Getting you up to speed on this major vulnerability

Rather than try to repeat any lengthy explanations, I’d like to share three resources that helped me understand this quickly.   I recommend this vulnerability is understood by key IT and Cybersecurity staff assigned to fixing this issue.  To me, this level of engagement and situational awareness is essential.

One idea is for the CIO and CISO to hold an online session with the team and view these resources together, so everyone gets up to speed quickly.  This provides a forum to provide clarity, address any concerns and answer questions.  

I recommend setting the precedent at the human level to achieve a collective, organized and unified response.  In my opinion, this demonstrates top-down leadership and bottom-up involvement for accountability and awareness.

Visual Aids of Attacks and Defense – worth a thousand words

Visual from Juniper site depicting Log4J-based attack using LDAP

Visual from Juniper site depicting Log4J-based attack using RMI

Excellent Swiss CERT Visual of Attack and Defense Opportunities 

For more depth I recommend a highly-informative 20 minute YouTube Video:

I believe the individual in this video does a fantastic job explaining the Log4J vulnerability with the technical depth needed for IT and security professionals.  This beats scouring 50 articles on the topic to get up to speed quickly: 

What must be done to Slay the Log4J Dragon?

I believe there needs to be a Low friction approach to dealing with the Log4J Dragon.  This applies to any Dragon-like potential security scenario.  The approach should include:

• Initiating existing Incident Response processes first 
• Establishing a longer-term Tiger Team strategy for depth and a long-tail response
• Providing critical detection-first strategy in parallel with prevention (top-down)
• Testing and automation built into key processes for efficiency
• Tackling the long-tail of affected areas when appropriate (bottom-up approach)
• Incorporating relevant cyber threat intelligence to keep up with developments

Helping the Cybersecurity Community

I felt the need to contribute as well, to help the cybersecurity community tackle the issue.  My objective is to look at more effective ways of approaching the issue.  I hope to make this process manageable and help teams work smarter with less friction.  My approach is driven by experience in slaying other Cyber Dragons and accomplishing major tasks quickly.

I’ve put together a multi-pronged strategy and playbook to help everyone respond to the Log4J vulnerability.  My approach seeks to be strategic and comprehensive to tackle major cyber risk.  I’ll provide advice to keep things manageable using a "divide-and-conquer" approach.  

There's definitely a smart strategy to tackle this Log4J issue to "work smart" rather than just "work hard,"  For starters I’ll provide a rapid-response 1-page checklist to immediately tackle the Log4J / Log4Shell vulnerability.  Then I'll provide a more detailed 2-team / 2-part playbook divided up by major tasks.

My recommended playbook will consist of two parts:  

• An immediate top-down response using existing resources & incident response
• A longer-term bottom-up comprehensive response via Tiger Team (project-like)

Stay tuned for these playbooks, coming soon.

#RCE #Log4Shell #Infosec #Cybersecurity. - CYBER Y'ALL! - @CyberYall