New Relic has released Java Agent and Containerized Private Minion updates to address a critical vulnerability in the open-source Apache Log4j framework that was publicly disclosed on December 9, 2021, as well as an additional, low-risk vulnerability disclosed on December 14, 2021. The critical vulnerability (CVE-2021-44228) can be exploited to allow malicious actors to control systems remotely or exfiltrate data. As a valued New Relic customer, we want to provide you with more information about the vulnerability, what New Relic is doing to protect our systems against this vulnerability, and steps you can take to protect your organization from this issue.
New Relic will update our Security Bulletins and customer guidance as new information becomes available.
Call to action: The Apache Log4j vulnerability CVE-2021-44228 is critical in severity and should be remediated immediately wherever possible.
What is the recommended remediation?
It is critical to upgrade Apache Log4j to version 2.16.0 or higher as soon as possible to remediate this vulnerability.
- New Relic released two product updates to remediate CVE-2021-44228, a critical vulnerability recently identified in the log4j framework, as well as CVE-2021-45046.
- Upgrade your Java Agent. New versions are available to address vulnerabilities in the Apache Log4j framework. Additional information about this update, including workarounds, is outlined in New Relic’s Security Bulletin NR21-03.
- Upgrade your Containerized Private Minion (CPM). Additional information about this update is outlined in New Relic’s Security Bulletin NR21-04.
- New Relic has released an open-source script, nr-find-log4j, to help you identify services monitored by New Relic APM that depend on log4j and are potentially vulnerable. See https://github.com/newrelic-experimental/nr-find-log4j for usage instructions.
- New Relic’s APM Environment functionality can help you identify if your agents or applications are at risk due to the inclusion of a vulnerable version of log4j. When viewing jars loaded in the jvm runtime, you can identify if log4j-core 2.x is present, as well as what version of the newrelic agent is in use, and initiate your security response processes to determine its impact.
- You can use New Relic Log Management to help search your existing log records for attempted exploits of the recent log4j security vulnerability. Your log records may show a known attempt to exploit this vulnerability and may be helpful in tracking down malicious actors within your services.
- First, select Logs in New Relic One.
- Next, in the search bar Find logs where, enter
"jndi:ldap"
- Finally, select Query logs. Any logs that include
jndi:ldap
will be displayed.
What has New Relic been doing to protect your data since the vulnerability was announced?
New Relic’s Security Response process was initiated shortly after the log4j vulnerability was published on December 9, 2021. Working with our established vulnerability management processes, our engineering teams rapidly released updates. Our teams are diligently working with New Relic engineers, our partners, vendors, and subprocessors to ensure we have comprehensive remediation across our internal infrastructure.
What is the Apache Log4j JNDI Vulnerability CVE-2021-44228?
According to the NIST National Vulnerability Database, 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. From log4j 2.15.0, this behavior has been disabled by default.”
Additionally, this vulnerability can be leveraged for data exfiltration even in scenarios where remote code execution has been mitigated. For this reason we advise, for CVE-2021-44228, updating all instances of log4j to 2.15.0 or implementing appropriate technical mitigations regardless of your current version of Java.
What is the Apache Log4j CVE-2021-45046?
NIST National Vulnerability Database notes that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.”
Additionally, “Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”
Thank you for putting your trust in New Relic
Keeping customer data secure is New Relic’s top priority; we have a well-established security program that includes vulnerability management components that continuously scan and monitor our applications and systems for new vulnerabilities. The vulnerability management program is reviewed annually as part of our SOC2 certification, and we are happy to share our latest SOC2 report as well as further details of our program under NDA.
As always, if you have any questions or need additional help, please reach out to your Account Team or visit support.newrelic.com to engage our Support Team.
Thank you,
The New Relic Security Team
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.