Log4Shell: log4j Vulnerability, Attack Surface, Variant and Remediation
December 14, 2021 • RBS
Yet another Log4Shell blog post? No, a variant!
Since its initial discovery on November 30, as an exploit used against Minecraft servers, the “Log4Shell” vulnerability has exploded across the Internet, sending the security community into overdrive. The original CVE assignment for this issue has now been joined by two more, creating further confusion and headache for security teams.
Flashpoint Community Call: Log4J Vulnerability
Flashpoint’s intel team, and Jake Kouns, CEO at Risk Based Security discuss what is known about this vulnerability.
There have been plenty of articles (some would say too many articles) on this topic. So, take your pick of any of the prior links if you want to get up to speed on the basics. We want to share some new information and perspective that you should be aware of when wrapping your head around Log4Shell.
It is important to call out that log4j is a popular logging framework in Java. This means it’s used in an extraordinary number of things. How many? Back in 2015, Oracle bragged that Java was running on 13 billion devices (even though we all know it’s 3 billion). Given the popularity of the library in question, Log4Shell might impact a large proportion of them, including IoT, ICS, medical, and more. We know it won’t impact all of them, but even a small percentage would mean a staggering number of devices. How prevalent is log4j? It’s used in the Mars 2020 Helicopter mission among other things.
CVE/NVD currently has log4j as the only impacted product in their list of CPEs. While the root vulnerability is in fact, in log4j, we have already determined that there are over 200 products affected and we’re still processing a long list of related advisories.
Products that are affected are from major vendors such as:
- National Security Agency (NSA)
- New Relic
There will be many more affected products still to be identified. And, of course, many more SaaS services will be impacted as well. It will take some vendors months to fully assess the impact of this vulnerability to their product portfolio.
The vulnerability was given the nickname “Log4Shell” by LunaSec, because it is a remote code execution that is relatively simple to exploit in many services and products. If an attacker can generate an event that is logged, it can result in shell access to the system. We aren’t trying to split hairs here but “remote” actually depends on how the library is used. Just because a product uses log4j does not necessarily mean it is vulnerable remotely.
The message lookup feature is the real problem, so how it can be used actually depends on where the logged malicious input comes from. For some products it is remote, for others it will be local, and others still won’t be affected at all since they don’t log attacker-controlled input. Exploitation requires that an attacker can control the string being logged.
While the default assumption is that it can be triggered remotely until you know otherwise for a specific product or usage, the truth is that it all depends. If it is faster to upgrade the log4j library than perform a root-cause analysis, upgrade first.
“If it is faster to upgrade the log4j library than perform a root-cause analysis, upgrade first.“
There have been a number of grim pronouncements from security vendors on just how nasty Log4Shell is:
- “The internet’s on fire right now,” – Adam Meyers, Senior Vice President of Intelligence, Crowdstrike [Source]
- “I’d be hard-pressed to think of a company that’s not at risk,” – Joe Sullivan, Chief Security Officer, Cloudflare [Source]
- “The Apache Log4j Remote Code Execution Vulnerability is the single biggest, most critical vulnerability of the last decade.” – Amit Yoran, CEO, Tenable [Source]
- “Worst bug impacting the Internet in the last 5 years, at least” – Matthew Prince, Co-founder & CEO, Cloudflare [Source]
Could Log4Shell be the “worst vulnerability ever”? At RBS we avoid fear-mongering, so we will say “to be determined” for now, but the potential is certainly there, and organizations need to pay attention. While vulnerabilities in OpenSSL, such as Heartbleed, were prevalent, exploitation was more difficult on some servers.
Log4Shell deserves to be taken seriously for the following reasons:
- Massive attack surface.
- A huge number of products are impacted.
- Ease of exploitation.
- Attackers were able to get remote code execution on Minecraft servers by simply pasting a short message into the chat box.
- This vulnerability is igniting discussion, in the press, social media and in the security community at large. Needless to say, our Social Risk Score is on fire!
- When vulnerabilities get this kind of coverage, there’s a race to find further exploits. Swift action is required.
“Variant” might just be our word of the year at this point, with seemingly endless new COVID strains in the press, and, more cheerfully, for the Marvel fans, Loki variants… well now, yes, there is actually a Log4Shell variant to worry about.
Many people are referring to one CVE for Log4Shell, but there are actually three assignments as we go to press:
The relationship between log4j2 (CVE-2021-44228) and log4j1 (CVE-2021-4104) could be confusing. There has been back and forth discussion over the past few days as to whether log4j 1.x is affected or not. As of December 13, RedHat assigned CVE-2021-4104 for a vulnerability under specific conditions. It requires considerable local access and will result in local privilege escalation.
That is important because a 1.x developer has stated:
- That it isn’t vulnerable
- But to be aware it is used in products “by an order of magnitude” despite 1.x being unsupported for years.
The developer was speaking about remote exploitation like CVE-2021-44228, where Red Hat’s CVE-2021-4104 is an entirely different attack vector. That means this has the potential to haunt us for a long time.
Add to that the CVE-2021-45046 assignment, which represents an ‘incomplete fix’ but is really the same vulnerability. MITRE and CVE Numbering Authorities (CNA) will assign a second CVE ID in cases of fixes not fully patching an issue. This helps some organizations in tracking an issue while introducing confusion to others.
Despite there being more than one CVE, many places have been treating them as a single issue, but this is definitely not the case. Based on our code review a few days ago and various discussion threads, we believe that 1.x is not affected as far as remote exploitation. We don’t believe that it includes the problematic message lookup functionality that was introduced in 2.0beta9 (or around that version). The vulnerability also only exists under very very limited circumstances i.e. requires JMS Appender class being in use (not often the case), JDNI support, and seemingly also config write access. Rob Fuller also just published a nice quick “Fact or Fiction” post on his LinkedIn page that helps understand the issue.
Yes, this appears to be an important issue and it needs to be taken seriously.
In order to help plan your approach here are some recommendations:
- Figure out where you may be affected
- If you haven’t worked on implementing a Software Bill of Materials (SBOM) at your organization for your products, now would be a great time to get started!
- Monitor for vendors/products that are impacted and assess your risk.
- Figure out the best solution/fix for your organization.
- While the reported vulnerability was addressed in version 2.15.0, version 2.15.1 was released to disable JNDI access by default.
- A more comprehensive fix has been released in version 2.16.0 where the problematic message lookups functionality has been removed.
- Anyone not requiring JNDI access or message lookups are strongly encouraged to update to version 2.16.0 or later.
- As a workaround, pattern layout lookups within message text can be disabled by setting the “formatMsgNoLookups” option to “true”.
- Note that this option is only available in version 2.10.0 and later.
- If running End of Life (EOL) 1.x version, it should not be used and it is recommended to upgrade to a current supported version.
- Apache Log4j 1.2 reached end of life in August 2015
- While it seems more difficult to exploit this version, be mindful there are other known vulnerabilities in this version as well.
- Expect a whole lot of vendors to be announcing patches very soon.
- With so many products affected, start planning for a substantial patching effort in the short term for your organization.
- You should also expect to see varying CVSSv2 and CVSSv3 scores.
- The CVSS standard and scoring guidelines have some issues with this vulnerability.
- Many organizations are rating Log4Shell a 10.0 for CVSSv3 and a 9.3 for CVSSv2.
- If following the proper scoring standards, the scores should really be a 9.8 for CVSSv3 and 9.3 for CVSSv2.
- As mentioned, depending on the implementation severity scores will vary, so expect to see inconsistency from your vendors.
- In some implementations, exploitation may involve a “scope change”. That is a CVSSv3 designation take can take a remote code execution vulnerability from 9.8 to 10.0. In these cases, a log event may be generated on one system but passed to a second system (i.e. a logging host) where the code is executed. That is where the scope of the vulnerability impact changes.
- Expect lots of questions (and initial confusion!)
- Whether it is from inside your company or outside (customers, vendors, partners), you should be prepared.
- This is getting so much attention, you will be asked questions and you need to have answers ready.
- Expect answers!
- You should also go get answers from your vendors as well.
- Ask them a) if they have determined if they are impacted, and b) what they are proposing as solutions.
This vulnerability is unfortunately going to be around with us for years… remember Heartbleed? Even with all that press, years later servers were still vulnerable and not patched. This new log4j vulnerability will likely haunt us for years to come. As always, we will keep an eye on this vulnerability and continue to monitor the situation.
Got all that? You are just in time for your regularly scheduled Patch Tuesday, with many more vulnerabilities to assess and remediate!