Von der Firma CompuGroup Medical (CGM) wird auch ein Praxis-Verwaltungssystem (PVS) für Zahnärzte vertrieben. Das System ist laut Firmenaussage bei über 7.000 Zahnärzten im Einsatz. Eine anonym bleiben wollende Quelle informierte mich Anfang des Jahres über potentielle Sicherheitsprobleme in dieser Software. Inzwischen hat es ein Software-Update gegeben, mit dem diese Probleme ausgeräumt sein sollten. Ich fasse mal den Sachverhalt in einigen Blog-Beiträgen zusammen.
Die Zahnarzt-Software Z1
Kurz zur Einordnung: Die CompuGroup Medical SE & Co. KGaA (CGM) ist ein börsennotiertes Softwareunternehmen mit Sitz in Koblenz. Die Gruppe entwickelt Software für das Gesundheitswesen. Dazu gehört auch Anwendungssoftware zur Unterstützung ärztlicher und organisatorischer Tätigkeiten in Arztpraxen, Apotheken, medizinischen Laboratorien und Krankenhäusern. Das Unternehmen beschäftigte 2024 nach eigenen Angaben ca. 8.700 Mitarbeiter in 19 Ländern und vertrieb seine Produkte in 60 Länder.
Eines dieser Systeme ist die CGM Z1 Praxis-Verwaltungssoftware für Zahnärzte, die laut Firmenaussage bei mehr als 7000 Zahnärzten im Einsatz ist. CGM ist wohl Marktführer in diesem Bereich.
Hinweis einer Quelle auf Probleme
Zum 10. März 2025 erhielt ich eine Mail einer anonym bleiben wollenden Quelle, die für einen IT-Dienstleister tätig ist. Diese schrieb mir, dass sie im Rahmen seiner Tätigkeit regelmäßig Berührungspunkte mit Zahnarztpraxen habe.
Einer der Marktführer in diesem Bereich sei die Firma CompuGroup Medical, kurz CGM, u.a. börsennotiert. Diese biete das oben erwähnte PVS Z1 für Zahnärzte an, welches von weit mehr als 7.000 Zahnärzten genutzt werde. Die Z1 Praxisverwaltungssoftware decke alle Vorgänge in einer Arztpraxis – Patientenakten, Abrechnung, je nach Ausbaustufe auch Terminverwaltung, Wartezimmervorgänge etc. pp. – ab.
Setup der Software als Problemfall
Im Rahmen ihrer Tätigkeit mit dieser Software habe die Quelle einige problematische Feststellungen gemacht, gibt sie an und teilte mir ihre Beobachtungen mit. Laut Quelle vertreibt die CGM offiziell keine Installationsanleitungen für die Software Z1. Die Quelle vermutet, damit nur "geschulte" Fachpartner/Vertriebler o.ä. in der Lage sind, die Software zu installieren. Erfahrene IT-Mitarbeiter sollten aber mit der Zeit dahinter kommen, wie das Setup dieser Software in den Praxen abläuft, schrieb die Quelle.
Es gibt einen Installer für die Software, die seinerseits auf einen erforderlichen MS-SQL-Server zugreift (siehe obigen Sceenshot), für den wiederum auf jedem System ein DSN dafür eingerichtet sein muss. Die Quelle schrieb, dass sie mangels offizieller Installationsanweisungen und -scripte mal genauer geschaut habe, wie die Z1-Installationen, zu denen sie beruflich Zugang hatte, eingerichtet wurden.
Feste Zugangsdaten im Setup
Die Quelle gibt an, dass sie erschreckenderweise festgestellt habe, dass sowohl der Superadmin sa, als auch der Client-Nutzer z1 das immer das gleiche Passwort für den Zugriff auf die SQL-Datenbank haben. Das Setup der Z1-Software erwarte dies im Regelfall auch so, denn das Passwort finde sich als fester String in den Setup-Dateien.
Das ist kein Problem, wenn diese Daten nach der Installation vom IT-Supporter für die Praxis individualisiert werden. Die Quelle schrieb, dass mit entsprechender Fachkenntnis und manuellem Aufwand es möglich sei, diese Passwörter abzuändern. Die Quelle vermutet, aus Beobachtungen in den Praxen, das dies nur in einem Bruchteil der 7000 Praxen passiert sein dürfte.
Backup der Z1-Instanzen unverschlüsselt
Ferner hat die Quelle sich ein Backup der Z1-Instanzen angeschaut. Das Backup sei im Wesentlichen eine SQL-Datei, welche als Dump alle Statements zum Wiederherstellen der Datenbank umfasst, schrieb mir die Quelle. Dabei seien natürlich alle Patientendaten und Diagnosen sowie alles, was irgendwie in der Datenbank steht (Stichwort Patientenakte) im Klartext enthalten. Das ist natürlich ein potentielles Problem, wer Zugriff auf diese Backups bekommt, dem liegen alle Patientendaten offen.
Die Wiederherstellung eines Backups sein nur möglich, schrieb die Quelle, wenn man dafür ein Passwort von der Hotline erhält. Ansonsten weigert sich das Z1-Tool, eine Datensicherung einzulesen. Das Passwort ließ sich auf technischen Wegen beschaffen, es ist vierstellig und recht trivial, merkt die Quelle an.
Zugriff auf SQL-Server per Netzwerk
Der Schluss der Quelle war: sofern eine Person – es müsse nicht einmal ein Angreifer sein – Zugang zu einem Netzwerk bekommt, in welchem die Z1-Software genutzt wird, ist nach seinem Verständnis Tür und Tor zum Zugriff auf die SQL-Datenbank mit allen Informationen möglich.
Ein kurzer nmap-Scan reiche aus, um den MSSQL-Server zu finden, und sich an diesem mit den Standard-Zugangsdaten zu authentifizieren. Alle weiteren Passwörter, die Z1 selbst zur alltäglichen Anmeldung vom Nutzer einfordert, sind dann nicht mehr relevant.
Es hängt am IT-Dienstleister
Die Quelle hat mir dann noch einige Überlegungen zum Sachverhalt mitgeteilt, die ich nachfolgend mal zusammenfassen möchte.
Dienstleister erforderlich
(Zahn-)Ärzte haben oft nicht die Zeit und das Fachwissen, eine solche Installation vollumfänglich allein zu betreuen und sind daher auf die Mitwirkung eines entsprechenden Dienstleisters angewiesen. Als offizielle Partner gibt es davon in Deutschland sehr wenige.
Sehr problematischer Setup-Ansatz
In jedem Fall widersprechen hart codierte Passwörter einer guten Sicherheitspraxis. Immer wenn bei der Installation gepatzt wird, verbleiben die Standard-Passwörter in der Installation. Wer die kennt, hat per Netzwerk Zugriff auf die Datenbank. Liegen die Daten unverschlüsselt vor, können Unbefugte alles einsehen – die in der Software abgefragten Passwörter sind nutzlos.
Großes Problem bei Backup/Wiederherstellung
Auch das mehr oder weniger unverschlüsselt angefertigte Backup ist ein Problem. Unbefugte können bei Zugriff auf Backup-Dateien direkt an die Patientendaten gelangen. Der Anwender muss also besondere Maßnahmen treffen, um angefertigte Backups vor dem Zugriff unbefugter Dritter zu schützen.
Die Quelle wies noch auf ein weiteres Problem hin. Es gebe vor allem eine Einschränkung bei der Wiederherstellung. Was, wenn die Hotline im Notfall nicht erreichbar ist, weil z.B. Wochenende ist?
Unerfreuliches Fazit, was tun?
Der Schluss der Quelle lautete, dass bei dem oben skizzierten Ansatz so ziemlich gegen alle Grundsätze:
- DSGVO (Stand der Technik),
- BSI-Grundschutz,
- KBV-Sicherheitsrichtlinie
und was noch alles verstoßen wird. Die Quelle meinte dazu: "Ich fürchte aber, kaum ein Arzt hat schon einmal was von der ODBC-Datenquellenverwaltung in Windows gehört und wäre ansatzweise in der Lage, das Passwort eines MSSQL-Users zu ändern."
Die Quelle schloss seine Mail mit den Worten ab: "Vielleicht gibt es ja weitere Nutzer, die für andere CGM-Software Ähnliches bestätigen können?" Denn theoretisch könnte es ja sein, dass alle anderen Praxen außerhalb des Wirkungskreises der Quelle "sauber mit geänderten Passwörtern und verschlüsselten Backups" aufgesetzt sind.
Zudem hegte die Quelle Bedenken, plötzlich Repressalien oder beruflichen Konsequenzen zu erleiden. Er meinte, dass der Anbieter "harte Positionen" verfolgt. und der Fall Modern Solution mit dem angerichteten Flurschaden ist bestens bekannt.
Wir haben uns daher zu einem Responsible Disclosure entschlossen, bei dem ich den Fall aufbereite, den Sachstand kläre und erst nach Nachbesserungen veröffentliche. Im Hinblick auf "Repressalien" ist die Sachlage folgende:
- Ich kenne die Identität der Quelle nicht, die Kommunikation war zwar etwas mühsam, aber die Informationen haben mich erreicht, da die Quelle quasi ein "Poll-Verfahren" nutzte, um über kurzzeitig aktive Adressen den Sachstand abzufragen.
- Als Blogger habe ich nie Zugriff auf entsprechende Z1-Instanzen oder Daten gehabt und werde hier auch keine Daten wie Kennwörter etc., die mir über die Quelle zur Kenntnis gelangt sind, veröffentlichen.
Zudem berufe ich mich als Medienvertreter auf das Recht auf Quellenschutz. Für den "Whistle Blower" ist also ein doppelter Schutz eingebaut. In Teil 2 beschreibe ich, wie ich versucht habe, das Thema ohne Öffentlichkeit zu klären. In Teil 3 geht es um die Frage, was in der Zwischenzeit an Abhilfe passiert ist. Es sind seit März 2025 ja einige Monate vergangen.
Artikelreihe
Zahnarzt Praxis-Verwaltung-System (PVS): Sicherheitslücken beim CGM Z1 – Teil 1
Reaktionen von CGM auf Meldung der Sicherheitslücken beim Z1-PVS – Teil 2
Korrekturen des Z1 PVS durch CGM und aktueller Stand – Teil 3
Ähnliche Beiträge:
Bundeswehr bekommt Arzt- und Zahnarztinformationssysteme von CompuGroup Medical
Frage: Wie steht es um die Sicherheit unserer Medizin(geräte)-Technik?
Desaster (Zuverlässigkeit, Sicherheit) bei der Telematik-Infrastruktur im Gesundheitswesen
Medisign: Erneut langer Telematik-Ausfall (15.4.2024) – gematik prüft den Anbieter
Laufzeitverlängerung bei TI-Konnektoren läuft an, aber Ausfälle nach dem Update
Desaster (Zuverlässigkeit, Sicherheit) bei der Telematik-Infrastruktur im Gesundheitswesen).
MVP: 2013 – 2016
Die Erlebnisse dürften für Fachanwendungen nicht unüblich sein. Da könnte man eine eigene Serie zu machen, was sich bei solchen Branchenlösungen an Altlasten und "Worst Practice" im Laufe der Jahre angesammelt hat. Das überhaupt ein funktionierender Installer dabei ist, ist erstaunlich. Installationsdokumentation würde Sicherheitsmängel nur schriftlich fixieren, was man als Softwareanbieter nicht gerne möchte. Was auch nicht beliebt ist, ist ein engagierte IT-Support einer Drittfirma, der Fragen hat. Danke für den Einblick in diese Software.
Wo ist das Problem? Als Patienten erheben wir unsere Ansprüche auf Schadensersatz und Schmerzensgeld stets gegen die Leistungserbringer, also Ärzte. Sollen die sich doch mit ihren Zulieferern herumschlagen und diese in Regress nehmen. Da können die Halbgötter in Weiss doch mal zeigen ob sie wirklich solche Tausendsassas sind.
Und da wären dann noch die Volksvertretungen, die mit ihren legislativen Ergüssen diesen ganzen Wahnsinn eines digitalisierten Gesundheitswesens erst ermöglicht und losgetreten haben. Dann geht halt nicht wählen.
Ich sehe keinen Grund weshalb ich als Patient CGM grollen sollte, die müssen halt auch schauen wo sie bleiben und nutzen den Rahmen. Wenn ich als Patient ständig zum Arzt renne, darf ich mich auch nicht wundern, dass immer mehr Daten anfallen, die in falsche Hände geraten können. Weniger ist mehr.
Satire bitte kennzeichnen.
???
Ein wenig unstrukturiert die Antwort oder überlese ich was,
Nebenbei: Ich habe beim Zahnarzt nie „zum Arzt Renner" gesehen.
???
Betr. "Ein wenig unstrukturiert die Antwort oder überlese ich was":
Wie hätten Sie es denn gerne? Inhaltsverzeichnis, Fussnotenapparat, Executive Summary? Der Kern meines Beitrages ist "Man schlägt den Sack und meint den Esel". Kritik an CGM mag sachlich streckenweise zutreffend sein, geht aber am Ziel vorbei. Die Fehler liegen im System nicht bei einzelnen Akteuren.
Betr. "Ein wenig unstrukturiert die Antwort oder überlese ich was, Nebenbei: Ich habe beim Zahnarzt nie „zum Arzt Renner" gesehen."":
Natürlich nicht. Ohne PZR und Zahnspangen kann ja kein Mensch überleben, Irionie aus. Befassen Sie sich mal mit zahnärztlichem Leistungsrecht. Der öffentlich einsehbare GOZ Kommentar der Bundeszahnärztekammer bietet Hand.
> Dann geht halt nicht wählen.
Typische Stammtischparolen. Wer nicht wählen geht, darf auch über die Politik nicht jammern, wenn einem die Wahlergebnisse und deren Ergüssen nicht passen.
Den Schuh können Sie sich selber anziehen, Ihre Argumentation ist noch unter dem angesprochenen Niveau. Merke: Die Wahrnehmung verfassungsmässiger Rechte ist nicht an die Teilnahme an Wahlen geknüpft.
Sehe ich genauso wie Peter Vorstatt. Ich mag CGM auch nicht. Das ist ein ziemlich übler Verein, mit Drückermethoden, unehrlich bis auf die Knochen. Kein Wunder, bei dem Chef.
Aber ein Zahnarzt ist ein Zahnarzt und kein EDV-Dienstleister. Ich hab eine Kneifzange, ziehe aber trotzdem keine Zähne.
Wenn in der EDV was schief geht, dann höhnt die Meute "Da waren wohl Fachleute am Werk!". Und plötzlich sollen es Zahnärzte selber können?
Schuster bleib bei deinen Leisten!
Dem Volk soll es egal sein und nicht wählen gehen? Bei zusammenhangloser posttraumatischer Theatralik fragen Sie Ihren Arzt.
Das lustige ist ja wie dieses Passwort heißt, daraus kann man ja die uralt uralt abhängigkeiten ablesen :). Aber ja deswegen kam ja ihr "Sicherheitsupdate", was dann neue passwörter für alle datenbank zugänge erfoderlich gemacht hat und auch beim der sicherung ein pw vorraussetzt. Ich glaube da hatten viele Praxen spaß mit dem update, das lief alles andere als rund.
Das habe ich mir auch gedacht, es lässt auf jeden Fall Rückschlüsse auf das vorher genutzte Datenbanksystem zu…
Ich habe mir mal den Spaß erlaubt und in der Z1 Datenbank die Kennwörter für KIM gesucht. Dort wurde auch wieder alles gegeben mit der Art der "Verschlüsselung".
Hat jemand einen Tipp, wie man die Datenbankverschlüsselung für Z1.Pro aktiviert? Das wird seit den letzten beiden Updates angemeckert, aber keinerlei Infos oder Anleitungen zur Verfügung gestellt. Es gibt ja schon unterschiedliche Ansatzpunkte und die Software sollte danach noch funktionieren. CGM gibt an ihre Systempartner offenbar keine Infos heraus, so zumindest die Info vom Partner im Raum Bremen.
du meinst die transportverschlüsselung? DB an sich sollte verschlüsselt sein, nach dem update auch mit eurem Kenntwort.
Ich möchte nur ergänzen, dass ich mindestens 2 PVS (nicht CGM) kenne, die ebenso gestaltet sind.
• DB-Kennwort fix und trivial zu ermitteln
• DB-Backup unverschlüsselt
Wenn man keine zusätzlichen additiven Maßnahmen zur Absicherung ergreift (z.B. DB-Zugriff nur von localhost und Drive-Encryption des Servers) sieht das in tausenden von Praxen identisch aus!
Lasse mir die Infos privat per Mail zukommen. Verschlüsselung ist möglich. Ich schaue, was ich da über die Datenschutzaufsicht tun kann.
u.a. eines der vorgenannten Beispiele:
https://www.aend.de/article/236045
Hab es auf dem Radar, findet sich in Teil 2 zur Artikelreihe Neues zur elektronischen Patientenakte (ePA): Theorien, Ausfälle und mehr – Teil 1
Danke für den Hinweis, stützt meine oben gemachte Aussage "Die Fehler liegen im System nicht bei einzelnen Akteuren.".
Die Bundeswehr wird sich freuen.
Den Patienten wird es egal sein, siehe die geringe Anzahl an Widersprüchen bei der ePA.
Wartet mal ab bis ihr die Zustände in anderen PVS von CGM seht, da kommt ein Knaller nach dem nächsten..
Tatsächlich eher die DB-Verschlüsselung selbst. Beim Update wurden ja nur Kennwörter geändert.
Transportverschlüsselung müsste aktiv sein (MSSQL Standard), aber die Daten selbst sind nicht verschlüsselt. Das wird bei den letzten Quartalsupdates angemerkt.
Der SQL Server 2019 Standard wurde damals über den SQL Configurator von CGM installiert.
Die Alternative bei anderen Softwareanbietern in dem Bereich sieht dann gerne so aus:
dateibasierte Datenbanken, die mitsamt Anwendung und weiteren Daten auf einem Fileshare liegen – Vollzugriff für alle User erforderlich.
Dampsoft DS-Win wäre so ein Beispiel. Serverumzüge laufen bequem ala "robocopy quellfreigabe zielfreigabe /MIR /COPYALL", fertig. Datendiebstahl leider auf dieselbe Weise… So ist das wohl mit Software aus 1986.
das ist aber leider nicht nur bei PVS-Systemen aus der Medizin so!
Das scheint Gang & Gebe bei einigen Softwareherstellern zu sein -> "ja, alle (Jeder) braucht Zugriff auf den Programmordner auf dem Server, was stellen Sie sich so an! Der große IT-DL aus … mit Namen … hat da doch auch kein Problem mit."
Und nein, man kann sich nicht wehren als einzelner IT-DL, wenn die Fachsoftware "alternativlos" ist… ;-)
Dampsoft wird früher oder später auf SQL umstellen, Charly nutzt auch ein DB PW für Alle…
Wie sonst sollen die Support-Techniker der Anbieter in der DB etwas "fixen"? Der Kunde merkt sich doch keine Passwörter oder verliert sie und die Anbieter sollten keine Liste mit allen Kunden-DB-Passwörter führen, das wäre ja noch schlimmer…
Ein verschlüsselter String im Setup wäre wenigstens mal ein Anfang…
zu Charly hatte ich was gesehen, aber noch keine Zeit, das aufzubereiten. Es ist ein Desaster, was ich so am Rande zu PVS mitbekomme.
You lost me at DSN Datenquelle…
Wenn die MSSQL als ODBC System-DSN am System (offensichtlich mit Auth) hinterlegt ist, dann kann jedes Programm, jedes Skript SQL Abfragen gegen diese absetzen.
Wenn ein Entwickler im Jahr 2025 noch ODBC verwendet (vor allem mit einem modernen MSSQL dahiner) der hat schlicht den Knall nicht gehört. Das kann man als Notlösung noch nutzen, wenn alle anderen Wege scheitern, doch nicht als Default!
Odbc ist für C++ o.ä notwendig. Vom nativen Treiber hat sich MS verabschiedet und OleDb stirbt seit Jahren vor sich hin. Ado.net ist ideal, erfordert aber eine komplette Neuschreibung und wer macht das ohne Not?
1 +
> Odbc ist für C++ o.ä notwendig.
What? DSNs in der ODBC Verwaltung stehen allen Programmen, COM-Komponenten, Skripten, Programmiersprachen zur Verfügung, sogar einem Excel. Ich könnte Dich jetzt schocken. Man könnte sogar per DCOM remote von einem anderen Rechner ohne DSN drauf zugreifen.
> Vom nativen Treiber hat sich MS verabschiedet
Hab ich was verpasst? Seit NT4 Zeiten stecken in jedem Windows weiterhin die Basis-ODBC Treiber für MSSQL, Access & Co und werden von minderbemittelten Software-Stacks mit MDAC, ADO und Co um weitere bzw. "aktuellere" per Redist mitinstalliert.
Was ist dann mit ODBC User-DSN und Always Encrypted?
Bei CGM Medistar läuft es identisch. Dort ist eine Oracle Ora19c DB im Einsatz die mit Benutzer *** und Passwort *** in allen Praxen identisch konfiguriert ist.
Diese Informationen enthält man sogar auf Nachfrage unproblematisch an der Hotline (z.B., wenn man sie für das Veeam Backup benötigt).
——–
GB: Die Zugangsdaten habe ich mit *** verschleiert, um keine schlafenden Hunde in Versuchung zu führen. Wenn jemand mit Details bei mir aufwarten kann (verschlüsselte E-Mail ist möglich, siehe Impressum), spiele ich wieder über Bande.
Das gilt übrigens auch für PVS anderer Hersteller – manchmal kann ein Landesdatenschutzbeauftragter da durchaus Feuer machen. Und ich habe das Gefühl, dass so einige aus der Ärzteschaft hier mitlesen.