NewsLog4Shell Exploit für z/OS: Was für Admins zu tun ist

Um diesen Exploit auszunutzen, braucht man folgendes

• Eine Web Application running Log4j, das auch heißt, geöffnete Ports für diesem Application
    (geöffnete Server Ports kann man mit dem MVS Command D TCPIP,,NE,CO,SERVER prüfen.)
• Der attackierte Server muss von außen erreichbar sein (Public Internet) – Firewall/incoming Packets!
• Der attackierte Server muss mit einem external (public!) Server, welcher den Malicious Code hat, über das LDAP Protokoll kommunizieren können – das kann zum Beispiel eine Firewall blockieren.

Fehlt einer diese Schritte, ist diese Exploit nicht ausnutzbar!

Log4j ist, als .jar, mitgeliefert mit Netview und z.B. zOSMF, ist jedoch nicht per default aktiviert – man muss Log4j aktiv konfigurieren und starten. 

Auf Netview z.B. könnte das Correlation Enginge es nutzen (wenn es aktiv konfiguriert und gestartet ist!) – das kann man überprüfen z.B. mit dem Netview Kommando CORRSERV STATUS. 

Was den Service Management Unite betrifft, wenn es auf Websphere läuft

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"

Man kann also die Bedrohung in diesem Fall abschwächen, in dem man den genannten Parameter (-Dlog4j2.formatMsgNoLookups=true) setzt . Wenn dies vorher jedoch sowieso nicht möglich war, wegen beispielsweise einer Firewall, dann ist es eigentlich nicht nötig, diesen Parameter zu setzen.

Die Empalis unterstützt Sie gerne bei der Umsetzung der Local Fixes oder bei weiteren Fragen.

Hier geht es zum vorherigen Artikel zum Thema Log4j vom 16.12.2021