Hallo, aufgrund einer von log4j unabhängigen Lücke werden die TSM Server gerade gepatcht. Genauso gibt es eine Update Empfehlung der Clients auf die Version 8.1.13 wegen eines anderen Issue (https://www.ibm.com/support/pages/node/6524706?myns=swgtiv&mynp=OCSSEQVQ&mync=E&cm_sp=swgtiv-_-OCSSEQVQ-_-E) Unabhängig davon haben wir eine Anfrage zu Thema log4j an IBM gestellt, da es zur Zeit noch keine Warnung (aber eben auch keine Entwarnung) von IBM gibt. Wir werden uns Auf jeden Fall hier noch einmal melden, wenn es Neuigkeiten zu dem Thema gibt. Gruß -- Jonas Jansen IT Center Gruppe: Server, Storage, HPC Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-28784 Mobil: +49 1515 8342747 Fax: +49 241 80-22134 jansen@itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ -----Original Message----- From: Xhonneux, René <xhonneux@ub.rwth-aachen.de> Sent: Monday, December 13, 2021 10:13 AM To: rwth-security@lists.rwth-aachen.de Subject: [rwth-security] Re: RCE-Lücke in Log4j <2.15.0 Hallo zusammen, wenn ich das richtig sehe, ist der Backup-Client auch betroffen: rpm -qlp TIVsm-BA.x86_64.rpm |grep log4j /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-api-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-core-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-jcl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-slf4j-impl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j.properties Sollte ich mir deswegen Sorgen machen, oder ist das unproblematisch, weil der eh nur mit den ITC-Servern spricht? Irgendwie habe ich das Problem noch nicht mit all seinen Facetten verstanden. Generell wird als Mitigation empfohlen, die Systemeigenschaft "log4j2.formatMsgNoLookups" auf “true” zu setzen, aber wo mache ich das in dem Fall? Danke und Grüße, René [1] https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/cli... Am 11.12.21, 00:05 schrieb "Jens Hektor" <hektor@itc.rwth-aachen.de>: Am 10.12.21 um 12:14 schrieb Jan Niehusmann: > Moin! N'abend! > Ich bin eben über folgenden Artikel gestolpert: > https://www.lunasec.io/docs/blog/log4j-zero-day/ > > TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein > potentieller Angreifer gesendet hat, dann sollte man dringend auf > Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden. > > Das könnte einen signifikanten Anteil aller in Java geschriebener > Server-Software betreffen. Nach dem, was man mittlerweile so liest, stimmt das. Und: die gaaanz Großen sind dabei, nicht nur die "Excellenz" ;-) Leider sind tatsächlich auch Systeme bei uns betroffen und ein prominentes haben wir temporär aus der Schußlinie genommen. Insgesamt ist die Bedrohungssituation aber überschaubar. Weltweit wird ca. von 150 scannenden Systemen berichtet, der hier gesehene Anteil liegt derzeit bei <50 Angreifern, dies Gesamtzahl gesehener "Events" ist auch noch <100. Dazu muß man folgendes anmerken: a) wir sehen nur HTTP, also keine Angriffe auf HTTPS, da wir derzeit nur 1 (in Worten: eins) System haben, beim dem HTTPS in der Firewall deep inspected werden kann. b) wir sehen es überhaupt, weil unser Firewallhersteler gegen 14:00 begann, entsprechende Signaturen ("Situations") bereitzustellen (es gab noch zwei Updates danach) c) neben dem oben erwähnten "prominentem" System gehen wir von einer größeren Zahl dem IT Center nur teils bekannter Systeme in der RWTH aus Es wurde folgendes umgesetzt: Systeme, die die Signaturen triggern, werden für einen Tag geblacklistet. Die bisher gesehene IP der "ldap URL", die zum Code Nachladen benutzt wird, ist für eine Woche auf der Blacklist. > Grüße, > Jan Gruß, Jens <private>wann gehen wir zwei endlich mal wieder ein Bierchen trinken?</private>