To exploit this exploit, you need the following:
- A web application running Log4j, which also means open ports for this application. (open server ports can be checked with MVS Command D TCPIP,,NE,CO,SERVER).
- The attacked server must be accessible from the outside (Public Internet) - firewall/incoming packets!
- The attacked server must be able to communicate with an external (public!) server, which has the malicious code, via the LDAP protocol - this can be blocked by a firewall for example.
If one of these steps is missing, this exploit is not exploitable!
Log4j is, as .jar, included with Netview and e.g. zOSMF, but it is not activated by default - you have to actively configure and start Log4j.
On Netview e.g. the Correlation Enginge [AM1] could use it (if it is actively configured and started!) - you can check this e.g. with the Netview command CORRSERV STATUS.
As for the Service Management Unite, if it runs on Websphere
See this security bulletin: https://www.ibm.com/support/pages/node/6525706
WebSphere has already provided an iFix to address the issue: https://www.ibm.com/support/pages/node/6525672
- It is recommended that you apply this iFix to the WebSphere Application Server installation in your SMU docker image.
- If you are unable to apply this iFix, you can also mitigate the exposure by setting the following JVM property in WAS:
- Set the JVM system property "-
Dlog4j2.formatMsgNoLookups=true".
So you can mitigate the threat in this case by setting the mentioned parameter (-Dlog4j2.formatMsgNoLookups=true). However, if this was not possible before anyway, for example
because of a firewall, then it is not really necessary to set this parameter.
Empalis will be happy to support you with the implementation of the local fixes or if you have any further questions.