Topic: {warning} Log4Shell: RCE 0-day exploit found in log4j2,this is gonna be HUUUUGE (Read 191 times)

It was discovered that version 2.15.0 would still be vulnerable when the configuration has a pattern layout containing a Context Lookup (for example, $${ctx:loginId}), or a Thread Context Map pattern %X, %mdc, or %MDC. In these cases, when the attacker manages to control the Thread Context values, JNDI lookup injections may be possible, resulting in JNDI connections. Version 2.15.0 limited JNDI connections to 'localhost’' but this possibility could result in a denial of service (DoS) or worse.

Therefore, a new version (2.16.0) has been made available to completely fix the issue (so far at least) associated with CVE-2021–45046 along with more effective mitigation measures for versions to 2.x versions:

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

But what can we as regular users do?

This attack does not target us, it targets servers. So it's important to not leave your personal info everywhere, which is easier said than done, as sites like Amazon or Ebay require it for deliveries.

Answer: Many, many servers including many internet servers use a programming language called Java. Java has been around for a quarter of a century at this point, which in computer technology time, is a very long time indeed. In other words there's lots and lots of servers out there that use Java.

Something that almost every server must do is, over time, generate logs of text. For example "At 12:23pm user 67456 submitted a review for product 7635824: This is the best toothbrush I've ever purchased!".

One of the oldest Java plugins (called libraries) for logging things in a server is called Log4J which has been around for 20 years now. In other words there's lots and lots of servers out there that use Log4J.

It turns out that some versions of Log4J have a critical vulnerability where if a specially formatted piece of text is saved to a log that is handled by Log4J, an arbitrary command can be executed in that server. So for example, "At 12:23pm user 67456 submitted a review for product 7635824: {send user 82738's private account details to [email protected]}"

These examples are simplified a lot, but they hopefully communicate the basic nature of the threat.

Unfortunately, as an individual, there's not a lot that you can do about any of this. First off, it's difficult to know which of the internet services that you use depend on Java. Secondly, it is virtually impossible to know which of these services use Log4J. Thirdly, it is even more impossible to know which versions of Log4J they are using.

Update December 10, 11:46 AM EST: Cloudflare told BleepingComputer that its systems are not vulnerable to CVE-2021-44228 exploitation attempts.
"We responded quickly to evaluate all potential areas of risk and updated our software to prevent attacks, and have not been able to replicate any external claims that we might be at risk," said Leigh Ann Acosta, Cloudflare's Director of Public Relation

It means that any website or server on the Internet that uses a popular Java logging software called log4j can be instantly hacked

A few hours ago, a 0-day exploit in the popular Java logging library log4j2 was discovered that results in Remote Code Execution (RCE) by logging a certain string.

Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. We're calling it "Log4Shell" for short (CVE-2021-44228 just isn't as memorable).

The 0-day was tweeted along with a POC posted on GitHub.

Who is impacted?​
Many, many services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Anybody using Apache Struts is likely vulnerable. We've seen similar vulnerabilities exploited before in breaches like the 2017 Equifax data breach.

Many Open Source projects like the Minecraft server, Paper, have already begun patching their usage of log4j2.

Updates (3 hours after posting): According to this blog post (in english), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

Affected Apache log4j2 Versions​
2.0 <= Apache log4j <= 2.14.1

Permanent Mitigation​
At the time this post was created (December 9th, 2021), no stable release was available.

As of December 10th, 2021, Version 2.15.0 was released. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].

Releases to GitHub appear to still be pending.

This log4j exploit = remote code execution in basically everything

Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

This may well be devastating 0day RCE exploit that has ever been dropped in all of history.

https://t.co/CeQNtSBpZV https://t.co/jYkmdVfdyK