Log4Shell Hacks On and On

Wikipedia states that Log4Shell was a zero-day vulnerability in Log4j, the popular Apache logging program. The key word is “was.” Log4Shell, even though there have been patches for it since Log4j2 2.17.1 was released in February, is still alive, well and causing trouble.

Indeed, the Cybersecurity and Infrastructure Security Agency (CISA) and the US Coast Guard Cyber Command (CGCYBER) have released a joint Cybersecurity Advisory (CSA) to warn us that hackers, including state-sponsored advanced persistent threat (APT) actors, are still exploiting CVE-2021-44228 (Log4Shell) in VMware Horizon and Unified Access Gateway (UAG).

Patches Yet to Be Applied

Why? Because organizations have still not applied the appropriate patches. Come on already! Get with it. This is code hidden in some undocumented programs! These are major VMware programs. VMware released the fixes months ago! Patch it already!

If you don’t, the CISA suggests you “treat all affected VMware systems as compromised.” This is a serious problem. In case you’ve forgotten, Log4Shell can make a system execute arbitrary code. And, with this, a hacker can take full control of your vulnerable systems.

I think we can all agree that this is bad news! Right!? Of course, right.

Besides just becoming root on your systems, Cisco Talos reports Log4Shell is being used to plant AvosLocker ransomware. Once an attacker establishes a foothold, they then move on to cause mischief in your Linux and Windows systems. It’s just one thing after another!

It’s not just VMware’s programs that are being exploited. Other programs, even new ones, are still open to Log4Shell attacks. As Dan Murphy, Invicti Security Distinguished Architect, said, “Modern software tends to be a patchwork of many disparate components, fixing Log4Shell vulnerabilities isn’t that simple. Sometimes these dependencies are transitive — a software developer adds an open source package that depends on a package that then depends on Log4j. Because of this, the developer has no idea they introduced a vulnerable component into their code.”

SBOMs Needed

There’s a reason why we really, really need Software Bills of Material (SBOM) for all our programs.

In addition, Murphy added, “the real danger with Log4Shell is older applications.” That’s because these “often live in dusty layers of application infrastructure, only invoked occasionally outside the typical execution flow.” Unless you’ve checked them for problems, the first thing you may know about something being off is when you run them once a month and an attacker charges in to exploit them.

If you have been compromised, the CISA recommends the following steps:

1. Isolate compromised system
2. Analyze the relevant log, data, and artifacts.
3. All software should be updated and patched.
4. Reduce the non-essential public-facing hosting service to restrict the attack surface and implement DMZ, strict network access control, and WAF to protect against attack.
5. Organizations are advised to implement best practices for identity and access management (IAM) by introducing multifactor authentication (MFA), enforcing strong passwords, and limited user access.

You know all that stuff you should have been doing all along. In the meantime, check and scan your code, old and new, for Log4Shell holes. They are still there and they’re just as dangerous as ever.