Log4j Remote Code Execution Vulnerability
CVE-2021-44228 is a vulnerability identified with the Apache Log4j package that is classified under the highest severity (10 out of 10). This vulnerability allows an attacker to execute arbitrary code by injecting data into a logged message.
This post is an attempt to provide an analysis of the vulnerability and a discussion of potentially affected Identity Management products.
For details from the Apache Foundation regarding the Log4j package specifically, view the CVE details here: https://logging.apache.org/log4j/2.x/security.html
Vulnerability Description
This vulnerability, known colloquially as “Log4Shell” since it provides unhindered access to execute code on the compromised machine, affects one of the most popular logging libraries in the Java ecosystem (“over three billion devices run java”).
A logger is supposed to just record details of an even to a file, database, or send it to another server to store it. But in the case of log4j, there are a few things that are performed before writing anything. One of the things it does is look for patterns like ${something} and will try to replace it with additional information, i.e. ${date} could be replaced by the date of the error.
The problematic issue is that there are messages logged including strings like:
${jndi:...
Logback tries to replace the data, invoking another mechanism that loads a resource from another computer… anywhere on the internet.
This data can be a malicious code.
Due to the nature of Java the malicious code is automatically run on the computer that used log4j, which means that at the attacker can make the targeted computer do (almost) anything. All that it takes for that code to execute is for the attacker to get the string to be logged.
If your java web server, for example, is logging what urls are accessed it could be as simple as including the malicious code in an HTTP request to the server.
Generic Mitigation Strategies
Adding log4j2.formatMsgNoLookups=true as a JVM property to any vulnerable application’s Java Virtual Machine will remediate the issue.
External mitigation is also available via a Web Application Firewall (WAF). We recommend reaching out to your WAF vendor regarding mitigation for this vulnerability, and blocking some of the known prefixes such as:
Auth0
Auth0 cloud identity services are not vulnerable. See: https://twitter.com/auth0/status/1470086301902721024
Apereo CAS
CAS versions 6.3+ is vulnerable and requires immediate mitigation. Deployers can immediately mitigate by updating to the latest versions (at the time of writing) of each branch of CAS:
6.3.x
Modify your CAS overlay to point to the version 6.3.7.2.
6.4.x
Modify your CAS overlay to point to the version 6.4.4.
Alternative Mitigation
For users that can’t upgrade, another option is to set the log4j2.formatMsgNoLookups system property to true, e.g.
java -Dlog4j2.formatMsgNoLookups=true -jar cas.war
See: https://apereo.github.io/2021/12/11/log4j-vuln/ for additional details.
F5 BigIP
F5 BigIP products themselves are not vulnerable.
F5 provides guidance for deployers of F5 load balancers to block incoming traffic asserting the problematic JNDI strings here: https://support.f5.com/csp/article/K19026212
ForgeRock
The only ForgeRock product that utilizes Log4j is Autonomous Identity. ForgeRock Autonomous Identity is vulnerable, however all other ForgeRock products are not vulnerable.
As of December 13, 2021 a patch is unavailable, and as such ForgeRock recommends using the following setting:
log4j2.formatMsgNoLookups=true
or the Java Virtual Machine running Autonomous Identity.
For further details see: https://backstage.forgerock.com/knowledge/kb/book/b21824339#a39102625
Keycloak
Keycloak is not vulnerable unless you are using JMSAppender (non-standard; if you are using JMSAppender Keycloak recommends disabling that for now).
Okta
Two on-premises Okta products (RADIUS Server Agent and On-Prem MFA Agent) are vulnerable. The mitigation for these products is to update to the latest version available from the Okta admin console.
Okta cloud-based identity solutions are not vulnerable.
See: https://sec.okta.com/articles/2021/12/log4shell
PingIdentity
PingFederate, PingAccess, PingCentral and PingIntelligence are vulnerable.
Maintenance releases that permanently resolve this issue will be made available soon, however in the meantime Ping recommends to mitigate in various ways depending upon your version and product. See: https://support.pingidentity.com/s/article/Log4j2-vulnerability-CVE-CVE-2021-44228 (Note: requires account, free from here.)
Shibboleth
Identity Provider
Shibboleth Identity Provider is not vulnerable using the default configuration. Shibboleth leverages SLF4j and Logback, not Log4j. Shibboleth IDP does ship with a Log4j bridge, however, leveraging this feature would require specifically enabling the functionality.
See: http://shibboleth.net/pipermail/announce/2021-December/000253.html for information provided by Shibboleth lead developer Scott Cantor.
You can read SLF4j’s discussion of the Log4j issue here: http://slf4j.org/log4shell.html
In effect, you may be vulnerable if your specific configuration loads Log4j, so you should validate what libraries you are using for logging. Adding the startup string -Dlog4j2.formatMsgNoLookups=true to the JVM will provide protection if you are uncertain of what logging facility your server is using.
Service Provider
Shibboleth Service Provider is not vulnerable as it is not a Java-based product.
WSO2
The following WSO2 products are vulnerable:
- WSO2 Identity Server 5.9.0 and above
- WSO2 Identity Server Analytics 5.7.0 and above
- WSO2 Identity Server as Key Manager 5.9.0 and above
- WSO2 API Manager 3.0.0 and above
- WSO2 API Manager Analytics 2.6.0 and above
- WSO2 Enterprise Integrator 6.1.0 and above
- WSO2 Enterprise Integrator Analytics 6.6.0 and above
- WSO2 Micro Integrator 1.1.0 and above
- WSO2 Micro Integrator Dashboard 4.0.0 and above
- WSO2 Micro Integrator Monitoring Dashboard 1.1.0 and above
- WSO2 Stream Processor 4.0.0 and above
- WSO2 Stream Integrator 1.0.0 and above
- WSO2 Stream Integrator Tooling 1.0.0 and above
- WSO2 Open Banking AM 2.0.0 and above
- WSO2 Open Banking KM 2.0.0 and above
WSO2 provides a shell script that can be executed from the application’s base directory to locate the remove/update vulnerable classes: wso2/security-tools#169
See: https://docs.wso2.com/pages/viewpage.action?pageId=180948677 for additional details.
Need help assessing a security issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!
