Reaktionen von CGM auf Meldung der Sicherheitslücken beim Z1-PVS – Teil 2

In Teil 1 hatte ich ja von Unzulänglichkeiten beim Setup des von der Firma CompuGroup Medical (CGM) angebotenen Praxis-Verwaltungssystems (PVS) bei Zahnärzten berichtet, auf welche mich eine ungenannt bleiben wollende Quelle hingewiesen hat. In Teil 2 skizziere ich, wie ich den Sachverhalt versucht habe zu klären und was das Unternehmen dazu schreibt.

Wie bereits in Teil 1 erwähnt, äußerte die Quelle Bedenken, durch eine Offenlegung Repressalien oder beruflichen Konsequenzen zu erleiden. Ich habe daher als Vertreter der Medien die Aufgabe übernommen, den Fall weiter zu verfolgen.

Aber wie geht man dabei vor? In manchen Fällen rufe ich direkt beim Hersteller an und bitte um eine Kontaktaufnahme der Sicherheitsverantwortlichen. Habe ich bei einer Sparkassen-Software so gehandhabt, bei der ähnliche SQL-Passwort-Probleme auftraten. Habe ich auch bei VW so gehandhabt, wo eine Händler-Software ähnliche Probleme zeigte.

In anderen Fällen schalte ich den zuständigen Datenschutzbeauftragten ein. Das war bei Bauhaus nach einem Leak beispielsweise der Fall, nachdem ich bei einem Anruf bei der Zentrale nicht weiter kam.

Einschaltung des LfD von Rheinland-Pfalz

Im Fall von CGM, die den Hauptsitz in Koblenz haben, beschloss ich bei der Presseabteilung des Beauftragten für Datenschutz und Informationssicherheit (LfD) von Rheinland-Pfalz nachzufragen, ob sie sich als Zuständig erachten, einen bestimmten Sachverhalt mit dem verantwortlichen Unternehmen zu klären.

In einer kurzen Mail vom 11. März 2025 umriss ich den Sachverhalt, dass eine ungenannt bleiben wollende Quelle einige problematische Sachverhalte bei der von CGM vertriebenen Software Z1 für Zahnärzte festgestellt und mit mitgeteilt habe.

Erwähnt wurde in der Mail an den LfD, dass laut meiner Quelle die Zahnarzt-Software Z1 der CompuGroup Medical in der Standard-Installation mit festen Zugangsdaten für die verwendete SQL-Datenbank ausgeliefert werde. Mit Kenntnis der Zugangsdaten, die sich über die Installationsprozeduren ermitteln lassen, wäre es Dritten ein leichtes, auf die betreffenden Datenbank zuzugreifen.

Das sei einerseits ein gravierendes Sicherheitsproblem, andererseits dürfte dies auch DSGVO-relevant werden, wenn auf Patientendaten zugegriffen werden könnte, erwähnte ich in der Mail. Denn die in der Zahnarztsoftware Z1 von CGM eingebauten Sicherheitsabfragen würden nicht mehr greifen, wenn Unbefugte auf die SQL-Datenbank Zugriff haben.

Zudem erwähnte ich, dass es sich andeutet, dass Backups der Datenbank SQL-Dumps enthalten, die nur durch triviale vierstellige PINs gesichert sind. Ich habe alles bewusst im vagen gehalten, da ich keine Kommunikation über eine verschlüsselte Verbindung führen konnte. Zudem gab es den Hinweis, das ich die nur Informationen nur aus einer anonymen Quelle bekommen habe, aber zu gegebener Zeit über den Sachverhalt in meinem Blog zu berichten plane. Die Rückmeldung des LfD von Rheinland-Pfalz war, dass sie sich als Zuständig erachten und bei der CompuGroup Medical nachfragen.

Rückmeldung mit Antwort der CGM

Es gab zum 11. und 14. März 2025 zwei Kontakte mit dem LfD, wo noch Informationen nachgefragt wurden, sowie die Information, dass man von CGM eine Stellungnahme angefordert habe und um Geduld bitte. Zum 20. Mai 2025 erreichte mich eine Zwischennachricht des LfD mit den Einlassungen der CGM. Ich stelle diese Aussagen mal von mir weitgehend unkommentiert hier im Blog ein.

Hinterlegte Zugangsdaten zur Datenbank

Zum Thema, dass ggf. feste Zugangsdaten für die Datenbank beim Setup eingerichtet werden, antwortete der LfD: Die von Ihnen bzw. Ihrer Quelle aufgestellte Behauptung, dass in der Standard-Installation des Produktes "Z1" bzw. "Z1.PRO" des Herstellers CGM die Zugangsdaten für die verwendete SQL-Datenbank festgelegt seien, kann ich so nicht bestätigen bzw. nachvollziehen.

Der LfD formulierte diese Antwort auf Basis der Ausführungen der CGM. In der Antwort des LfD hieß es, dass im Rahmen der Installation ein Kennwort für den administrativen Datenbankzugriff und ein Kennwort für den Z1-Datenbankzugriff erfasst werde. Die Ausgestaltung dieser Kennwörter obliege der Person, die die Installation durchführt.

Regelmäßig dürfte es sich hierbei um einen im Auftrag der verantwortlichen Arztpraxis tätigen Dienstleister handeln. Im hierfür vorgesehenen Installationsdialog werde auf die Kritikalität der Kennwörter hingewiesen und die Empfehlungen des BSI angegeben. Ein systemseitig festgelegtes oder in der Installationsdokumentation vorgegebenes Kennwort existiert nach Angaben der CGM nicht.

Der Dienstleister trägt die Verantwortung

In der Rückmeldung wurde also der für die Installation verantwortliche Dienstleister in die Pflicht genommen, was erst einmal aus rechtlicher Sicht so festlegbar ist. Ob das aus sicherheitstechnischer Sicht klug ist, steht auf einem anderen Blatt.

Hinsichtlich des technischen Sachverhalts, dass beim Setup ein Passwort angefragt werde, gab es allerdings eine Diskrepanz zwischen den Aussagen in der oben zitierten Stellungnahme und den Beobachtungen meiner Quelle.

Die Quelle schrieb mir, dass nach ihrer Kenntnis beim Installationspaket ein Tool dabei sei, welches die ODBC-Quelle exakt immer gleich anlegt und entsprechende (Vorgabe-)Daten erwartet (siehe Maske in obiger Abbildung, wo kein Feld zur Passwort-Vergabe zu sehen ist).

Der Dienstleister könne natürlich vorab manuell die SQL-Datenbank als Datenquelle mit anderen Passwörtern einrichten, schrieb meine Quelle. Allerdings ist die Vermutung, dass dies kein Dienstleister so handhabt. In den Praxen, in denen die Quelle  Zugang zu den Netzwerken erhielt, war das jedenfalls nicht durchgeführt worden, sondern die Standard-Zugangsdaten galten.

Den Widerspruch konnte ich nicht auflösen und der LfD deutete an, dass er noch Zeit zur weiteren Klärung brauche. Meine Quelle widersprach den obigen Ausführungen und bot mir noch an, mir selbst einen Überblick zu verschaffen, indem ich mir die Setups ansehe – was ich aber aus diversen Gründen nicht angenommen habe. Die Beschreibungen der Quelle klangen jedenfalls plausibel und nachvollziehbar (aus Sicherheitsgründen lege ich hier keine Details offen).

Die Quelle bestätigte aber, dass ein Dienstleister die Vorgaben für Benutzer und Passwort zum Zugriff auf die Datenbank (Oracle SQL oder Microsoft Access) in der Datenbank und anschließend in der ODBC-Datenquelle aller Clients selbst anpassen könne. Nur mache das halt niemand, zumindest nicht in den Praxen, in denen die Quelle Zugriff erhielt.

Das Thema Verschlüsselung

Der zweite Punkt, den ich in Teil 1 sowie in der Mail an den LfD angesprochen habe, war die unverschlüsselte Speicherung der Daten in den angefertigten Backups. Hier ließ mich die Antwort des LfD etwas ratlos zurück. Denn in der Antwort hieß es: Weiterhin schreiben Sie, dass keine Verschlüsselung stattfinde. Hierbei ist zwischen einer Transportverschlüsselung der Kommunikation zwischen dem Client und der Datenbank und einer Inhaltsverschlüsselung der in der Datenbank abgelegten Inhalte zu unterscheiden.

Eine Transportverschlüsselung sei standardmäßig für alle von der Software unterstützten und die Systemanforderungen erfüllenden Datenbanken vorgesehen, hieß es. Allerdings könne nicht generell ausgeschlossen werden, dass in Einzelfällen auf Seiten einer Arztpraxis veraltete Datenbankversionen im Einsatz seien, die diese Anforderungen nicht erfüllen. Solche Fälle seien der CGM allerdings nicht bekannt.

Es werde nicht davon ausgegangen, dass jenseits seltener Einzelfälle entsprechende Datenbanken noch im Einsatz sind, da Microsoft den
Support dieser Datenbanken abgekündigt habe. Seitens CGM seien zudem routinemäßig Systemkompatibilitätschecks in die Updateroutinen der Software-Applikation integriert worden.

Im Rahmen dieser Checks prüfe das System automatisiert auch, ob die angebundene Datenbank den systemseitig vorausgesetzten Standards entspreche. Sofern das System eine veraltete Datenbank feststelle, erhalte die verantwortliche Praxis im Rahmen der Bestätigung des durchgeführten Updatevorgangs auch einen Hinweis auf die abgelaufene Version der
Datenbank mit dem Hinweis, diese zu aktualisieren. Diese Meldung erscheine auf dem Bildschirm des jeweiligen Anwenders der Software-Applikationen. Mit der Aktualisierung der Datenbank auf die aktuelle Version könne die Transportverschlüsselung durch einen Servicetechniker aktiviert werden.

Die Quelle, der ich die Information zukommen ließ, merkte dazu an, dass er die Transportverschlüsselung nicht in Abrede stellen will. Bei Praxen, die der Quelle bekannt sind, wurde "Standard" installiert. Da sei die Transportverschlüsselung auf aktuelleren System per default aktiv, nicht aber die Inhaltsverschlüsselung. Aus der Update-Doku zu Version 2.91 sei zu entnehmen, dass nun neuerdings zwei Checks durchgeführt werden. Auf das Update gehe ich in Teil 3 nochmals ein.

Definitiv sei  aber auch die Warnmeldung, dass diese auf dem jeweiligen System nicht aktiviert ist, neu. Die Warnmeldung erscheine während des Updates. Aussage der Quelle: "Das ist komischerweise, ganz spontan nach der Meldung beim LfD passiert. Vorher passierte viele Jahre nichts. Meine Interpretation: Irgend etwas wurde da, durch die über den LfD eingeleitete Kommunikation, bei CGM wohl angestoßen.

Aussagen zur Inhaltsverschlüsselung

In der Antwort des LfD hieß es, dass alle Versionen der  Software  (Z1,  Z1.PRO) mit einer dem Stand der Technik entsprechenden Verschlüsselung  "at  Rest" der angebundenen Datenbank kompatibel seien. Die tatsächliche Verschlüsselung der Datenbank liege jedoch grundsätzlich in der Verantwortung des Betreibers des Produkts, also der  Arztpraxis. Entscheide diese sich, sowohl Software-Applikation, als auch  Datenbank über CGM zu beziehen, erhalte sie eine Installation mit verschlüsselter Datenbank.

Auch die Installationsanleitung sehe die Aktivierung einer "at Rest" Datenbankverschlüsselung durch die Praxis  bzw. den beauftragten Servicetechniker vor. Allerdings sei auch hier nicht auszuschließen, dass  noch unverschlüsselte Datenbanken im Einsatz seien. Gründe hierfür  könnten eine veraltete IT-Infrastruktur, Performanceprobleme oder schlicht Unterlassung sein, auf die CGM keinen Einfluss habe. Auch hier werde im Falle einer Feststellung seitens CGM, dass unverschlüsselte Datenbanken im Einsatz sind – etwa im Rahmen von  Service-Überprüfungen oder Updateroutinen – dem Betreiber die Konfiguration
einer Datenbankverschlüsselung empfohlen.

Auch hier lautete die Botschaft, die mich über den LfD erreichte, nichts passiert, und im Grunde ist die Praxis bzw. der Betreiber verantwortlich. Die Quelle merkte dazu nur an: "Nonsens. Die Meldung erscheint nur während des Updates, das der Anwender nicht ausführt, sondern aufgrund der für die meisten Praxen zu hohen Komplexität der Systembetreuer." Die Quelle nannte mir auch den konkreten Wortlaut:

Datenbankverschlüsslung

Das Z1-Update hat festgestellt, dass auf Ihrem System keine Datenbankverschlüsselung eingerichtet wurde. Microsoft empfiehlt aus Sicherheitsgründen die Datenbankverschlüsselung zu aktivieren. Dies kann auch noch nachträglich von Ihrem Techniker (Dienstleister vor Ort) vorgenommen werden, wenn Sie über eine entsprechende SQL-Server-Version/-Edition verfügen. Ansonsten muss der SQL Server upgegradet werden. Bitte wenden Sie sich hierzu bitte an Ihren Techniker. Wenn die CGM Dentalsystem GmbH den technischen Service bei Ihnen vornimmt, kann mit Bestätigen von "ja" das Kontaktformular geöffnet werden, um einen Termin für den technischen Support zu buchen".

Die Quelle schrieb, dass man am doppelten "Bitte" und der falschen Wort-Trennung in manchen Fällen merke, dass es mit dem Warndialog offenbar schnell gehen musste. Die Quelle war sich absolut sicher, dieses Fenster vorher noch nie gesehen zu haben. Die Warnung sei erstmalig beim Update auf Version 2.91 angezeigt worden.

Absicherung der Datenbank Backups/Dumps

In der Antwort des LfD, verfasst auf den Aussagen der CGM hieß es zudem: "Als  letzten  Punkt  haben  Sie  noch  angedeutet,  dass  Backups  der  Datenbank  SQL-Dumps enthalten, die nur durch triviale vierstellige PINs gesichert seien. Hierzu liegen der CGM nach eigenen Angaben keine Kenntnisse vor.

Die Software biete eine Funktion zum manuellen Export der Daten aus  der Datenbank. Die Absicherung obliege der Person, die diesen Prozess> anstoße. Im Rahmen eines solchen Exports erscheine ein Hinweis auf die  Erstellung  eines individuellen Kennwortes, welches vom Anwender festgelegt werden könne.

CGM habe die Anfrage des LfD jedoch zum Anlass genommen, diese Vorgehensweise in der aktuellen Version der Software Z1/Z1.PRO gegenüber Anwendern auch technisch zu erzwingen.

Auch hier geht es um Nebensächlichkeiten, wie der Festlegung des Passworts. Die Quelle merkt dazu an dass das Datenbank-Backup ist ein einfacher Dump sei. Jedenfalls sei ein Restore nur möglich, wenn man das Z1-Dienstprogramm zum Rücksichern startet, und dort das Backup einliest. Hierfür sei zwangsläufig eine Art "Servicekennwort" notwendig. Mir ist das Kennwort bekannt, ich lege es aber hier im Beitrag nicht offen.  Ein Arzt sei also ohne dieses (CGM-exklusive) Wissen, so die Quelle, nicht in der Lage, eine Datensicherung zurückzuspielen.

CGM sei übrigens, auch wenn sie das anders darstellten, nicht immer zu den angegebenen Servicezeiten erreichbar. Die Quelle gibt an, mehrere Fälle erlebt zu haben, wo die "Hotline für stehende Systeme" nicht besetzt war.

Die Quelle erwähnte zudem, dass, wie CGM ja selbst sagt, wie auch in der Update-Doku angibt, dass es erst jetzt Pflicht ist, ein Passwort zu vergeben. Inwiefern jetzt noch eine Automatisierung der Datensicherung möglich ist, wollte die Quelle prüfen. Bisher ließ sich über einen CMD-Aufruf des Moduls z1dasi.exe immer manuell eine automatisierte und unverschlüsselte Datensicherung erstellen, wenn man die richtigen Parameter verwendete. Sofern das PW nun auf der CMD-Ebene mitgegeben werden muss, wäre auch etwas unsicher, weil es dann wieder hard codiert ist, merkt die Quelle an.

Vorläufige Einschätzung des LfD

Der LfD kam in seiner Antwort zur vorläufigen Einschätzung, dass die Absicherung der Datenverarbeitung nach dem Stand der Technik letztendlich im Zuständigkeitsbereich des Verantwortlichen, also der Arztpraxis, die die Software betreibt, liegt. Die grundsätzlichen Voraussetzungen für einen Betrieb nach dem Stand der Technik scheinen softwareseitig gegeben und die Anleitung des Herstellers ist dazu grundsätzlich geeignet.

An dieser Stelle äußerte die Quelle, dass sie das starke Gefühl habe, dass CGM unter Zeitdruck nachgebessert habe. Aber unser Ziel war ja, dass etwas passiert. Die Dinge kamen ins Rollen. In Teil 3 geht es um die Nachbesserungen, die CGM im Mai 2025 an ihrer Software vorgenommen hat.

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