Raygun's log4j vulnerability response

By Jeremy Boyd | Posted Dec 14, 2021 | 2 min. (383 words)

Over the weekend a high severity security vulnerability in the Java based log4j logging framework (CVE-2021-44228) was reported and is being actively exploited. This exploit is also known as “log4shell” and provides a vector for remote code execution.

Security is a top priority at Raygun so we have been actively reviewing our infrastructure to assess our exposure to this vulnerability and to ensure we continue to maintain a secure environment for your data.

  • At Raygun our core services are .NET based so do not use log4j and therefore those services are not affected.

  • Our provider for Java does not use log4j so customers using this provider do not need to upgrade the raygun4java component.

  • We do use Java based services in our supporting infrastructure and some of those services were using affected versions of the component.

  • Initial forensic review of those services indicated user supplied data would not be passed to a logging call and some services had existing mitigations in place to prevent remote code execution. On Monday NZT we took immediate action to start updating or applying mitigations to all Java based services.

  • Since this issue was reported we have observed a number of unsuccessful attacks and bot scripts probing our services for this exploit and we are continuing to monitor for this.

We recommend all customers review their own code and services for any use of this component and upgrade or apply one of the mitigations to keep yourself secure.

  1. If possible upgrade to log4j version 2.16

  2. If you cannot upgrade remove the affected class from the classpath:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

If you have any questions or concerns, please reach out to one of our team.

Update: 15/12/2021

A subsequent issue has been identified in log4j (CVE-2021-45046) which provides a vector for a denial of service attack. This is deemed to be less severe but is not covered by one of the earlier mitigations that was prescribed for CVE-2021-44228. A new version of log4j (version 2.16) has been released which covers both issues and if you are not able to upgrade the removal of the JdniLookup class from the classpath also covers both issues.

We have updated our above guidance to remove the reference to the use of the -Dlog4j2.formatMsgNoLookups=true property as this does not cover both issues.