log4j

[neckarpraxis]

Liebes Forum,

hat schon jemand eine Idee/ Strategie wie mit der nun auch über die Medien bekannt gewordenen Sicherheitslücke in der Java-Bibliothek (log4j) umzugehen ist.
Genaugenommen wäre hier ja CGM in der Pflicht...
Die genannte Bibliothek wird wohl bei TM an verschiedensten Stellen, nicht zuletzt auch der TI, verwendet.

[Lazarus]

Man kann davon ausgehen. dass die 3 ehrenamtlichen, also unbezahlten Entwickler bei Apache bald ein weltweites Patch für die betroffenen 30.000.000.000 Geräte herausgeben werden.
Oder anders ausgedrückt, das sind die Folgen, wenn man open source code umsonst runterlädt und teuer weiterverkauft.
Der Patch wird kommen, aber die Hacker werden ihre Schadsoftware schon längst eingeschleust haben.

[INP]

Ist wirklich sicher das TM das Modul log4j einsetzt? Denn nur weil TM Java einsetzt wird, heißt es noch nicht das auch das Modul log4j benutzt wird. Aber selbst wenn es eingesetzt wird, die Lücke kann nur ausgenutzt werden, wenn über einen Web-Server (Apache) mit aktiven log4j, eine manipulierte Browser Anfrage verarbeitet wird. Da aber in TM kein Web-Server eingesetzt wird, sehe ich da erst mal keine Probleme.

Da gibt es ganz andere (Sicherheits-)Probleme die ein Sorgen machen sollten.

- INP -

[RAMöller]

Eine etwas offiziellere Verlautbarung von CGM wäre mir lieber als Vermutungen.
Die Server stehen in den jeweiligen Firmen, werden kompromittiert und das wars dann.
Die jetzige rote Alarm "ziemlich wehrlos" ist eine Stufe vor "völlig wehrlos"

[h-o]

Es betrifft wohl auch andere PVS-Hersteller, die TI-Anwendungen nutzen.

Auf gematik.de (ggf. nach oben blättern) steht, dass bestimmte TI-Dienste deswegen vorrübergehend abgeschaltet würden.

[LandyMan]

Kaum zu glauben wie schnell manche Hersteller reagieren und andere nicht. Das T2med Entwicklerteam hatte bereits am vergangenen Freitag gegen 23 Uhr ein Sicherheits-Update veröffentlicht und alle Anwender informiert. Chapeau! So geht Service… Mal sehen wann sich Turbomed rührt...

[nmndoc]

Es betrifft wohl auch andere PVS-Hersteller, die TI-Anwendungen nutzen.

Auf gematik.de (ggf. nach oben blättern) steht, dass bestimmte TI-Dienste deswegen vorrübergehend abgeschaltet würden.

ja, schon "lustig":

"Aufgrund der aktuellen Meldung des BSI zur "log4j" Schwachstelle mussten einige Dienste der Telematikinfrastruktur präventiv vom Internet getrennt werden."

Habe ich da etwas verpasst? Die Dienste sind doch im eigenen TI-(VPN-)Netz (so wie auch die KVSafeNet-Dienste etc) und damit eben genau per Definition NICHT mit "dem" Internet verbunden?

[c-it]

Habe ich da etwas verpasst? Die Dienste sind doch im eigenen TI-(VPN-)Netz (so wie auch die KVSafeNet-Dienste etc) und damit eben genau per Definition NICHT mit "dem" Internet verbunden?

, stimmt, aber selbst die gematic traut ihrer eigenen Aussage wohl nicht ....

Schönen Tag
c-it

[Forti]

Es ist durchaus denkbar, die Schwachstelle aus einer per Konnektor angebundenen Praxis heraus auszunutzen.
Inwieweit das dann zurückschlagen kann auf Praxen, die dann auf verwundete Server zugreifen, kann ich nicht abschließend beurteilen.

By the way: Das KBV-Prüfmodul ist auch betroffen. Und das sitzt in den Praxen.

[Forti]

Um die Sicherheitslücke auszunutzen, reichen wenige Handgriffe. Diese werden im Regelfall auch nicht durch Virenscanner beachtet.
Ob die folgenden Module von CGM wirklich angreifbar sind (oder nur die log4j-Bibliotheken enthalten ohne sie einzubinden), vermag ich nicht zu beurteilen.
Einen Test auf Produktivsystemen spare ich mir bzw. den Praxen. Es ist aber anzunehmen, dass die Bibliotheken nicht zum Spaß mitgeliefert werden.
Irgendwo im CONNECT-Test habe ich auch mal die Zeichenfolge log4j über den Schirm huschen sehen.


!! KIM-Clientmodul CGM: log4j 2.11.2

!! FHIR: 2.14.1

!! CGM ASSIST: 2.11.1
(und damit wohl alles, was unter TM/Programm/communicator/plugins zu finden ist, z.B. Cube, DALE-UV, Telematik, Privadis, Impfzertifikatsservice, Clickdoc, Armin, KV CONNECT, KIM-Frontend (Mailer)?, eArztbrief KOM-LE)

Alte 1.2er, die wohl nicht betroffen sein sollen:
CGM Live / Vita-X: 1.2.14
DGUV-Prüfmodul: 1.2.9, .14, .15
dpdmax 1.2.15
ELAT 1.2.16
Praxischeck 1.2.16

[Forti]

Um CGM etwas in Schutz zu nehmen: Mit dieser Sicherheitlücke war nicht zu rechnen.

Jetzt kommt es vielmehr darauf an, was CGM mit den Erträgen aus den Arztpraxen wie schnell und wie erfolgreich unternimmt, um ein rechts- und betriebssicheres Weiterarbeiten zu ermöglichen.

[Forti]

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

[lcer]

Hallo,

was kann/sollte man tun? Zunächst muss ein externer Angreifer, der die Lücke ausnutzen will, irgendwie einen Dienst erreichen, der verwundbar ist.

Daher sollte man prüfen, ob der verwendete Internetrouter betroffen ist. Vermutlich ist das Logging in Router-betriebssystemen eher nicht über Java realisisert, sicherheitshalber sollte man das prüfen.

Weiterhin sollte man prüfen, ob auf dem Router (NAT)Portweiterleitungen zu Servern/PCs eingetragen sind. Die ist beispielsweise der Fall, wenn man eigene Mail- oder DNS-Server verwendet, aber auch bei IP-Telefonanlagen. Für alle Weiterleitungen muss man nun prüfen, ob die betroffenen Systeme anfälliges Java verwenden. Ggf. sind diese System auch temporär abzuschalten, falls kein ?Patch verfügbar ist.!

Verwendet man Weiterleitungen für das Router-System-Log muss auch auch diese Weiterleitungsziele prüfen (eigener Logserver, z.B. auf NAS).

Sind alle von außen erreichbaren Systeme (und deren Logging-Anhängsel) nicht betroffen, hat man erst mal etwas Luft. Die inneren Systeme (Turbomed-Server etc.) sollten natürlich trotzdem schnellstmöglich gepatcht werden, da man ja nicht ausschließen kann, dass sich Angreifer einen anderen Weg ins interne Netzwerk suchen und sich dann dort austoben.

Wichtig wäre hier noch, das der Turbomedserver nicht gleichzeitig die Domänencontroller-Rolle innehat. Eigentlich sollte so eine Installation nicht vorkommen, aber in der Praxis .... In so einem Fall kann über die log4j-Lücke direkt Code mit Domänenadministratorrechten ausgeführt werden - und man hat gleich verloren. Falls jemand also so etwas installiert hat, sollte er schnellstmöglich mit seinem IT-Partner reden und den Domänencontroller vom Turbomedserver trennen.

Zwischenzeitlich sollte man seine Backups und die Dokumentation mal überprüfen - sind die auch tauglich um das System wiederherzustellen?

Grüße

lcer

[DocET]

Im KocoBox-Administratorhandbuch S. 184 findet sich folgende Fehlermeldung:

20502 -> Error -> Technical Fehler in der Kommunikation zwischen AK (Anwendungskonnektor) und NK (Netzkonnektor) -> „In der Kommunikation zwischen der NK und AK JVM (Java Virtual Machine) liegt ein Fehler vor“

Ist die naheliegende Schlussfolgerung richtig, dass in der KocoBox eine virtualisierte Java Applikation läuft? Leider äußert sich der Hersteller nicht.

Dank und Gruß, DocET

[c-it]

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?
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.
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.
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.
Also schauen wir wie schnell CGM die Java-Bibliotheken erneuert. Das Netz der TI kennt als VPN-Netz
immer den Ausgangspunkt (Konnektor der Praxis) einer Attacke, dafür wird kein Arzt sein Netz hergeben.

Einen schönen Tag
c-it

[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