zurĂŒck zum Artikel

SicherheitslĂŒcken im Pandemie-Management-System SORMAS

| Andreas Kurtz

GesundheitsÀmter setzen bei der Kontaktverfolgung auf die Open-Source-Software SORMAS. Das System ist weltweit zum Management von Epidemien im Einsatz.

(An english version of this articcle is available: Security Flaws discovered in the Pandemic Management System SORMAS [1])

SORMAS steht fĂŒr "Surveillance, Outbreak Response Management and Analysis System". Das federfĂŒhrend vom Helmholtz-Zentrum fĂŒr Infektionsforschung (HZI) entwickelte System dient der Verwaltung von Kontaktpersonen und zur Nachverfolgung von Infektionsketten. UrsprĂŒnglich zur EindĂ€mmung der westafrikanischen Ebola-Epidemie im Jahr 2014 konzipiert, wird SORMAS mittlerweile auch von deutschen Behörden bei der Corona-Pandemie eingesetzt.

Mehr von c't Magazin Mehr von c't Magazin [2]

Das Managementsystem ist seit 2016 ein Open-Source-Projekt, der Quellcode auf GitHub verfĂŒgbar [3]. So kann das System weltweit sehr einfach und unbĂŒrokratisch eingesetzt werden. Bei einem Scan fand c’t Dutzende aktive SORMAS-Installationen rund um den Globus verteilt. Sie sammeln fĂŒr gewöhnlich Namen, Adressen und Telefonnummern, Testergebnisse sowie QuarantĂ€ne-Anordnungen von Infizierten und ihren potenziellen Kontakten. Wenn diese brisanten Informationen in falsche HĂ€nde geraten oder gar manipuliert oder gelöscht wĂŒrden, hĂ€tte das nicht nur fĂŒr die Betroffenen, sondern fĂŒr die gesamte PandemiebekĂ€mpfung fatale Folgen.

Bis Mitte MĂ€rz wurden bei jeder Installation von SORMAS zu Demo- und Testzwecken ungesicherte Standard-Accounts angelegt und standardmĂ€ĂŸig aktiviert, bis hin zum Administrator. Die simplen zugehörigen Passwörter standen festverdrahtet im Quellcode [4]. Wer ihn studierte, konnte sich mit diesen ZugĂ€ngen von außen ĂŒber das Internet in die Systeme einklinken und nach Belieben Personendaten auslesen, verĂ€ndern oder löschen.

Solche Standard-Accounts mit statischen Passwörtern sind ein Verstoß gegen das „Security by Default“-Paradigma. Es bedeutet, dass eine Software schon im Auslieferungszustand die sicherst mögliche Konfiguration aufweisen sollte. In der Praxis fĂŒhren solche Default-Logins immer wieder zu ernsten Problemen.

SORMAS-Nutzerkonten

(Bild: SORMAS ÖGD)

Im Kern besteht SORMAS aus einem mit der Jakarta Enterprise Edition aufgesetzten Backend-Server mit einem Web-Frontend als Hauptzugangsweg. ErgĂ€nzend gibt es eine Android-App, die ĂŒber ein REST API mit dem Backend interagiert. FĂŒr den einfachen Betrieb stehen vorgefertigte Docker-Images zur VerfĂŒgung.

Um die komplexen AblĂ€ufe des Epidemie-Managements und aller daran beteiligten Personengruppen ĂŒber ein System zusammenzufĂŒhren, verfĂŒgt SORMAS ĂŒber ein umfassendes Rollenkonzept mit Dutzenden Rollen und jeweils unterschiedlichen Berechtigungsstufen.

Personen der Rollengruppe "Hospital Informant" sind dafĂŒr verantwortlich, VerdachtsfĂ€lle in der Bevölkerung zu erkennen und an das System zu melden, beispielsweise aus einer Klinik. "Laboratory oder Surveillance Officer/Supervisor" analysieren und validieren die so eingespeisten Informationen anschließend. "Case/Contact Officer bzw. Supervisor" kontrollieren bestĂ€tigte FĂ€lle sowie EindĂ€mmungsmaßnahmen und verfolgen sie nach. FĂŒr Administratoren steht schließlich eine Rolle mit umfassenden Berechtigungen zur VerfĂŒgung, um das Gesamtsystem und seine Benutzer zu verwalten.

Problematisch ist, dass SORMAS bis zur Version 1.57 fĂŒr jede dieser Rollen automatisch ein Benutzerkonto angelegt hat. Die Passwörter entsprachen dabei jeweils den Benutzernamen.

Über eine Auswertung der von SORMAS genutzten digitalen Zertifikate (Certificate Transparency Logs) und einschlĂ€gige Suchmaschinen entdeckte c’t Anfang Februar eine Vielzahl potenziell anfĂ€lliger SORMAS-Installationen im Internet – von Indien bis Afrika und von Australien bis Europa. Da unsichere Standardeinstellungen erfahrungsgemĂ€ĂŸ hĂ€ufig nicht angepasst werden, ist die Gefahr groß, dass sich darunter auch zahlreiche Installationen mit Default- Logins und Standardpasswörtern befinden.

Auf Nachfrage von c’t erklĂ€rte das HZI [5] Ende Februar, dass es die Probleme nicht als SicherheitslĂŒcke einstufe. So erklĂ€rten die Update-Hinweise, dass die automatisch angelegten Konten lediglich Demo- oder Testzwecken dienen. Administratoren wĂŒrden dazu angehalten, die Konten auf Produktivsystemen selbststĂ€ndig zu entfernen oder die Passwörter zu Ă€ndern.

Wenn die Admins das jedoch vergaßen oder die Aufforderung nicht lasen, blieben die Konten weiterhin aktiv. Das System selbst warnte Betreiber nicht vor aktiven Standard- oder Administrator-Konten mit unverĂ€nderten Passwörtern.

Laut HZI seien deutsche GesundheitsĂ€mter in der Regel nicht betroffen. Insgesamt 336 Ämter wĂŒrden ihre SORMAS-Instanzen ĂŒber das gemeinsam mit dem RKI konzipierte Projekt SORMAS@DEMIS [6] beantragen, die dann von einem IT-Dienstleister installiert und zentral betrieben wĂŒrden. Diese Instanzen wĂŒrden grundsĂ€tzlich ohne Standard-Accounts aufgesetzt und fĂŒr jede wĂŒrde ein neues, individuelles Administrator-Passwort vergeben. Die Konfiguration und weitere Nutzung obliege dann dem jeweiligen Gesundheitsamt. Unklar blieb jedoch, wieviele der 39 weiteren an das RKI angeschlossenen GesundheitsĂ€mter diesen Service nicht nutzen und SORMAS auf eigene Faust betreiben.

Die HZI-Entwickler reagierten auf die Hinweise von c’t und Ă€nderten die SORMAS-Konfiguration so ab, dass bei zukĂŒnftigen Neuinstallationen keine Default-Logins mehr angelegt werden. Die Änderungen wurden mit Release 1.58 im MĂ€rz veröffentlicht.

Durch diesen offiziellen Fix Ă€nderte sich aber nichts an bestehenden Installationen: Wurde SORMAS bereits mit Default Logins installiert, waren diese auch nach dem manuell einzuspielenden Update weiterhin gĂŒltig. Zudem warnte SORMAS auch nicht vor dem Admin-Konto, das weiterhin bei jeder Neuinstallation immer mit dem gleichen, fest im Code der Anwendung hinterlegten Standardpasswort angelegt wird.

Im Changelog von SORMAS auf GitHub fĂŒhrt das HZI den erzwungenen Passwortwechsel als neues „Feature“ auf. Dass es sich dabei um ein wichtiges Sicherheitsupdate handelt, erfahren die Nutzer nicht.

Diese verbliebenen Probleme wurden erst in der SORMAS-Version 1.59 angegangen, die bis zum 14. Mai bei den vom HZI betreuten GesundheitsĂ€mtern aufgespielt werden sollte. c’t hatte eine Forschungsgruppe der Hochschule Heilbronn kontaktiert, die sich mit Cybersicherheit an der Schnittstelle zu medizinischen Anwendungen beschĂ€ftigt. Die Forscher um Prof. Dr.-Ing. Andreas Mayer erkannten das Problem und steuerten dem HZI kurzfristig Code bei.

Durch die ErgĂ€nzungen der Hochschule Heilbronn werden SORMAS-Nutzer und Betreiber bei vorhandenen Default-Logins oder Standardpasswörtern nun gewarnt und es werden Passwortwechsel fĂŒr die betroffenen Konten erzwungen – inklusive fĂŒr das des Administrators.

Verfolgt man die emsige Betriebsamkeit des SORMAS-Teams auf GitHub, erkennt man schnell, wie mit Hochdruck an neuen Funktionen, Verbesserungen und Bugfixes gearbeitet wird. Im Hinblick auf die Standard-Accounts wĂ€re trotzdem energischeres Handeln wĂŒnschenswert gewesen – ebenso wie ein transparenterer Umgang mit Sicherheitsproblemen und deren Behebung durch sicherheitsrelevante Updates.

Um dem hohen Schutzbedarf der in SORMAS verarbeiteten Gesundheits- und Personendaten gerecht zu werden, drÀngen sich noch eine ganze Reihe weiterer Verbesserungen auf. Das zeigt ein Blick in den OWASP Application Security Verification Standard [7], einem umfassenden Kriterienkatalog zur Absicherung von Webanwendungen. Er beschreibt beispielsweise in Abschnitt 2 detaillierte Anforderungen an eine sichere Authentifizierung, etwa eine Zwei-Faktor-Authentifizierung.

Wie die Kooperation der Heilbronner Forschungsgruppe mit dem HZI zeigt, ist das SORMAS-Team gegenĂŒber externen BeitrĂ€gen aufgeschlossen und nimmt sie dankbar an. Wer ihm auf GitHub unter die Arme greifen und so zur erfolgreichen PandemiebekĂ€mpfung beitragen möchte, rennt offene TĂŒren ein.

Betreiber von SORMAS sollten in jedem Fall darauf achten, dass sie alle Standardpasswörter geĂ€ndert haben und stets die neuste Version – aktuell 1.59 auf GitHub [8] – einsetzen, um mögliche Sicherheitslöcher zu schließen, bevor Angreifer sie ausnutzen.

c’t Ausgabe 12/2021

In c’t 12/2021 widmen wir uns dem brandneuen Desinfec't 2021 [9] mit vier Virenscannern inklusive einem Jahr kostenloser Signatureupdates. Wir erkunden spannende Smartphone-Apps fĂŒr StreifzĂŒge durch die Natur und haben Boards fĂŒr Core i-1000, externe SSDs fĂŒr den Datentransport, Videoleuchten fĂŒrs Homeoffice und smarte Displays fĂŒr Alexa & Co. getestet. Ausgabe 12/2021 finden Sie ab dem 21. Mai im Heise-Shop [10] und am gut sortierten Zeitschriftenkiosk.

(hag [11])


URL dieses Artikels:
https://www.heise.de/-6046608

Links in diesem Artikel:
[1] https://www.heise.de/news/Security-Flaws-discovered-in-the-Pandemic-Management-System-SORMAS-6050707.html
[2] https://www.heise.de/ct
[3] https://github.com/hzi-braunschweig/SORMAS-Project
[4] https://cwe.mitre.org/data/definitions/798.html
[5] https://www.helmholtz-hzi.de/de/
[6] https://sormas-demis.de/
[7] https://owasp.org/www-project-application-security-verification-standard/
[8] https://github.com/hzi-braunschweig
[9] https://shop.heise.de/ct-12-2021-auf-desinfect-stick?wt_mc=intern.shop.shop.ct_2112.stick-red.textlink.textlink
[10] https://shop.heise.de/ct-12-2021/PDF
[11] mailto:hag@ct.de