Wie wir nur mal kurz einen Corona-Test machen wollten und versehentlich in ein Nest voller Sicherheitslücken gefallen sind.

Seit dem 8. März gibt es in Berlin »kostenlose Bürger*innen-Tests«. Über das Portal test-to-go.berlin kann man ein Testzentrum finden und einen Termin buchen.

Schon kurz nach Veröffentlichung der Testzentren-Übersicht der Berliner Senatsverwaltung für Gesundheit, Pflege und Gleichstellung waren wir irritiert: Alles an diesem Online-Portal machte auf uns den Eindruck, doch etwas hastig zusammengestrickt worden zu sein – und das nach nur einem Jahr Pandemie.

Anscheinend ist Internet für das @SenGPG immer noch Neuland und sie haben noch nie von Domainsquatting gehört, denn jetzttesten​.​berlin sowie tests-to-go​.​berlin (& test2go​ & tests2go & test-togo …) sind noch frei.
Das ist besonders bei mündlicher Weitergabe problematisch. pic.twitter.com/Ai9avSldvo

— zerforschung (@zerforschung) March 7, 2021

Da wir ohnehin einen Test machen wollten, konnten wir dieses neue Angebot gleich mal ausprobieren.

Am Testzentrum angekommen wunderten wir uns, dass wir sehr energisch auf die Online-Registrierung hingewiesen wurden. Wir standen doch schon am Eingang! Aufgrund der Menge persönlicher Daten, die in der WebApp abgefragt wurden, hätten wir eine Online-Erfassung eigentlich gern vermieden.

Nach dem Test freuten wir uns nicht nur über das negative Ergebnis – sondern guckten dabei, wie üblich, auch kurz mit auf den Datenverkehr. Bei einigen URLs hatten wir schon im ersten Moment ein mulmiges Gefühl. Das mulmige Gefühl würde in den nächsten Minuten blankem Entsetzen weichen.

Erster Akt: Graf Zahl und die Test-Ergebnisse

Eine Viertelstunde nach dem Test erhielten wir eine E-Mail mit einem Link zum Testergebnis von 21Dx, der Betreiberin des Testzentrums. Dieser Link führte uns auf die Domain 21dx.medicus.ai.

Wie aber hängen medicus.ai und 21Dx zusammen? Das Wiener Startup medicus.ai bietet mit ihrer Software SafePlay eine Komplettlösung für Testzentren, mittels derer man sich für Tests registrieren und hinterher die Ergebnisse abrufen kann. Unsere Berliner Testzentrum-Betreiberin 21Dx nutzt diese Software as a Service.

Wir wollen jetzt unsere eigenen Testergebnisse einsehen und folgen dem Link auf 21dx.medicus.ai. Nach einem Login erscheint die folgende Seite mit guten Nachrichten für uns:

Viel interessanter aber: Neben der Online-Anzeige lässt sich das Ergebnis auch als PDF herunterladen, falls man es ausdrucken möchte oder etwas benötigt, das besonders offiziellen Eindruck macht:

Wie immer lassen wir bei spannenden Webseiten die Netzwerk-Ansicht der Entwicklertools im Browser offen. Manchmal entdecken wir dort interessante Dinge – so leider auch hier.

Die Anfrage zum Herunterladen des PDFs geht an /api/web/v1/results/export-patient-specific-result-file?report_id=12345

Kurioserweise wird anstatt einer PDF-Datei ein JSON zurückgeliefert, welches den Datei-Inhalt als data-URI verpackt:

{
  "code":200,
  "message":"success",
  "data":{
    "fileName":"Vorname_Nachname_Abrufunixtimestamp.pdf",
    "file":"data:application/pdf;base64,…"
  }
}

Wie oben zu sehen, enthält die PDF-Datei nicht nur den Befund, sondern alle bei der Registrierung hinterlegten Daten:

• Vorname
• Nachname
• Geschlecht
• Adresse
  • Straße
  • Hausnummer
  • Postleitzahl
  • Ort
• Geburtsdatum
• Staatsbürgerschaft
• Mobilfunknummer
• E-Mail-Adresse
• Probentyp
• Datum und Uhrzeit der Probenahme
• Datum und Uhrzeit der Ergebnisbereitstellung
• Befund
• Optional: Reisepass/Ausweis-Nummer
• Optional: Abweichender Aufenthaltsort in den nächsten zwei Wochen
  • Straße
  • Hausnummer
  • Postleitzahl
  • Ort

Der ?report_id=12345-Parameter sah schon ziemlich verdächtig aus. Üblicherweise würde man für so etwas eine UUID verwenden, also einen langen, zufälligen Wert – und nicht einfach nur eine Zahl.

Und leider stellte sich heraus: Ändert man die Zahl im Parameter, hat man Zugriff auf die Testergebnis-PDFs anderer Menschen. Dazu muss man noch nicht mal eine bestimmte Test-ID erraten, da die Tests einfach aufsteigend durchnummeriert sind.

Spätestens jetzt wurden wir nervös. Bei personenbezogenen Daten oder gar medizinischen Daten dürfen Sicherheitslücken nicht vorkommen, erst recht nicht derart triviale. So etwas muss umgehend gemeldet werden, um das Desaster schnell und effektiv zu beseitigen. Deshalb haben wir zusammen mit dem Chaos Computer Club das BSI informiert. epicenter.works übernahm die Kommunikation mit dem CERT.at, da medicus.ai in Österreich sitzt.

Linus Neumann vom CCC sagte dazu:

»Diese Art von Schwachstellen sind ein Klassiker, vor dem immer wieder gewarnt wird. Wer sich auch nur im Entferntesten mit IT-Sicherheit auseinander setzt, macht solche Fehler einfach nicht.«

Zweiter Akt: Brian? Nein, ich bin Brian. Nein, ich!

Bei der Registrierung muss man seinen Namen, Adresse, E-Mail-Adresse und Telefonnummer angeben. Tatsächlich wird im Testzentrum der Ausweis gefordert, der dann mit den registrierten Daten verglichen wird.

Im Testportal lassen sich jederzeit die angegebenen Adressdaten, Reisepass/Ausweis-Nummer und der eventuell abweichende Aufenthaltsort verändern. Das ist auch durchaus praktisch, um bei weiteren Tests in der Zukunft nicht alles von vorn eingeben zu müssen.

Wir waren dann nur sehr erstaunt, als wir nach einer Adressänderung im Testportal unser Befund-PDF erneut heruntergeladen haben und dort die gerade aktualisierten Daten auftauchten.

Wenn sich schon die Adressen ändern lassen, vermuteten wir, dass der Name vielleicht doch auch betroffen sein könnte – obwohl dieser eigentlich in der Oberfläche als nicht bearbeitbar dargestellt wird.

Deaktiviert man diese Prüfung im Browser oder sendet man eine passende Anfrage direkt an die API, werden die Änderungen tatsächlich nicht nochmal vom Testportal überprüft. Wir können also den Namen ändern oder Pflichtfelder einfach leer lassen.

Auch nach dieser Namens- und Adressänderung lassen sich neue Befund-PDFs herunterladen. Damit ließen sich mit einem negativen Test problemlos weitere negative Test-Befunde mit beliebigen Namen und beliebigen Adressen für andere Leute erstellen.

So wäre es auch möglich, ein negatives Testzertifikat für Donald Duck zu bekommen, der ja bekanntermaßen in sehr vielen Restaurants unterwegs ist.

Dritter Akt: Und wie sieht es in Ihrem Unternehmen aus?

Nachdem die Lücke aus dem ersten Akt gemeldet war, hat medicus.ai sie geschlossen. Wir hatten erstmal genug davon, versehentlich Corona-Portale zu zerforschen und wollten eigentlich nur noch schlafen. Da sind wir noch auf ein Detail gestoßen:

Medicus.ai betreibt auch ein Dashboard, auf dem sich Statistiken über die Anzahl der positiven, negativen und ungültigen Tests pro Testzentrum abrufen lassen.

Zudem lässt sich der dargestellte Zeitraum auf die Sekunde genau einschränken. Diese statistischen Daten sind sehr interessant – und machen auf Anhieb keinen brisanten Eindruck. Allerdings kann man auf der Plattform die Daten nach Testzeiträumen filtern – und den Filter sekundengenau einstellen. Wenn wir also Donald Duck beobachten, wie er um 14:42 das Testzentrum verlässt, können wir hinterher sein Ergebnis über das Dashboard herleiten. Die Ergebnisse können so leicht deanonymisiert werden.

Über das Statistik-Dashboard lässt sich auch nach Test-Betreiber filtern. Darunter finden sich nicht nur mobile Teams und Testzentren, sondern auch Firmen. Wir vermuten, dass ██████ und ██████████████ nicht wollen, dass ihre Test-Statistiken öffentlich sind.

Der Zugang zum Dashboard war mit einem Login versehen – leider haben auch hier die Zugangsdaten unserer Registrierung wunderbar funktioniert. Es wurde also nicht unterschieden zwischen zu testenden Personen und Mitarbeiter*innen, für die diese statistischen Daten eigentlich gedacht waren.

Vierter Akt: Kann ich den Test noch einmal genauer sehen?

Dadurch, dass wir über das Dashboard sekundengenau auf die Statistiken zugreifen können, wird auch ein anderes Problem größer, welches wir vorher für nicht sehr kritisch hielten:

Am Eingang des Test-Zentrums erhält man nach dem Vorzeigen des eigenen QR-Codes und des Ausweises zur Identitätsprüfung einen frischen QR-Code auf einem Stück Papier, den man beim Abstrich wieder abgibt. Nach dem Test wird dieser QR-Code und der Teststreifen abfotografiert und das Bild auf den Servern von medicus.ai abgelegt.

Die URL zum Bild hat ein einheitliches Format und unterscheidet sich lediglich an drei Stellen: die ID des Testzentrums, die User-ID der*des Getesteten und dem Timestamp des Testergebnis. Durch das Problem aus Akt 3 lässt sich die ID des Testzentrums einfacher raten und der sekundengenaue Zeitstempel der Testergebnisse ermitteln. Die User-ID der*des Getesteten ist aufsteigend und kann daher durchprobiert werden. Zudem ist das Foto nicht durch weitere Authentifizierung geschützt. Wer die URL kennt (oder errät) hat also Zugriff.

Nun sollte so ein Foto eines Ergebnisses auf einem Teststreifen nicht weiter problematisch sein – nur haben wir zumindest in den Berliner Testzentren von 21Dx Fotos gesehen, bei denen handschriftlich der Name der getesteten Person unter dem QR-Code notiert wurde.

Besonders brisant: Die Bilder werden im User-Interface für Testlinge gar nicht angezeigt. Warum die URL via API ausgeliefert wird, erschließt sich uns nicht.

Auch dieses Problem haben wir gemeldet.

Interlude: Der leidige Datenschutz / Eine Auftragsdatenverarbeitungsparty

Als wären diese ganzen wirklich technischen Probleme nicht genug, sind uns auch “ganz klassische” Datenschutzprobleme aufgefallen:

Das Testportal von 21Dx bei medicus.ai liegt hinter Cloudflare, d.h. alle Testergebnisse und personenbezogenen Daten werden einmal durch ein US-Unternehmen geleitet.

Ebenfalls sind Tracking-Skripte von sowohl Google als auch dem Zahlungsdienstleister Stripe eingebunden, die jeden Seitenaufruf analysieren.

Alle drei tauchen nicht in der Datenschutzerklärung von 21dx.medicus.ai auf.

Links in Mails werden über den Mail-Analytics-Service von Mandrill weitergeleitet.

Außerdem gibt es in der Oberfläche keine Möglichkeit, den eigenen Account zu löschen, dafür wäre dann wohl ein DSGVO-Löschantrag per E-Mail nötig?

Auch das Portal test-to-go.berlin der Senatsverwaltung für Gesundheit, Pflege und Gleichstellung des Landes Berlin setzt Google Analytics ein und lädt Schriftarten von Google. Hier ist es aber nicht so, dass diese nicht in der Datenschutzerklärung von test-to-go.berlin stehen würden. Stattdessen stehen dort viel mehr Dienste, als überhaupt genutzt werden: Zum Beispiel wird laut Datenschutzerklärung auf der Webseite Spotify eingebunden, ebenso wie Vimeo und YouTube.

Fünfter Akt: Ein Test am Wörthersee.

21Dx ist nicht der einzige Testzentren-Betreiber der SafePlay von medicus.ai einsetzt. Bei unserer Recherche sind wir u.a. auf die FH Kärnten gestoßen die ihren Mitarbeiter*innen und Studierenden COVID-19-Tests anbietet. Auch hier traten die gleichen Probleme auf, wie bei der SafePlay Instanz von 21Dx. Deswegen ist davon auszugehen, dass auch andere Testzentren-Betreiberfirmen, welche die Software von medicus.ai einsetzen, betroffen waren.

Sechster Akt: Test nur in rosa und hellblau?!

Aber wie kann man sich überhaupt testen lassen? Dafür hat die Berliner Senatsverwaltung die bereits eingangs erwähnte Webseite https://test-to-go.berlin einrichten lassen. Dort findet man verschiedene Testzentren. Bei manchen muss man vorher einen Termin vereinbaren, bei anderen nicht. Bei Berliner Testzentren von 21Dx, die eine Terminbuchung voraussetzen, findet die Terminvergabe zusätzlich über das Portal “samedi” statt. Also haben wir auch versucht, uns dort einen Termin zu besorgen. Als wir dort unsere Daten eingeben wollten, sahen wir diese Auswahl:

Doch was ist daran falsch?
Bereits seit 2013 gibt es die Option, den Geschlechtseintrag offen zu lassen („kein Eintrag“). Seit Ende 2018 gibt es in Deutschland zudem die Möglichkeit, beim Eintrag ins Personenstandsregister außer den Geschlechtern „männlich“ und „weiblich“ auch die Option „divers“ zu wählen, die sogenannte „Dritte Option“. Seitdem gibt es – auch in Berlin – viele Menschen, die diese Optionen nutzen. Die Antidiskriminierungsstelle des Bundes weist darauf hin, dass es einen Verstoß gegen das AGG ist, falls man bei Registrierungen nur die Möglichkeit hat, zwischen Mann/Frau bzw. Herr/Frau zu wählen.

Dieser Fehler wird nicht nur im Testtermin-Buchungsportal sondern auch im Impftermin-Buchungsportal bei Doctolib begangen:

Dort ist das Problem übrigens noch schlimmer: Denn im Gegensatz zu den Testzentren, bei denen manche keine Terminbuchung und damit Geschlechterauswahl voraussetzen, ist das bei den Impfzentren zwingend erforderlich.

Fazit

All diese Dinge dürfen nicht passieren. Wirklich nicht. Wenn wir als Gesellschaft die Eindämmung der Pandemie ohnehin bereits unnötigerweise über ein Jahr hinauszögern, die Impfung schleppend anläuft und auch erst jetzt offene Testmöglichkeiten für alle geschaffen werden, dann darf es wirklich nicht dazu kommen, dass selbst die grundlegenden Rahmenbedingungen für Tests so dilettantisch erledigt werden.

Tests können ein sehr wirksames Mittel in der Pandemiebekämpfung sein, wenn sie für alle verfügbar und besonders leicht zugänglich sind. Sie dürfen niemanden ausschließen und müssen so angelegt sein, dass die Menschen, die sich testen lassen wollen, sich nicht unnötig gestresst fühlen – und vor allem keine Angst davor haben.

Wenn solche Datenunfälle vorkommen, dann zerbröckelt die Bereitschaft zur Eindämmung der Pandemie beizutragen immer weiter. Wenn staatlich beauftragte Unternehmen nachlässig mit sehr sensiblen Daten umgehen, fällt das leicht auf die komplette staatliche Infrastruktur zurück. Dabei brauchen Menschen gerade jetzt das Vertrauen, damit sie die verfügbaren Angebote wie Tests und Impfungen auch wahrnehmen. Auch wir wollen uns testen und impfen lassen, ohne versehentlich in Sicherheitslücken zu stolpern!

Dazu Linus:

»Dies ist nicht die erste und sicherlich nicht die letzte Sicherheitslücke in hastig gebastelter Corona-IT. Wenn schon bei so einfachen Aufgaben katastrophale Anfänger-Fehler passieren, sollten die Verantwortlichen erstmal ihre Hausaufgaben machen. Stattdessen werden als nächstes mehrere Millionen Euro für fragwürdige Blockchain-Impfnachweise versenkt.«

Ein Teil des Vertrauens würde sich auch wieder gewinnen lassen, wenn staatliche Stellen nicht alles einfach nur deswegen einkaufen, weil AI oder Blockchain draufsteht. Diese Hype-Begriffe sind eben keine Labels, die Lösungen besonders vertrauenswürdig machen - sondern eher ein Indikator dafür, wer sich besonders leicht über den Tisch ziehen lässt.

Thomas Lohninger von der Datenschutz-NGO epicenter.works, die uns beim Kontakt mit den zuständigen Behörden in Österreich unterstützt hat, sagt dazu:

»Es ist jetzt an den betroffenen Firmen und zuständigen Datenschutzbehörden, diesen Skandal aufzuklären. Diese unverantwortliche Fahrlässigkeit zeigt wie leichtfertig mit unseren Gesundheitsdaten umgegangen wird. Was ständig auf der Strecke bleibt, ist das Vertrauen der Bevölkerung in die angemessene Bewältigung dieser Krise.«

Bei der Veröffentlichung haben wir neben CCC und epicenter.works auch mit Journalist*innen von rbb|24, SZ und dem Standard.at zusammengearbeitet. Wir haben hier nur unseren Teil der Geschichte aufgeschrieben, auf den folgenden Seiten findet ihr weitere fundierte Informationen, Recherchen und eine journalistische Einordnung:

• Pressemitteilung des CCC

• Pressemitteilung epicenter.works

• Artikel des RBB

• Artikel des Standard.at

• Artikel der SZ

Danke dafür <3

Disclosure Timeline

• 2021-03-09: Teammitglied macht Schnelltest bei 21Dx
• 2021-03-10: Wir schauen routinemäßig in den Datenverkehr des Testportals
• 2021-03-10 23:00 Uhr: Teammitglied findet die PDF-Download-URL und ändert ID
• 2021-03-10 23:05 Uhr: Andere Team-Mitglieder können es reproduzieren
• 2021-03-11 00:30 Uhr: Wir erhalten Kontakt zum BSI / CERT-Bund
• 2021-03-11 03:10 Uhr: Vorläufige Dokumentation des Problem 1 ist fertig, wird ans BSI gesendet
• 2021-03-11 13:10 Uhr: Wir schicken die vorläufige Dokumentation an Datenschutzbehörden von Bund und einigen Ländern
• 2021-03-11 13:15 Uhr: Bei einem zufälligen Test stellen wir fest, dass Probleme 1 und teilweise 2 behoben scheinen
• 2021-03-11 23:30 Uhr: Wir sind auf das offene Analytics-Dashboard gestoßen
• 2021-03-12 02:00 Uhr: Wir senden einen Aufschrieb der Probleme 2-4 an das CERT-Bund
• 2021-03-15 07:30 Uhr: CERT-Bund informiert uns, dass Aufschrieb an den Hersteller weiter geleitet wurde
• 2021-03-15 16:45 Uhr: Bei einem zufälligen Test stellen wir fest, dass auch Probleme 2-4 behoben scheinen
• 2021-03-18 06:00 Uhr: Veröffentlichung dieses Blogposts