The Twelfth Day Of Tagsmas (2023): Unauthenticated Remote Code Execution (RCE) In Log4j (CVE-2021-44228) — a.k.a. Log4Shell

‍

We’re taking a slightly different format for this final day of Tagsmas, focusing on what has turned out to be a fairly pernicious vulnerability that will likely be a perennial threat to organizations of all shapes and sizes.

The Two-Year Anniversary of Log4j

As we careen past the two-year anniversary of CVE-2021-44228, it's essential to examine the events that have transpired and provide guidance for addressing this issue in 2024. The Log4j vulnerability, also known as Log4Shell, was discovered in December 2021 and significantly impacted organizations worldwide.

GreyNoise was at the forefront of capturing the initial onslaught of mass exploitation attempts, which we’ve detailed previously:

• Trending Internet Scanning on Apache Log4j Vulnerability
• Log4j Analysis — What to Do Before the Next Big One

As the annotated timeline shows, attackers wasted no time launching mass exploitation attempts with increasingly more complex, comprehensive, and obfuscated payloads. The associated GreyNoise activity graph further shows that Log4Shell attempts have entered the “pervasive background noise of the internet” stage, with some recent spikes in exploitation.

Thousands of commercial applications and an unimaginable number of enterprise in-house developed applications were, and still are, vulnerable to this attack vector. A recent post and report by Veracode further paints a bleak, but not hopeless, picture of the state of affairs of both Log4j and software weaknesses in general. 

GreyNoise Labs continues to see new Log4Shell payload clusters that use novel obfuscation techniques or insert JNDI exploit strings in novel places.

‍

‍

If you are a GreyNoise account holder, you can poke around a very interesting day in December 2023. Note that public Sift data ages out of the Sift application after 30 days, but you can email labs@greynoise.io if you’d like a copy of the payloads for that day).

And, yes, the “spray and pray” header approach that was identified within days of the vulnerability being made public is alive and well today:

‍

Most recently, the North Korean state-run Lazarus APT group exploited Log4Shell in publicly facing and unpatched VMware Horizon servers. They used their access to deploy custom remote access trojans (RATs) written in DLang, a programming language not commonly used in malware development. The campaign, dubbed Operation Blacksmith, targeted companies in the manufacturing, agricultural, and physical security sectors. The Storm⚡Watch crew did a deep dive into Operation Blacksmith and Log4j/Log4Shell on the 2023-12-14 episode.

Staying Safe In 2024 And Beyond

Given that unpatched weaknesses in Log4j present a clear and present danger to virtually every organization, there are some tangible actions you can take to keep your organization safe(r) in 2024:

• Update Log4j Libraries: Ensure your organization is using the latest version of Log4j to mitigate known vulnerabilities. Regularly monitor for updates and patches from Apache.
• Monitor for Exploitation Attempts: Implement monitoring and detection strategies to identify potential exploitation attempts targeting Log4j vulnerabilities. One great way to do this is with GreyNoise Alerts. 
• Improve Open-source Software Security: The Log4j vulnerability highlights the need for more stringent open-source security practices. Organizations should adopt better practices for managing and securing open-source software components.
• Evaluate Third-Party Libraries: Regularly review and update third-party libraries used in your projects to ensure they are not introducing new vulnerabilities.
• Keep The “Log4j Question” On Your Third-Party Questionnaires: When adding a new vendor or partner (or recertifying existing ones), do not skip over a series of questions that ask about their ongoing efforts to stay safe from Log4Shell. Taking your eye off this is a great way to get indirectly compromised.
• Ensure Your Backup/Restore Practices Keep Log4j Patched: Many organizations scrambled to shore up their defenses when CVE-2021-44228 debuted, and a large subset of those organizations failed to ensure that application restores likely put back a vulnerable version or configuration of Log4j. This led to numerous public breaches in 2022 and a non-publicly disclosed number in 2023.
• Remember Your Squishy Internal Networks: Even if you patched your external systems, untrusted application inputs and application log events with malicious JNDI strings make their way into all sorts of nooks and crannies within your less-than-buttoned-up intranets. You need to monitor all systems that process this data for signs of errant behavior, as you may have just inadvertently let attackers right inside your door.

And To All A Good Night

The researchers of GreyNoise Labs would like to take a moment to thank the massive efforts of the communications and design teams who made this year-end vulnerability round-up as gorgeous and fun as it was (hopefully) informative. We’d also like to thank all the GreyNoise Community members who gave us nods of encouragement along the way.

Remember, GreyNoise has your back as we enter a new year full of new vulnerabilities and exploit campaigns.

Finally, mark your calendars! In January, we start the year strong with a webinar series that takes a deep, deep dive into the ecosystem of GreyNoise Tags.

‍