c’t deckt auf: Kritisches Sicherheitsleck bei Rettungsdienst-System IVENA
Seite 2: Admin-Zugang mit allen Rechten
Der gefundene Account durfte so ziemlich alles auf der Plattform – er war Administrator mit vollen Rechten zur Benutzer- und Krankenhausverwaltung. Er durfte also nicht nur Patienten anmelden, wie es ein Mitarbeiter der Rettungsleitstelle darf, sondern auch ganze Krankenhäuser abmelden, anlegen und Kennwörter anderer Nutzer ändern.
Der Schaden, den ein übelgesinnter Finder der Zugangsdaten hätte anrichten können, wäre gewaltig. Plötzlich wären viele Rettungsleitstellen in Niedersachsen von einem wichtigen Werkzeug abgeschnitten gewesen, die Bildschirme in unzähligen Notaufnahmen hätten nur noch Fehler oder manipulierte Daten angezeigt. Ein solcher Ausfall oder eine Sabotage hätten schlimmstenfalls Menschenleben gefährden können. Wie uns die Entwickler später bestätigten, hatte der gefundene Account auch in allen anderen IVENA-Instanzen in Deutschland volle Zugriffsrechte.
Personenbezogene Daten wie Alter, Diagnose und Geschlecht, die sich in den Datensätzen fanden, konnten keinem konkreten Patienten zugeordnet werden – Namen, Adresse oder Geburtsdaten werden in IVENA nämlich nicht erfasst. Einsehbar waren dagegen die Kontaktdaten aller Benutzer, also dienstliche Kontaktdaten von Ärzten, Mitarbeitern der Leitstellen und den Notaufnahmen. Diese Daten findet man aber uberwiegend auch auf den Homepages der Krankenhauser.
Flächendeckendes Problem
Diese Erkenntnisse waren mehr als besorgniserregend. Gespräche mit Personal aus einer Notaufnahme bestätigten unsere Einschätzung, dass ein Ausfall oder Manipulationen im Krankenhausalltag verheerend sein könnten. Großen Schaden, so das Ergebnis unseres Gesprächs, hätte der Admin-Account auch mit dem Modul "MANV" anrichten können. Damit kann man einen "Massenanfall an Verletzten" in einer Region anmelden – wie etwa bei einem Zugunglück oder Flugzeugabsturz.
Mit diesen Informationen kontaktierten wir sofort die Entwicklerfirma mainis IT und wiesen darauf hin, dass auch alle Nutzerkennwörter potenziell geändert werden müssten. Schließlich hatte der betroffene Account das Recht, diese zurückzusetzen oder Rechte zu bearbeiten.
Technische Fehler
Das Unternehmen reagierte zügig. Am späten Abend, etwa fünf Stunden nach unserem Hinweis, bekamen wir die Information, dass das Kennwort geändert und der Fehler in Apache beseitigt sei.
In einem längeren Gespräch mit mainis IT gab ein Mitarbeiter am nächsten Tag die Fehler unumwunden zu und sprach gleich in mehreren Punkten von völligem menschlichen Versagen. Falsch sei es gewesen, einen Super-Admin-Account anzulegen, in allen Instanzen dasselbe Kennwort zu verwenden, dieses noch im Klartext irgendwo zu hinterlegen und den Apache-Server dann noch so falsch zu konfigurieren.
Das Kennwort gelangte im April 2020 auf den Webserver, nachdem das Unternehmen – nach eigenen Angaben mit letzter Kraft – ein Modul für die Covid-19-Bettenauslastung fertiggestellt und auf Wunsch der niedersächsischen Landesregierung noch eine öffentliche Auslastungskarte implementiert hatte. Die Konfigurationsdatei mit dem Kennwort gehörte zu ebendieser Kartenschnittstelle.
Dieser Zeitdruck und die besonderen Umstände sollen, so der Verantwortliche, das Versagen keinesfalls entschuldigen und höchstens etwas erklären. Die zahlreichen individuellen Fehler, etwa ein Kennwort für alle Instanzen und das Directory Listing, seien unter keinen Umständen zu entschuldigen. So viel Offenheit und Ehrlichkeit nach Hinweisen auf Sicherheitslücken ist nicht alltäglich.
Vorbildliche Korrekturen
Auch die weiteren Maßnahmen waren vorbildlich: Mainis IT veröffentlichte eine ausführliche Stellungnahme auf der Homepage und per Rundschreiben an alle Nutzer-Accounts mit dem Hinweis auf einen möglichen Vorfall nach Artikel 33 der DSGVO. Demnach wurde am 16. Oktober auch der hessische Landesdatenschutzbeauftragte informiert. Uns gegenüber berichtete man außerdem, eine ausführliche Analyse aller Logfiles in allen Instanzen durchgeführt zu haben.
Jeder Schreibvorgang wurde protokolliert, sodass sich alle Aktionen des Admin-Accounts seit April zurückverfolgen ließen. Der Account habe nirgendwo Schaden angerichtet und keine Kennwörter anderer Nutzer geändert. Überdacht werde auch die Anmeldung – alle Benutzer-Accounts, die andere Benutzer verwalten können, sollen in Zukunft verpflichtend mit einem zweiten Faktor (TOTP oder FIDO2) gesichert werden. Arbeiten daran hätten bereits begonnen.
Organisatorisches Versagen
Die akute Gefahr war damit gebannt und wir sahen uns das IT-Projekt aus organisatorischer und rechtlicher Sicht an. Dabei fanden wir allerlei Merkwürdiges.
Die Instanz ivena-berlin.de zum Beispiel wird von ekom21 betrieben, einer öffentlich-rechtlichen Körperschaft aus Hessen. Diese Plattform nutzen, darauf deuten zumindest die Logos im Kopfbereich der Seite hin, neben Berlin auch Sachsen-Anhalt und Brandenburg mit. Das Impressum stammt aus einem Online-Impressum-Generator, die Seite mit der Datenschutzerklärung war bis Redaktionsschluss einfach leer.
Als Betreiber wird im Impressum ekom21 genannt – die uns auf Anfrage aber schriftlich mitteilten, inhaltlich nicht verantwortlich zu sein und nur das Hosting zu übernehmen. Wer dann verantwortlich ist? "Nach unserem Kenntnisstand wurde die Anwendung in Berlin zentral über die Senatsverwaltung eingeführt", so ekom21.
Auch die Berliner Charité als angeschlossenes Krankenhaus ist sich keiner Verantwortung bewusst. Auf Anfrage heißt es: "Es handelt sich bei IVENA um ein Projekt der Senatsverwaltung für Gesundheit, Pflege und Gleichstellung, weshalb wir Sie bitten möchten, sich bezüglich Ihrer Fragen dorthin zu wenden." Hier hat sich ganz offenkundig niemand mit den organisatorischen Fragen des Projekts beschäftigt und vorab sicher keine Rechtsabteilung konsultiert.
Digitalisierung bottom up
Wie uns mainis IT beschrieb, ging die Initiative in einigen Bundesländern oft von einzelnen Krankenhäusern aus, die im Einzugsbereich einer Rettungsleitstelle eine gemeinsame Plattform betreiben wollten und IVENA oft auch bezahlen. In Niedersachsen hat zum Beispiel das Gesundheitsministerium die Plattform als Pilotprojekt für einzelne Kreise aufgesetzt, wie aus einem Bericht auf dessen Homepage hervorgeht; an diese Instanz haben sich dann immer mehr Krankenhäuser angehängt.
Die Digitalisierung verlief hier also, untypisch für staatliche Projekte, von unten nach oben und ohne Vergabe-, Prüf- und Genehmigungsverfahren recht hemdsärmelig. Das Klinikum Region Hannover schrieb uns auf unsere Fragen nach der Zuständigkeit: "Das KRH hat mit hannIT einen Auftragsdatenverarbeitungsvertrag geschlossen, in dem die Verantwortlichkeit für die Datenübertragung und -verarbeitung im Rahmen von IVENA beim KRH verbleibt." Einen solchen Vertrag sollte jeder mit seinem Hoster abschließen.
Die Frage der Zuständigkeit beantwortet das aber nicht. Die hannIT findet sich im Impressum als Betreiber und in der Datenschutzerklärung als Verantwortlicher, bezeichnet sich auf unsere Anfrage aber lediglich als Hoster. Als Verantwortliche sieht man "die in Niedersachsen an das IVENA-System angeschlossenen Krankenhäuser und Leitstellen".
Kern des organisatorischen Problems ist eine komplizierte Drei- oder Vierecksbeziehung zwischen Krankenhäusern, Kommunen mit den Rettungsleitstellen, Rechenzentrum und teilweise dem Bundesland. Irgendwo in diesem Konstrukt fehlt es an klaren Verantwortlichkeiten, die für ein solches Projekt nötig gewesen wären. Auch Sicherheits-Audits oder Maßnahmen wie eine Zweifaktor-Anmeldung wurde von den Kunden nicht systematisch eingefordert. Anders als das technische Problem eines veröffentlichten Kennworts, das vom Entwickler zügig behoben wurde, dürfte das Entknoten dieses rechtlichen Konstruktes die Betreiber und Beteiligten in Krankenhäusern und Landkreisen deutlich länger beschäftigen.
Viele c’t-Investigativ-Recherchen sind nur möglich dank anonymer Informationen von Hinweisgebern.
Wenn Sie Kenntnis von einem Missstand haben, von dem die Öffentlichkeit erfahren sollte, können Sie uns Hinweise und Material zukommen lassen. Nutzen Sie dafür bitte unseren anonymen und sicheren Briefkasten.
Dieser Artikel stammt aus c't 24/2020.
(jam)
