If you’re not scrambling to contain and fix this vulnerability, do so now. It’s a doozy folks! Every organization using third-party software or developing custom applications with the Java programming language is potentially impacted. All current versions of log4j2 up to 2.14.1 are vulnerable.
Log4j is a very popular logging framework for Java developers, used by most Java applications. It has been ported to other programming languages including log4perl, log4php, log4net, and log4r. Log4j is also incorporated into a host of popular frameworks, including Apache Struts2 (web application framework), Apache Solr (enterprise search platform), Apache Druid (database), Apache Flink (streaming framework), and ElasticSearch (search engine based on Apache Lucene).
The Apache Foundation released a critical vulnerability alert for log4j, published in the NVD as CVE-2021-44228 with a critical severity and CVSS base score of 10.0 and classified as CWE-20: improper input validation.
“Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”
This security issue is not just widespread, but it’s very easy for bad actors to exploit. Data supplied by an untrusted outsider—such as data you are just wanting to print out for later reference or data you are logging into a file—can take over the server you are using for these actions. Log4j “lookup” features provide a way to add values to the Log4j configuration at arbitrary places. The user supplying the data you’re going to log, for instance, gets to choose how it’s formatted, what it contains, and how that content is acquired. From a Wired article on the subject:
“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.”
What Steps Should You Take Starting Now?
Take an outside-in approach to identify your impact and exploitability:
- Scan your whole external surface area to itemize vulnerable hosts: your COLOs and AWS or whatever cloud provider you’re using. There are plugins available from various security vendors for this. Check in with whatever vendor you are using and see if they issued a new plugin.
- Look at your Software Composition Analysis (SCA) scans to identify which Java codebases have dependencies on Log4j. Make sure your scans are reporting both direct and transitive dependencies, or anything that can result in Log4j being part of your applications.
- If you don’t have SCA scans, run freely available scanners. There are several that were developed over the weekend and are available on GitHub.
- At a minimum, run a grep across all of your Java codebases for log4j*.jar, or log4j-api-*.jar and log4j-core-*.jar.
A couple of things to keep in mind:
- This specific issue does not impact the ports; only Log4j since it requires the use of Java interfaces. It may be that the ports have similar vulnerabilities, but they would likely be of a substantially different nature such that we would issue a different CVE for them to help distinguish the vulnerabilities, patching, and remediation steps.
- Although it appears that Log4j 1.x is not impacted, it has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x are not being fixed. Users should upgrade to Log4j 2 to obtain security fixes.
Some additional important steps:
- Upgrade your dependencies to Log4j 2.15.0; if you cannot upgrade for some reason, Apache has proposed three different workarounds that appear to be working based on security experts.
- Notify your customers of the actions you are taking and when you will provide them with information about impacted systems or applications.
- Build a remediation plan and execute on it.
- If you are not already continuously scanning for OSS, please start.
- Take this opportunity as you are sifting through all of your applications to also check for other past exploits such as old versions of OpenSSL, Apache Struts 2, and others. We are still often seeing cases of well-publicized vulnerable versions of popular OSS components in our audit services practice which means that people are not always pathing their applications. This is a great opportunity to catch up with that effort.
Scanning your applications with an SCA tool such as Code Insight will show you vulnerabilities in your open source libraries and identify where instances of Log4j exist. Get alerts when vulnerabilities affecting you are reported. Analyze security risks within projects with dashboards and reports, and date-based search criteria.
Code Insight includes a robust framework supporting multiple data sources for vulnerability data, including NVD, RubySec, Debian, RustSec, and advisories from Secunia Research at Revenera.
What is Revenera Doing?
Revenera customers have been made aware of Log4j. For updates on our continued actions, please go to our Community page for updates.
Check your codebase using our free Code Aware for Log4j scanner and begin to mitigate your risk from this critical vulnerability.
