Thought Leadership
Wie verschiedene Medien, darunter heise.de, golem.de
„Safeplay wird in Deutschland und Österreich im Rahmen der Coronavirus-Bekämpfung genutzt. Durch einfache Veränderung der URL konnten registrierte Nutzer auf Corona-Testergebnisse und persönliche Daten anderer Anwender zugreifen. Betroffen waren laut CCC 136.000 Testergebnisse und Daten von mehr als 80.000 Personen.“, so heise.de.
Der Software-Anbieter, die Wiener Firma Medicus, hat die Sicherheitslücke nach eigenen Angaben mittlerweile geschlossen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) sowie das CERT.at wurden informiert.
„Wie der CCC nach einem Besuch eines Berliner Testzentrums entdeckt hat, ließen sich die Daten und Corona-Testergebnisse auch von anderen registrierten Kunden durch eine einfache, manuelle Änderung der Safeplay-Internetadresse abrufen. Die URL für die sogenannten “Testzertifikate” enthält die Nummer des Tests. Wurde diese Zahl hoch- oder runtergezählt, waren die Ergebnisse und Daten anderer Personen frei zugänglich. Im Testzertifikat stehen neben dem Testergebnis auch Name, Geburtsdatum, Anschrift, Staatsbürgerschaft und Ausweisnummer der Betroffenen.
Linus Neumann vom Chaos Computer Club stimmt der Vorfall für die Zukunft wenig optimistisch: “Dies ist nicht die erste und sicherlich nicht die letzte Sicherheitslücke in hastig gebastelter Corona-IT”, erklärte Linus Neumann vom Chaos Computer Club. Er wirft Gesetzgebern, Behörden sowie Unternehmen Fahrlässigkeit vor: “Wenn schon bei so einfachen Aufgaben katastrophale Anfängerfehler passieren, sollten die Verantwortlichen erst mal ihre Hausaufgaben machen.”
Dazu ein Kommentar von Gunnar Braun, Synopsys:
„Der Beitrag in der Süddeutschen Zeitung zeigt gleich drei verheerende Sicherheitslücken auf: nicht nur konnten Nutzer auf die Testdaten anderer zugreifen, sondern es war auch möglich, sich unbefugt in einem Mitarbeiter-Portal anzumelden und sogar falsche Testergebnisse auf dem Server abzulegen. Die erste der genannten Schwachstellen ist auch unter der CWE-425 als Direct Request („Forced Browsing“) bekannt. Dabei handelt es sich um eine Sicherheitslücke, die sich häufig schon während der Software-Entwicklung mittels statischer Codeanalyse (SAST) erkennen lässt. Spätestens aber, wenn man zu dynamischen Security Testing Tools wie DAST und IAST greift.
Interessant ist noch ein anderer Aspekt. Es wird zwar, wie so häufig, der Datentransports mittels HTTPS verschlüsselt. Die abgelegten Daten (die sogenannten „Data at Rest“) sind aber scheinbar weder verschlüsselt noch signiert. Die Art der Sicherheitslücken und das Wie ihres Auftretens, deuten auf einen Mangel an systematischen Prozessen bei der Softwaresicherheit hin. Oft fehlt es zusätzlich an Know-how hinsichtlich der möglichen Angriffs-Vektoren. Und die muss man nicht nur kennen, sondern einordnen und bewerten können. Ohne diese Voraussetzung ist eine effektive Verteidigung schlichtweg unmöglich.
Das wirft die Frage nach entsprechenden Regulierungen und Standards auf. Die DSGVO belegt zwar Nachlässigkeit mit empfindlichen Strafen. Allerdings lässt sich der Vorwurf mangelnder Sorgfalt oft schon dadurch abwenden, dass man ja HTTPS verwendet habe. Für Software im medizinischen Sektor gilt andererseits (und das seit Jahren schon) die IEC 62304.
Die scheint aber hier nicht zur Anwendung zu kommen, da es sich nicht um eine Software handelt, die medizinische Geräte kontrolliert. IEC 62304 einzusetzen, ist eine ernsthafte Überlegung wert. Die Norm ist zwar in punkto Cybersicherheit immer noch vergleichsweise “leichtgewichtig”, aber sie erfordert zumindest Dinge wie ein Risiko-Management und Statische Codeanalyse.“
