Apache Log4j2 vulnerability fix for Web Service Adapter of SAP NetWeaver Process Integration
On Thursday, December 9th 2021 , a 0-day exploit in the popular Java logging library log4j (version 2) was discovered that results in Remote Code Execution (RCE), by logging a certain string.
log4j is an apache library used commonly in java applications. This particular issue was identified in log4j2 and fixed in log4j 2.17.1
Affected Apache log4j Versions:
Almost all versions of log4j version 2 are affected.
2.0-beta9 <= Apache log4j <= 2.14.1
LIMITED VULNERABILITIES FOUND IN 2.15.0 AND 2.16.0
As of Tuesday, Dec 14, version 2.15.0 was found to still have a possible vulnerability in some apps. And, a few days later, a DOS vulnerability was found in 2.16.0 too.
Recommended to update to 2.17.0 which includes the fixes introduced in 2.16.0 as well as a fix for a discovered denial of service (DOS) attack.
Version 1 of log4j is vulnerable to other RCE attacks, and if you’re using it, you need to migrate to 2.17.1
2.17.0,1 of log4j has been released without the RCE or DOS vulnerabilities.
KBA – https://launchpad.support.sap.com/#/notes/3129883
‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior
SAP NetWeaver Application Server Java is not impacted by the CVE-2021-44228, CVE-2021-45046 & CVE-2021-45105. This applies to all the AS Java Core Components (see KBA 1794179).
As of now only one SAP Delivered product is affected on top of AS Java which is Process Orchestration.
How to identify if your system is impacted by this vulnerability?
A: In order to find some possible applications that might use the vulnerable library the below Telnet command can be run for class (e.g. log4j-api.jar and log4j-core.jar):
llr -all -f org/apache/logging/log4j/core/lookup/JndiLookup.class
If your system is not impacted, you will see output similar to: “Such resource cannot be found in the registered loaders
If your system is impacted by SAP standard code issue, you will see output similar to:
Is there any usage of the impacted log4j in SAP standard code?
Yes. SAP have identified usage of the log4j in standard SAP code. This impacts only release 7.50 with SP20, SP21 and SP22.
There is no impact identified on any lower SP’s or releases e.g. 7.30, 7.31 or 7.40.
Is there a workaround?
A. Java system property “log4j2.formatMsgNoLookups=true” as described in KBA 3129883 CVE-2021-44228 – AS Java Core Components’ impact for Log4j vulnerability.
Set this parameter in the AS Java Config Tool.
B. SAP also offer the following additional workaround, in case you are not using Java Web Service Adapter. Stop and disable the WS Adapter Application to be safe. No restart is needed!
– Logon to NWA via https://host:port/nwa
– Navigate to Operations -> Start & Stop -> Java Applications. Filter for “com.sap.aii.adapter.ws.app” and stop this app. Press home.
– Navigate to Configuration -> Infrastructure -> Java System Properties. Press “Show Advanced Properties”. Select the Filters tab. To add a local filter, press Add and enter Action=disable, Vendor Mask=sap.com Component=application, Component Name Mask=com.sap.aii.adapter.ws.app. Press set and save.
– Verify that https://host:port/WSAdapter returns “Error: Application is stopped.”
– Delete this filter after the system was patched (with bugfix from SAP Note 3130521).
If you are unsure if you are using the WS_AAE Adapter, go to the Communication Channel Monitor via https://host:port/nwa -> SOA -> Monitoring -> PI Communication Channel Monitoring -> Advanced and check the Adapter Type dropdown for any WS_AAE channels. If no channels are found, then you are not using this adapter and can disable the adapter application.
In case you are using Java Web Service Adapter, proceed as follows (it is an online deployment). Apply this workaround in emergency cases only.
1. Download the referenced Patch from SAP Service Marketplace (SAPXIAF.SCA).
2. Extract the “com.sap.aii.adapter.ws.cxf.lib.sda” from it and place it in the instance directory, for example Linux:/usr/sap/<SID> or Windows: <drive>:\usr\sap\<SID>
3. Open command shell on the server and logon with telnet localhost 5<xx>08. Enter commands
Linux: deploy /usr/sap/<SID>/com.sap.aii.adapter.ws.cxf.lib.sda core_components=online version_rule=all
Windows: deploy \usr\sap\<SID>\com.sap.aii.adapter.ws.cxf.lib.sda core_components=online version_rule=all
4. As telnet is currently open, you can immediately check the used versions with:
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
5. Exit shell
6. Go to MMC and restart the single server nodes / instances.
Deploy the Support Packages and Patches referenced by this SAP Security Note:
3133005 – [CVE-2021-45105] Denial of service (DOS) associated with Apache Log4j 2 component used in Java Web Service Adapter of SAP NetWeaver Process Integration
This update also fixes the Log4j vulnerabilities reported in SAP Security Notes 3130521 and 3132204.
Workarounds are explained in SAP Security Note 3130521. Actual information about Log4j vulnerabilities is available in FAQ Note 3131436.
Deploy the SCA either by SUM or telnet .
Reference link to deploy SCA:
2171408 – How to check the Dependencies of the PI Components
You did a good summary. Nevertheless I suggest a minor correction of your stament saying "Recommended to update to 2.17.0(...)" in order to mention 2.17.1. instead of 2.17.0.
I also had to go through all those steps and also to check the AXIS adapter where I found a v1.x of log4j.