IT-Sicherheit beim elektronischen Gesundheitsdossier im Fürstentum Liechtenstein

Kritik am Datenschutz

Personen, welche für den Datenschutz zuständig sind (Datenschutzbeauftragte), folgen oftmals der Logik, dass der Datenstandort für den Datenschutz tatsächlich wichtig ist. Und wie oben beschrieben gilt in diesem Fall der Datenstandort Schweiz. Es ist auch wahrscheinlich, dass sich viele Juristen dieser Sicht anschliessen und dies rechtlich korrekt ist (wir sind keine Juristen). Allerdings sollte jedem klar sein, dass viel wichtiger ist wer im Endeffekt denn auf die Daten zugreifen kann.

Interessant ist hierbei, dass in den Datenschutzhinweisen bereits explizit eine Ausnahme zugelassen ist, nämlich dass Siemens für Supportzwecke aus Fürth (Deutschland) zugreifen darf.

In der Praxis ist der Datenstandort aber weniger relevant, denn für amerikanische Firmen gilt ohnehin der Cloud Act und wird mit einem Satz treffend auf Wikipedia erklärt: "Das Gesetz verpflichtet amerikanische Internet-Firmen und IT-Dienstleister, US-Behörden auch dann Zugriff auf gespeicherte Daten zu gewährleisten, wenn die Speicherung nicht in den USA erfolgt". Inwiefern die Verwendung der amerikanischen Unternehmen Cloudflare als Dienstleister oder Liferay als Software-Lieferant diesbezüglich eine Rolle spielt, sei dahingestellt...

Als IT-Sicherheitsexperten, die tagtäglich den Abfluss von Daten sehen, fühlen wir uns der Datensparsamkeit verpflichtet. Täglich scheitern Unternehmen daran, wichtige Daten geheim zu halten. Beispiele gibt es genug, das kürzliche Datenleck bei xplain.ch mit Daten von verschiedenen Kantonspolizeien und der Bundespolizei (bei dem auch Daten zur Liechtensteiner Polizei enthalten waren) ist nur eines davon.

Eine zentrale Speicherung von Gesundheitsdaten standardmässig für jeden Bürger einzuführen, scheint deshalb fragwürdig. Das Dossier wird auch für Bürger eingeführt, welche über keine eID verfügen und somit das Dossier nicht komplett nutzen können. Trotzdem werden Daten zentral gesammelt. Auch Hinweise in den Fragen und Antworten zum Gesundheitsdossier, dass der Nutzen von eHealth die "Gewährleistung Anbindung mit Nachbarländern und darüber hinaus" sein soll, klingen eher nach Überwachungsstaat als Dienst für den Bürger.

Kritik an der Authentifizierung via Passkopie

Alle Bürger, welche über keine eID verfügen, können per E-Mail oder Online-Formular Antrag auf Zugang stellen, wenn eine Passkopie mitgesendet wird. Allerdings werden Passkopien auch von Autovermietungen oder Hotels angefertigt, womit die Sicherheit dieser Vorgänge nicht sichergestellt ist. Unter anderem kann auch eine Stellvertretung für das elektronische Gesundheitsdossier auf diesem Weg beantragt werden.

Die Einführung einer solchen unsicheren Methode widerspricht der auf der Webseite im Bereich Fragen und Antworten dokumentierten Aussage, dass "heutige Kommunikation mittels E-Mail, Chats, Fax und Brief [...] weder einen hohen Datenschutz noch eine hohe Datensicherheit" bietet.

Anmerkung zum DDoS-Schutz durch Cloudflare

Cloudflare bietet grundsätzlich einen Schutz vor Denial-of-Service-Angriffen, bei denen mittels vieler gleichzeitiger Anfragen Ressourcen einer Webanwendung so verbraucht werden, dass keine weiteren Anfragen mehr möglich sind. Allerdings ist dabei wichtig, dass für einen Angreifer lediglich die IP-Adressen von Cloudflare bekannt sind, nicht die der Server der MTF in diesem Fall. Es stellt sich also grundsätzlich die Frage, ob der Schutz überhaupt effektiv ist, wenn die IP-Adressen bei der MTF für die APIs bekannt sind. Mit dem momentanen Kenntnisstand kann dies nicht abschliessend beurteilt werden.

Kritik an der Erreichbarkeit von Systemen aus dem Internet

Es ist nicht gängige Praxis, dass ein System wie Nagios im Internet erreichbar ist, welches lediglich der Überwachung von IT-Systemen dient. Der Zugriff verlangt nach einem Benutzernamen und einem Passwort. Grundsätzlich scheint aber ein Login aus dem Internet möglich, wenn jemand ein gültiges Passwort besitzt. Warum dieses System aus dem Internet erreichbar ist oder ob dies so gewollt ist, ist unklar. Ein solches Überwachungssystem muss lediglich den IT-Adminstratoren zur Verfügung stehen, welche die Systeme betreuen. Da dieses System jedoch im Internet grundsätzlich ansprechbar ist, bietet der Betrieb dieser Software unnötig Angriffsfläche. Kennt ein Angreifer eine Schwachstelle der Nagios Software, kann er diese über das Internet ausnutzen. Solche Schwachstellen gibt es immer wieder für Nagios und lassen sich online nachlesen.

Auch die Test- und Abnahme-Umgebungen sind grundsätzlich nicht für den produktiven Betrieb notwendig und bieten somit nur unnötig Angriffsfläche.

Anmerkung zu zusätzlichem Webserver-Schutz

Die Gesundheitsdossier-Webseite verwendet keinen HTTP-Header Content-Security-Policy (CSP), welcher bei strikter Umsetzung die Problematik von Cross-Site-Scripting-Schwachstellen entschärfen könnte.

Auffällige Code-Muster in Liferay

Um eine Einschätzung der Software machen zu können, haben wir zuerst den Quellcode in der Version 7.4.3.84 heruntergeladen. Sucht man im Quellcode von Liferay nach bestimmten Mustern, die üblicherweise IT-Schwachstellen zeigen, wird man sofort fündig.

Es scheint als wären viele Code-Pfade verwundbar auf sogenannte Cross-Site-Scripting-Schwachstellen (XSS). Dabei sind dies sehr auffällige Muster, welche darauf hindeuten, dass Liferay keine Release-Qualitätssicherung macht, welche solche Muster findet, bevor die Software veröffentlicht wird.

Auch dass in den letzten 1.5 Jahren 20 Cross-Site-Scripting-Schwachstellen gefunden wurden, zeigt: Liferay hat keinen strategischen Ansatz um Schwachstellen zu verhindern und wiederholende Schwachstellen der gleichen Kategorie sind häufig.

Sucht man weiter nach Mustern, findet man beispielsweise in der Datei PermissionUpgradeProcess.java:

private void _upgradeResourcePermission(String name) throws Exception {
        try (PreparedStatement preparedStatement1 = connection.prepareStatement(
                        StringBundler.concat(
                                "select resourceActionId, bitwiseValue from ",
                                "ResourceAction where actionId = 'ADD_ENTRY' and name = '",
                                name, "'"));
                ResultSet resultSet1 = preparedStatement1.executeQuery())

Wer sich mit sicherer Programmierung auskennt erkennt: String-Formatierung (via StringBundler.concat) zum Erzeugen eines SQL-Statements zu nutzen, ist ein Anti-Pattern und kann zu SQL-Injektionen führen. Würde dieses Muster nur an einer Stelle verwendet, hätten wir uns angeschaut, ob es ein Sicherheitsrisiko darstellt. Allerdings hat der Quell-Code von Liferay sehr viele solcher Muster und wir haben deshalb nicht jedes Vorkommen eines solchen Musters überprüft.

Folgend nun neue Schwachstellen, welche wir während unserer Untersuchung gefunden und an Liferay Inc. gemeldet haben. Wir haben uns die Liferay-Software selbst auf unserem System installiert und eine Sicherheitsanalyse (in einem begrenzten Rahmen) durchgeführt.

Schwachstelle 1 bis 4: Cross-Site Scripting Schwachstellen

Wir haben insgesamt vier Cross-Site Scripting Schwachstellen identifiziert, welche wir an Liferay gemeldet haben und alle von Liferay bestätigt wurden. Für die Schwachstellen wurden die Identifikationsnummern CVE-2023-42627, CVE-2023-42628 und CVE-2023-42629 vergeben.

Bei manchen dieser Schwachstellen handelte es sich um Stored Cross-Site Scripting. Beispielsweise konnte eine Schwachstelle durch einen bestellenden Benutzer im Liferay-Shop ausgenutzt werden. Dabei wird der eingeschleuste Code anschliessend im Browser des Online-Shop-Betreibers/Administrators ausgeführt. Das bedeutet, ein Angreifer könnte beliebige Aktionen als Shop-Betreiber ausführen und womöglich den kompletten Online-Shop übernehmen. Die technischen Details zu den Verwundbarkeiten, werden wir später in einem separaten Advisory veröffentlichen. (Update 2023-10-17: Die Details zur den Cross-Site-Scripting-Schwachstellen in der Liferay-Portal-Software sind nun öffentlich.)

Inwiefern diese Schwachstellen ebenfalls auf dem Gesundheitsdossier ausgenutzt werden könnten, ist unklar.

Schwachstelle 5: Datenbankpasswort für wedeploy.com veröffentlicht

Das Unternehmen Liferay plante oder unterhielt zu einem Zeitpunkt einen Service mit dem Namen wedeploy.com. Zwar ist die Webseite mittlerweile nicht mehr erreichbar, trotzdem finden sich neben dem Code selbst auch noch Konfigurationen im Quellcode der Liferay-Software.

Anscheinend hat Liferay dabei das produktive Datenbankpasswort für den wedeploy.com-Service aus Versehen veröffentlich.

Wir haben diese Schwachstelle an Liferay gemeldet und diese wurde von Liferay bestätigt und das Passwort wurde geändert. Technische Anmerkung: Da Liferay nicht die alten Einträge der Versionskontrolle ändern möchte, da sonst Kompatibilitätsprobleme mit Forks auf Github entstehen können, ist das alte Passwort weiterhin in der Versionshistorie ersichtlich.

Gleichzeitig fiel auf, dass Liferay dieses Passwort nicht nur in der Produktion verwendet, sondern ebenfalls in der Umgebung für DEV (für development, also wiederum eine Testumgebung) und UAT (wiederum eine Abnahmeumgebung). Dieses Vorgehen ist nicht zu empfehlen. Passwörter sind unbedingt unterschiedlich auf Produktion und Testsystemen zu setzen. Ansonsten kann es passieren, dass ein Angreifer eine der anderen Umgebungen angreift und anschliessend über gültige Passwörter für die Produktion verfügt. Testumgebungen sind häufiger weniger gesichert, zeigen vielleicht Debug-Ausgaben oder sind tendenziell nicht im (Sicherheits-)Monitoring. Wenn ein Angreifer Dienste versehentlich unbenutzbar macht, dann fällt dies vielleicht gar nicht auf. Testumgebungen im Internet sind Industrie-Standard, aus Sicherheitsicht zwar nicht zu empfehlen, aber praktisch – auch für Angreifer.

Auf das Gesundheitsdossier hat das grundsätzlich keinen Einfluss, zeigt aber Probleme beim Lieferanten Liferay.

Schwachstelle 6: Verwundbare JavaScript-Bibliotheken

Es wird ausserdem eine JavaScript-Bibliothek mit bekannten Verwundbarkeiten verwendet, die Bibliothek ckeditor wird in Version 4.18.0 verwendet und ist von der Schwachstelle "CVE-2023-28439: Cross-Site Scripting" betroffen.

Schwachstellen in JavaScript-Bibliotheken sind ein gängiges Problem, insbesondere Cross-Site-Scripting-Schwachstellen sind zu erwarten. Dabei gilt: Nach der Schwachstelle ist vor der Schwachstelle. Das Vorhandensein von Verwundbarkeiten in Bibliotheken bedeutet nicht, dass die Lücken ausnutzbar sind, oder gar einfach ausnutzbar sind. Man ist dennoch gut beraten, Bibliotheken zu aktualisieren.

Diese Bibliothek ist insbesondere auch auf dem Gesundheitsdossier erreichbar. Inwiefern dieses Problem dort ausnutzbar ist, wurde nicht untersucht.

Schwachstelle 7: Denial of Service mittels einer verschachtelten Abfrage in GraphQL

Die GraphQL-Schnittstelle von Liferay is verwundbar auf eine Denial-of-Service-Schwachstelle, die von einem Angreifer ausgenutzt werden kann, wenn dieser eine verschachtelte Abfrage sendet. Die Schwachstelle erlaubt es, mit einer einzigen Anfrage den kompletten Speicher des Servers aufzubrauchen (java.lang.OutOfMemoryError). Anschliessend kann der Liferay-Server keine anderen Anfragen mehr entgegennehmen und erscheint für andere Nutzer unerreichbar.

Liferay hat geantwortet, dass sie über die Schwachstelle bereits Bescheid wissen und diese zu einem späteren Zeitpunkt erst beheben werden.

Es wird davon ausgegangen, dass auch die GraphQL Schnittstelle des Gesundheitsdossiers betroffen ist. Inwiefern dieses Problem dort tatsächlich ausnutzbar ist, wurde nicht untersucht.

Fazit

Wir haben keine Sicherheitsuntersuchung der Gesundheitsdossier-Webseite durchgeführt und melden an dieser Stelle auch nicht direkt Schwachstellen an die Landesverwaltung, da wir lediglich die zugrunde liegende Liferay-Software betrachtet haben. Schwachstellen von verwendeter Software abzuklären ist Aufgabe der Landesverwaltung. Inwiefern eine Sicherheitsprüfung durchgeführt wurde, ist uns nicht bekannt. Es ist uns aber wichtig, für Liechtensteiner Bürger mehr Transparenz zu schaffen.

Insgesamt ensteht bei der Betrachtung des Gesundheitsdossier im Fürstentum Liechtenstein folgender Eindruck:

• Die Datenschutzhinweise erwähnen nicht alle Drittparteien (z. B. Cloudflare), die rein technisch involviert sind. Mindestens die Dienstleister, die Inhalte sehen können, sollten transparent genannt werden.

• Es scheint als wurde nicht darauf geachtet, Risiken für das Gesundheitsdossier zu minimieren. Beispielsweise die Erreichbarkeit aus dem Internet einzuschränken, Sicherheitskonfigurationen hinzuzufügen oder Komponenten (beispielsweise von Liferay) zu sperren, zu entfernen oder zu deaktivieren.

• Das Liferay-Portal hinterlässt nicht den Eindruck, dass bei dessen Entwicklung wirksame Qualitätsprüfungen vor Veröffentlichung stattfinden, die auch Sicherheitseigenschaften prüfen. Als Quasi-Lieferant der Software ist Liferay ausserdem zu betrachten bei Themen wie Supply-Chain-Angriffen. Zusammen mit der hohen Komplexität und der verwendeten und erreichbaren Komponenten, scheint Liferay eine fragliche Wahl für die Umsetzung einer so kritischen Applikation wie dem Gesundheitsdossier zu sein.

Aktualisierung 2023-09-18: Artikel "Hacker orten Schwachstellen bei Software-Anbieter" der Tageszeitung Vaterland verlinkt.

Aktualisierung 2023-10-17: Advisory zu den Cross-Site-Scripting-Schwachstellen in der Liferay-Portal-Software verlinkt.