Wir wollten ja eigentlich nichts mehr mit Corona machen, aber dann kam ein Testzentrum dazwischen. 🙄

Es begann ähnlich wie das letzte Mal: Ein zerforschungs-Angehöriger war beim Corona-Schnelltest und bekam danach eine E-Mail mit einem Link zu seinem Ergebnis. Das kam ihm irgendwie fischig 🐟 vor, also haben wir uns das mal angeschaut.

Die E-Commerce-Bude macht jetzt auch in Testzentren

Der Anbieter Eventus Media International (EMI) betreibt unter anderem in Leipzig, Berlin, Hamburg, Schwerte und Dortmund Testzentren unter der Marke testcenter-corona.de und bietet Software und Infrastruktur als Franchise-Modell an.

Statt die eigene Website von Grund auf selbst zu entwickeln, setzt testcenter-corona.de auf WordPress, ein weitverbreitetes Open-Source-Blog-System. Seine große Beliebtheit hat WordPress unter anderem seiner vielseitigen Erweiterbarkeit durch Plugins zu verdanken. Diese ermöglichen es, dem System Funktionalitäten hinzuzufügen, die weit über das Veröffentlichen eines Artikels auf einem Blog hinaus gehen. In diesem Fall das Buchen von Terminen und Abrufen von Testergebnissen.

Dabei haben sie erst einmal etwas richtig gemacht: Für das Abrufen der Ergebnisse werden keine aufsteigenden Nummern verwendet, sondern zufällige 10-stellige, alphanumerische Zeichenketten.

WordPress-API

WordPress besitzt eine API, also eine Schnittstelle, über die viele der Inhalte einer Seite maschinenlesbar von anderen Systemen abgerufen und weiterverwendet werden können. Diese API ermöglicht z.B. die Nutzung der WordPress-App, aber auch anderer Editoren und Anwendungen.

In WordPress kann man zusätzlich zu den vorhandenen Standardtypen für Inhalte wie z.B. Blogposts, Seiten oder Kommentare eigene Inhaltstypen definieren – und diese optional über die API verfügbar machen. Die API ist unter /wp-json/ abrufbar, einzelne Posts zum Beispiel unter /wp-json/wp/v2/posts. Registriert man nun einen eigenen Inhaltstyp mit dem Namen beispielname und aktiviert den Zugriff über die API, sind alle Einträge von diesem Typ unter /wp-json/wp/v2/beispielname abrufbar.

EMI hat für die Testzentren-Websites den eigenen Inhaltstypen registration für Schnelltest-Registrierungen angelegt, welcher Terminbuchungen und Testzertifikate abbildet.

Da EMI aus uns unerklärlichen Gründen die API-Zugriffsmöglichkeit für diese aktiviert hat, sind alle Registrierungen auch über diese abrufbar.

Fragt man nun die Schnittstelle für Registrierungen eines Test-Zentrums an (/wp-json/wp/v2/registration/), so erhält man eine Liste:

[
	{
	    "id": 1234,
	    "date": "2021-04-10T03:45:56",
	    "date_gmt": "2021-04-10T01:45:56",
	    "guid": {
	        "rendered": "https://[…]/registration/abcdef1234/"
	    },
	    "modified": "2021-04-10T03:45:56",
	    "modified_gmt": "2021-04-10T01:45:56",
	    "slug": "abcdef1234",
	    "status": "publish",
	    "type": "ev_tc_registration",
	    "link": "https://[…]/registration/abcdef1234/",
	    "title": {
	        "rendered": "abcdef1234"
	    },
	    "template": "",
	    "_links": {
	        "self": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/registration/1234"
	            }
	        ],
	        "collection": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/registration"
	            }
	        ],
	        "about": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/types/ev_tc_registration"
	            }
	        ],
	        "wp:attachment": [
	            {
	                "href": "https://[…]/wp-json/wp/v2/media?parent=1234"
	            }
	        ],
	        "curies": [
	            {
	                "name": "wp",
	                "href": "https://api.w.org/{rel}",
	                "templated": true
	            }
	        ]
	    }
	},
	…
]

Darin steht unter anderem ein 10-stelliger, alphanumerischer Code… – Moooment mal, solche Codes haben wir doch schonmal auf dieser Website gesehen. Das werden doch nicht genau die Codes zum Abruf des Testergebnisses sein, oder?

Doch tatsächlich entdecken wir relativ schnell unseren eigenen Abrufcode.

Wir haben also eine Liste aller Abrufcodes. Das ist in etwa so, als würde man sich einen Safe einbauen lassen, aber den Code dann direkt daneben legen.

Diese Abrufcodes kann man auf der Testergebnisabfrage-Seite eingeben und erhält dann ein fremdes Ergebnis. Auch hier war das Ergebnis wieder mehrstufig – zuerst eine kurze Seite, die das eigentliche Ergebnis (positiv/negativ) anzeigt und dann eine Downloadmöglichkeit für ein PDF, welches deutlich mehr Angaben enthält:

• Vorname
• Name
• Anschrift
  • Straße
  • Hausnummer
  • Postleitzahl
  • Ort
  • Land
• ggf. Anschrift derzeitiger Aufentaltsort
  • Straße
  • Hausnummer
  • Postleitzahl
  • Ort
  • Land
• Geburtsdatum
• Telefonnummer
• E-Mail-Adresse
• Test
• Testdatum
• Testergebnis

Betroffen waren am 6.4.2021 über 14.000 Registrierungen mit hinterlegtem Testergebnis, wie folgt auf Städte verteilt:

Ein im Vergleich unwichtig wirkendes Detail: Die Macher*innen scheinen kein Rate-Limiting eingebaut zu haben. Auf die Schnittstelle hätte man eine Begrenzung legen können, wie viele Anfragen in einem definiertem Zeitraum möglich sind, um zumindest massenhafte Abfragen zu verlangsamen.

Dennoch waren die Testergebnisse (positiv/negativ/noch nicht vorliegend) aller 25.000 Registrierungen abfragbar, ohne an eine solche Grenze zu stoßen.

Und jetzt?

Weil es sich um besonders schützenswerte Daten handelt, war es uns wichtig, dass die Lücke möglichst schnell geschlossen wird. Deshalb haben wir uns auch hier wieder mit einem detailierten Aufschrieb an das BSI gewendet. Dieses hat das Problem anonymisiert an das Unternehmen weitergeleitet.

Reaktion der Macher*innen

Nachdem Eventus Media International vom BSI informiert wurde, haben sie die Lücke am gleichen Tag geschlossen. Zusätzlich wurde am nächsten Tag ein weiteres Feld beim Abruf eines Testergebnisses eingeführt. So muss jetzt nicht mehr nur der 10-stelligen Code, sondern auch Vorname, Nachname oder E-Mail-Adresse der getesteten Person eingegeben werden. Für alle Testergebnisse, die vor dem 7.4. erstellt wurden, wurde zudem ein neuer Code generiert und per E-Mail zugesendet.

Für die Veröffentlichung haben wir mit Journalist*innen des NDR, RBB und MDR zusammengearbeitet.

Gegenüber diesen sagte ein Sprecher von EMI, dass man

»Testcenter, einschließlich der damit verbundenen Datenverarbeitungssysteme, mit großer Eile hochgezogen und mit versierten IT-Spezialisten zusammengearbeitet [habe] um den Kunden, die das Testangebot in Anspruch nehmen wollen, die größtmögliche Sicherheit gewährleisten zu können. […] Dass Hacker trotzdem auf einen Teil der Daten zugreifen konnten, tut uns leid, und wir entschuldigen uns bei den betroffenen Kunden.«

Bis zur Veröffentlichung dieses Artikel wurden uns bekannte Kund*innen noch nicht über das Datenleck informiert.

Fazit

Das ist jetzt schon das zweite Mal, dass wir zufällig so ein Datenleck in Testzentrums-Software finden.

Wir müssen uns an dieser Stelle leider wiederholen:

[Das] darf nicht passieren. Wirklich nicht. Wenn wir als Gesellschaft die Eindämmung der Pandemie ohnehin bereits unnötigerweise über ein Jahr hinauszögern […], dann darf es wirklich nicht dazu kommen, dass selbst die grundlegenden Rahmenbedingungen für Tests so dilettantisch erledigt werden.

Im Unterschied zum letzten Mal: Testen ist kein optionales Feature mehr. In einigen Bundesländern sind Tests inzwischen Vorraussetzung für Teile des öffentlichen Lebens.

Auch wenn man nicht gerade in den Baumarkt, zum Friseur oder zum Möbelhaus muss, können Tests ein sehr wirksames Mittel in der Pandemiebekämpfung sein, wenn sie für alle verfügbar, leicht zugänglich und auch technisch sicher sind. Dazu gehört auch, dass man sich mit gutem Gewissen testen (und impfen) lassen kann, ohne dabei Angst haben zu müssen, dass die eigenen Daten plötzlich öffentlich sind.

Wieso kommen solche Lücken immer wieder vor?

Unternehmen scheinen bei solchen Problemen keine Konsequenzen zu fürchten. Wenn wir so etwas finden, gibt es zwar negative Presse, aber am Ende dürfen solche Anbieter weitermachen, oder sogar an Ausschreibungen mitschreiben und diese auf sich selber optimieren.

Stattdessen sollten die Datenschutzbehörden solche Vorfälle ernst nehmen und z. B.

1. die Anbieter zwingen, allen Kund*innen Bescheid zu sagen sowie
2. empfindliche Strafen verhängen.

Solch härteres Vorgehen wäre rechtlich bereits möglich, es müsste nur getan werden.

Der Schutz von Gesundheitsdaten, darf nicht auf die leichte Schulter genommen werden.

Dabei darf die besondere Pandemielage und schnelle Handlungsfähigkeit keine Ausrede sein.

Unternehmen müssen hier ihrer Schutz- und Sorgfaltspflicht vor dem Start nachkommen – und wenn sie dies nicht können, dann haben sie in diesem Bereich nichts verloren.

Bei der Veröffentlichung haben wir mit Journalist*innen von MDR, NDR und rbb zusammengearbeitet. Auf den folgenden Seiten findet ihr weitere fundierte Informationen, Recherchen und eine journalistische Einordnung:

• Radiobeitrag des MDR und des NDR
• Artikel des rbb|24
• Beitrag in der 12.00 Uhr-Tagesschau und Tagesschau.de-Artikel

Danke dafür <3

Timeline

• 2021-03-31: Wir schauen uns den Anbieter an und finden die Lücke. Wir beginnen das Problem nachvollziehbar aufzuschreiben.
• 2021-04-02 04:00 Uhr: Wir senden Aufschrieb ans CERT-Bund beim BSI
• 2021-04-06: BSI leitet Informationen an Datenschutzbeauftrage*n des Unternehmens weiter
• 2021-04-06: Lücke ist geschlossen