Bug in Log4j 2.15.0 also RCE: Severity raised to 9.0

Whac-that-mole...

A fresh bug allocated CVE-2021-45046 in Log4j release 2.15.0 that was initially rated CVSS 3.7 has had its severity boosted to a critical 9.0 after security researchers demonstrated remote code execution (RCE).

It had earlier been thought only to offer potential denial of service (DOS) possibilities.

Version 2.15.0 was released December 13 to fix the devastatingly widespread critical CVE-2021-44228.

While RCE in 2.15.0 has arguably not been as widely demonstrated for the “new” bug (CVE-2021-45046) as it had been for CVE-2021-44228, users should consider swiftly updating to 2.16.0.  Apache said Dec 17 of the new vulnerability that only "Pattern Layouts with a Context Lookup (for example, $${ctx:loginId}) are vulnerable."

https://twitter.com/pwntester/status/1471511483422961669

The Apache team said early December 17 that 2.15.0 made a “best-effort attempt to restrict JNDI LDAP lookups to localhost by default, there are ways to bypass this and users should not rely on this [but]... the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

"When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and RCE in some environments and local code execution in all environments; RCE has been demonstrated on macOS but no other tested environments.”

The LunaSec team has a crisp explanation of the new bypass here that is worth reading.

https://twitter.com/marcioalm/status/1471740771581652995

Alvaro Munoz, Principal Security Researcher, GitHub Security Lab, told The Stack in an emailed comment: "The GitHub Security Lab was able to fully bypass all mitigations put in place in Log4j 2.15 on MacOS. We believe the additional vectors have the potential to impact other platforms especially if additional parser differentials are uncovered. However, we see many deployed applications that, while technically exposed to CVE-2021-45046, can not be exploited due to their Log4j configuration and given they’re not using affected lookups in non-message parts of the pattern layout. To be vulnerable, an attacker needs to control portions of the pattern layout other than the logged message text. This is possible, but very unlikely. There are some logging patterns that may lead to this scenario, but these should be rare and are not commonly deployed Log4j patterns."

As The Stack published many large vendors were still referencing the earlier, lower DOS threat, with Microsoft, for example, still urging customers to make“plans to move to 2.16.0 as soon as possible "for extra protection against a potential DoS attack” (now an RCE one) which may lull customers into false security.

Microsoft is among the myriad large vendors with several vulnerable platforms. Beyond an initial attack on Minecraft Microsoft claims not to have seen any attacks in the wild on its software however. Its vulnerable products are listed here. As we earlier reported, VMware was particularly exposed with a proof-of-concept for pre-auth RCE attacks circulating, which the virtualisation giant said it had seen in the wild.

We love to connect with readers on LinkedIn. Follow us today.

The two are just a brace of examples of the myriad software providers affected.

The Dutch NCSC has one of the more detailed advisories on products affected here.

Bitdefender today said its Log4j honeypots were attacked 36,000 times between Dec 9 - 16, with more than 50% of attacks are using TOR to mask true country origin. More on that research to follow. Cloudflare's CTO meanwhile said the company had seen peaks of 100,000 attacks per minute. Security vendors probably accounted for a large chunk of that, but as CISA's director has noted, it's now best to assume you've been exploited.

Worryingly, major OT vendors are also highly exposed to the original CVSS 10 bug, with many companies are still struggling to identify where Log4j runs. These include multiple Siemens industrial software platforms, ranging from software for smart meters, CAD software to the German conglomerate's enterprise manufacturing platform Opcenter Execution Process. OT security vendor Dragos potential saying the issue has "the potential to become a vulnerability that will persist within Industrial Control Systems (ICS) environments for years to come."

See also: VMware vCenter “trivial to exploit” using Log4Shell, POC available