log4j

[lcer]

Ich halte es eher mit dem Thema aus "Hitchhikers Guide to Universe" : don't panic

Router sind i.A Geräte mit einem chronischen RAM-Mangel da fällt Java als Anwendung schon mal raus.
Für die gängigen Fritzboxen hat AVM selbst Entwarnung gegeben. https://avm.de/service/aktuelle-sicherheitshinweise/
Port-Weiterleitungen zu prüfen ist immer richtig, aber was soll bei Mail- und DNS-servern Java-affin sein?

Google kaputt? "DNS Server Java"

Unter Windows läuft Exchange (mit eigenen Problemen) und auf den NAS-Geräten eine angepasste
Version der Linux-Komponenten welche syslog statt irgendwelchen JAVA-Apps nutzen. Das trifft auch für
Log-Server auf NAS-Geräten (syslog) zu.

Dann ist es ja gut.

Auch die Trennung von Domänencontroller und Turbomed-DB erscheint mir (außer bei sehr großen Installation,
Lastverteilung) nicht notwendig, da log4j ja nicht mit Domänenadmin-Rechten läuft.

Naja, zumindest die installierten Dienste (fastobjecs, postgrsql) laufen als Lokales System - haben also zugriff auf den Gesamten Rechner!

Wer sich einen Virus eingefangen hat, das Schlupfloch für den Emotet-Virus wurde zumindest gestern beim
Windows-Patch-Day geschlossen, bei dem findet mimikatz spätestens beim nächsten Turbomed-Update
den Hash-Key des Domänenadmins, mit oder ohne log4j.

Sorry? Es gibt keinen Grund, Turbomed als Domänenadministrator zu installieren. Dazu reichen lokale admin Rechte. hoffentlich steht c-it nicht für was hauptberufliches mit IT. OK - Ausnahme man installiert Turbomed auf dem Domänencontroller - siehe oben. Wo ist eigentlich das Problem. Zur Not virtualisiert man den DC (oder den DC und den Turbomed Server). Das kostet noch nicht einmal extra Lizenzgebühren.

Grüße

lcer

PS: hash-Key war das mit NTLM - das gehört auch abgeschaltet.

[lcer]

Ich halte es eher mit dem Thema aus "Hitchhikers Guide to Universe" : don't panic

Router sind i.A Geräte mit einem chronischen RAM-Mangel da fällt Java als Anwendung schon mal raus.
Für die gängigen Fritzboxen hat AVM selbst Entwarnung gegeben. https://avm.de/service/aktuelle-sicherheitshinweise/
Port-Weiterleitungen zu prüfen ist immer richtig, aber was soll bei Mail- und DNS-servern Java-affin sein?

Google kaputt? "DNS Server Java"

Unter Windows läuft Exchange (mit eigenen Problemen) und auf den NAS-Geräten eine angepasste
Version der Linux-Komponenten welche syslog statt irgendwelchen JAVA-Apps nutzen. Das trifft auch für
Log-Server auf NAS-Geräten (syslog) zu.

Dann ist es ja gut.

Auch die Trennung von Domänencontroller und Turbomed-DB erscheint mir (außer bei sehr großen Installation,
Lastverteilung) nicht notwendig, da log4j ja nicht mit Domänenadmin-Rechten läuft.

Naja, zumindest die installierten Dienste (fastobjecs, postgrsql) laufen als Lokales System - haben also zugriff auf den Gesamten Rechner!

Wer sich einen Virus eingefangen hat, das Schlupfloch für den Emotet-Virus wurde zumindest gestern beim
Windows-Patch-Day geschlossen, bei dem findet mimikatz spätestens beim nächsten Turbomed-Update
den Hash-Key des Domänenadmins, mit oder ohne log4j.

Sorry? Es gibt keinen Grund, Turbomed als Domänenadministrator zu installieren. Dazu reichen lokale admin Rechte. hoffentlich steht c-it nicht für was hauptberufliches mit IT. OK - Ausnahme man installiert Turbomed auf dem Domänencontroller - siehe oben. Wo ist eigentlich das Problem. Zur Not virtualisiert man den DC (oder den DC und den Turbomed Server). Das kostet noch nicht einmal extra Lizenzgebühren.

Grüße

lcer

PS: hash-Key war das mit NTLM - das gehört auch abgeschaltet.

[lcer]

Nachtrag zum Thema Gegenmaßnahmen:

der Log4j-Angriff läuft ja so ab, dass nach Einschleusen des primären Schadsoftwarecodes die Schadsoftware nachgeladen wird. Hier würde eine Firewall helfen, die auch ausgehende Verbindungen blockiert. Also alles blocken, nur gewünschtes durchlassen. Leider ist es recht "unklar", welche IP-Addressen bzw. Domänen erforderlich sind. Die Dokumenation ist lückenhaft und die CGM-Tools sind da etwas - sagen wir - inkonsistent. Ein Versuch wäre es aber Wert ... bitte aber nicht im laufenden Praxisbetrieb und am besten auch nicht remote.

Grüße

lcer

[c-it]

hoffentlich steht c-it nicht für was hauptberufliches mit IT.

... die Hoffnung stirbt zuletzt ... Ende.

Natürlich ist die Lage bei großen MVZ's oder GP mit vielen Ärzten anders als
bei EP oder kleinen GP. Da gibt's eher Server essentials und wenn der Server
nicht gleichzeitig als dauerhafte Arbeitsstaion benutzt wird ist das schon gut.
Auch für die EDV kann man hier als Richtlinie §12 SGB V nehmen:
" 1) Die Leistungen müssen ausreichend, zweckmäßig und wirtschaftlich sein; sie dürfen das Maß des Notwendigen nicht überschreiten."

Schönen Tag
c-it

[lcer]

Kurzer Hinweis. Die KBV hat heute die aktualisierten Prüfmodule veröffentlicht. Der Rest Wartezeit aufs Update liegt bei CGM.

Grüße

lcer

[Dozer]

Hier die offizielle Bekanntmachung von Turbomed zum Thema: https://service.turbomed.de/home/00001713.html

[W. Steuber]

aber bei der Benachrichtigung von TM wurde verlautbart, dass sich das update auf nächsten Montag verschiebt - wegen technischer Probleme (die man beim Durchlauf des github-scripts durchaus nachvollziehen kann). Das wären dann gut 10 Tage nach offizieller Bekanntgabe der Warnstufe ROT.
Dieses Verhalten als insuffizient zu sehen ist mehr als legitim, ist aber auf dem Weg der CGM nichs Neues.
Bin froh, bei T2Med eine zeitnahe Programmauffrischung erhalten zu haben (Freitag offzielles update, Samstag Sicherheitsupdate, nichtmal 1 Tag nach Veröffentlichung des exploits).
Lungert trotzdem noch so Einiges an javalogging auf der Festplatte rum, neben Turbomedresten das Laborprogramm und und und....

[Schorsch]

Hat jemand zufällig probiert, ob das manuelle austauschen der jeweils 3 log4j*.jar Dateien in den jeweiligen betroffenen Ordner (mit Version 2.16) funktioniert, wenn die Dateien mit der alten Versionsnummer (2.11) benannt werden?
Würde ja im Prinzip reichen, wenn Turbomed erstmal nicht abstürzt )

[Schorsch]

..also austausch von:

log4j-api-2.11.1.jar
log4j-core-2.11.1.jar
log4j-slf4j-impl-2.11.1.jar

mit:

log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j-impl-2.16.0.jar

und dann wieder umbenennen in:

log4j-api-2.11.1.jar
log4j-core-2.11.1.jar
log4j-slf4j-impl-2.11.1.jar

(beim Smartupdatecenter Standalone scheint es zu funtionieren, da der Dienst sich nach dem Austausch wieder starten lässt)

[Schorsch]

https://github.com/mergebase/log4j-detector

Code: Alles auswählen

c:\******>java -jar log4j-detector-2021.12.14.jar t:\turbomed > hitsTM.txt

Code: Alles auswählen

t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\Asthma\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\Brustkrebs\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\COPD\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\DM1\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\DM2\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\FEK\Bin\xpm-core-4.1.5.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eDMP\4\KHK\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q1\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q2\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q3\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\eHKS\Q4\Bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK\bin\xpm-core-4.2.4.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK\bin\xpm-core-4.2.6.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_3\Bin\xpm-core-4.1.9.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_3\Bin\xpm-ldk-2.2.1.jar!/javafx-swt.jar - java.io.EOFException: Unexpected end of ZLIB input stream
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_4\Bin\xpm-core-4.1.15.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_4\Bin\xpm-ldk-2.3.2.jar!/javafx-swt.jar - java.io.EOFException: Unexpected end of ZLIB input stream
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_5\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_6\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KBV\XPM-Pruefmodul\XPM-LDK.praxis3_2_7\Bin\xpm-core-4.2.3.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM\Client Module\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM\Kim Assist\data\KIM_Client-Modul\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM - Kopie\Client Module!\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\ExtPrg\KIM - Kopie\Kim Assist\data\KIM_Client-Modul\libs\common\log4j-core-2.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\DPP\datenpruefprogramm-4.2.0-jar-with-dependencies.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\packer\TPacker-4.2.5-jar-with-dependencies.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\IV_Verwaltung\data\Data\doku\IQTIG\packer\XPacker-4.2.5-jar-with-dependencies.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\aWinS\secsigner\SecSigner.jar!/certStack.zip - java.io.EOFException: Unexpected end of ZLIB input stream
-- Problem t:\turbomed\Programm\aWinS\secsigner\SecSigner.jar!/scdriver.jar - java.io.EOFException: Unexpected end of ZLIB input stream
-- Problem t:\turbomed\Programm\communicator\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\communicator\plugins\CubePlugin\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\CubePlugin.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\DaleUVCommunication\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\DaleUVCommunication.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\plugins\EVaccinationCertificateService\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\Programm\communicator\plugins\EVaccinationCertificateService.jar!/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
-- Problem t:\turbomed\Programm\communicator\plugins\MedDataPlugin\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\plugins\MedDataPlugin.jar!/lib/h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
-- Problem t:\turbomed\Programm\communicator\SmartUpdateStandalone\lib\h2-1.4.199.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
t:\turbomed\Programm\communicator\SmartUpdateStandalone\lib\log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ SADSMILEY
t:\turbomed\Programm\communicator\updater\lib\log4j-core-2.6.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ SADSMILEY

--> geht auch hiermit über die Kommandozeile nur nicht so schön
findstr /s /i /c:"JndiLookup.class" C:\*.jar

[Heilberger]

Lt. CGM ist ja da Programm TM selbst nicht betroffen.
Ich prüfe die Abrechnung per Prüfmodul aktuell auf einem Stand-alone-Rechner.
Weiß jemand, ob auch DALE-UV eine Gefährdung bringt?? Wir versenden aktuell die Berichte per Post.
Gruß

[Forti]

Lt. CGM ist ja da Programm TM selbst nicht betroffen.
Ich prüfe die Abrechnung per Prüfmodul aktuell auf einem Stand-alone-Rechner.
Weiß jemand, ob auch DALE-UV eine Gefährdung bringt?? Wir versenden aktuell die Berichte per Post.
Gruß

TurboMed ist nicht betroffen.
CGM ASSIST ist ja was Eigenständiges *hust*

DALE-UV ist betroffen, weil es über CGM ASSIST angebastelt ist.

[Schorsch]

CGM Kim und CGM SmartUpdate (Standalone) sind ja auch betroffen.. prinzipiell würde ich auf Aussagen von CGM nicht all zu viel geben.

ich habe mit einer Batch Datei einfach alle potenziellen "log4j*2.XX*jar" gegen die 2.16 ausgetauscht (alte Dateibennung wie vorher). Zumindest läuft Turbomed scheinbar auch so und man kann besser Nachts schlafen.. das "Update" dauert doch wieder bis 23.12... und dann sind wieder hundert neue Fehler eingebaut.

APC Business Edition ist übrigens auch betroffen, das hat vielleicht der ein oder andere auch drauf (USV).

[Landarzt21]

Hat noch jemand bekommen, jetzt setz ich mich glaub doch hin und tausch dateien von hand aus.....

[Schorsch]

Hat noch jemand bekommen, jetzt setz ich mich glaub doch hin und tausch dateien von hand aus.....

Na ein Glück ist ja CGM Turbomed nicht betroffen *Ironie aus*…

evtl. sollte man alle Fernwartungsstools von CGM entfernen?

[Schorsch]

CGM Kim und CGM SmartUpdate (Standalone) sind ja auch betroffen.. prinzipiell würde ich auf Aussagen von CGM nicht all zu viel geben.

ich habe mit einer Batch Datei einfach alle potenziellen "log4j*2.XX*jar" gegen die 2.16 ausgetauscht (alte Dateibennung wie vorher). Zumindest läuft Turbomed scheinbar auch so und man kann besser Nachts schlafen.. das "Update" dauert doch wieder bis 23.12... und dann sind wieder hundert neue Fehler eingebaut.

APC Business Edition ist übrigens auch betroffen, das hat vielleicht der ein oder andere auch drauf (USV).

.. ich präzisiere meine Aussage.. das Update kommt am 23.12.2022!

[Heilberger]

Info der KV Bayern: Abrechnung kann wie bisher übersandt werden. Module der KVB seien von log4j nicht betroffen. Der Dienst Telemed ist heute nicht verfügbar. wir versenden unsere D-Berichte per Post!
Schöne Weihnachten!

[Forti]

Klingt unglaubwürdig.
Das KBV-Prüfmodul ist lt. CGM anfällig.
Und die neue Version kommt erst mit dem - sich verspätenden - Update.

Aber entspannt: Das Modul läuft lokal über die .CON und holt sich nichts aus dem Netz nach.
Und die wird sicherlich nicht kompromittiert sein, wenn PC und das ausgebende TurboMed sauber sind.

[framus]

TurboMed schreibt ja am 17.12.21 folgendes:
„Von einer Abrechnung von Q4/2021 mit bereits ausgelieferten Versionen von CGM TURBOMED raten wir ab, da uns keine Informationen vorliegen, inwieweit die log4j-Schwachstelle bereits ausgenutzt und schadhafter Code in betroffene Software-Module eingeschleust wurde!“

Wir haben bereits vorletzte Woche Probeabrechnungen laufen lassen. Da wusste man noch nichts von der Sicherheitslücke. Könnte dadurch etwas passiert sein? Und wie bekäme man sowas heraus??

Bin besorgt …

[framus]

log4j_Versionen_auf_Server.pdf

Wir finden auf dem Server viele Java-Altlasten, die z.T. out-of-life sind. Erschreckend, dass TurboMed-Updates hier keine Routine zur Bereinigung anbieten. Hier müsste doch mal aufgeräumt werden, oder?