Die Anatomie von typischen Datenlecks bei Test- und Impfterminvergabe

Seit Anfang 2021 sammelt sich in den Postfächern der c’t-Redaktion eine neue Kategorie von Zuschriften: „Datenschutzproblem bei Terminvergabe“ oder „Datenleck bei Impfportal?“ lauten ­häufige Betreffzeilen. Dahinter stecken Berichte von Lesern, die sich in einem Corona-Schnelltestzentrum oder bei einer Arztpraxis für einen Schnelltest oder eine spontane Impfung angemeldet haben: „Wenn ich das richtig sehe, ­könnte ich auf diesem Weg die Daten von Tausenden anderer Patienten einsehen.“

Für gewöhnlich reagieren wir auf solche Hinweise immer nach einem ähn­lichen Schema: Zunächst versuchen wir, den Fehler nachzustellen und zu dokumentieren. Dann stellen wir weitere Analysen rund um den betreffenden Dienst an und stoßen nicht selten auf weitere Probleme: Alte Versionen von Serversoftware, Lücken in der Serverkonfiguration (etwa aktives Verzeichnis-Listing bei Apache-­Servern, über das man eigentlich vertrauliche Ordner findet) oder Probleme mit HTTPS und dem Zertifikat sind typischer Beifang. Meist bestätigt sich die Beobachtung der Leser, manchmal fanden wir noch tiefergehende Probleme, weil wir schon ähnliche Systeme kannten und die Lücken mit Erfahrungen von anderer Software kombinieren konnten. Über all diese Beobachtungen informieren wir die Betreiber im Rahmen von Responsible Dis­closure – solange Daten noch ungewollt öffentlich erreichbar sind, schreiben wir nicht über den Fall.

Allzu ähnliche Probleme

Sind die Probleme abgestellt, berichten wir oft ausführlich über die Fälle – vor allem, damit andere Entwickler und Administratoren nicht in ähnliche Fallen tappen. Zuletzt veröffentlichten wir Probleme mit der Online-Funktion für die Aldi-­Schnelltests [1]. Seit Anfang 2021 haben wir uns aber immer häufiger dagegen entschieden, jeden Fall, der im Postfach landet, in einem Artikel vorzustellen. Schlagartig hatten bundesweit Arztpraxen und Apotheken, Betreiber von privaten oder kommunalen Testzentren die Aufgabe, Termine für Schnelltests und Impfungen (abseits der Impfzentren) zu vergeben, Ergebnisse zu kommunizieren oder online prüfbare Testzertifikate auszustellen. Und genauso schlagartig hatten Anbieter passende Softwarelösungen bereit, die Ärzte, Apotheken und Testzentren in ihre Homepage integrieren konnten. Die Anbieter treten teilweise nur regional begrenzt in Erscheinung, beliefern etwa mehrere Arztpraxen in einer Stadt mit ihrer Lösung. Obwohl viele kleine Hersteller völlig unabhängig voneinander eigene Software geschrieben haben, sehen sich die Fehler alle extrem ähnlich.

Wir prüfen zwar weiterhin eingehende Hinweise, stellen die Fehler nach und informieren die Betreiber mit einer ausführlichen Beschreibung des Problems, haben uns aber dazu entschieden, die typischen Probleme dieser Softwarelösungen in einem Artikel zu sammeln. Spannender und lehrreicher ist ohnehin die Anatomie typischer Sicherheits- und Datenschutzpannen. Eins lässt sich festhalten: Von der Optik darf man sich nicht täuschen lassen, sie sagt nichts über die Fähigkeiten der Entwickler aus. Offensichtliche Fehler fanden wir sowohl in Plattformen im Retro-Look als auch in schicken modernden Frontends.

1. Falsche Einstellung

Wer eine Terminvergabesoftware baut, die Impftermine oder Schnelltests verwaltet, kommt schnell mit Gesundheitsdaten von Nutzern in Kontakt. Für diese fordert die DSGVO einen besonderen Schutz. Wer an die Aufgabe mit der Einstellung herangeht, „mal eben“ eine Software zusammenzustricken, wird also zwangsläufig scheitern. Ein ausführliches Gespräch mit dem hauseigenen Datenschutzbeauftragten ist Pflicht, eine Beratung bei einem Anwalt für IT-Recht kann nicht schaden, wenn man in das Geschäftsfeld einsteigen will – und zwar be­vor man die erste Zeile Code schreibt

Selbstverständlich ist das nicht: Bei einem Telefonat mit dem Datenschutzbeauftragen eines Test-Anbieters mit akuten Problemen erfuhren wir, dass dieser erst einbezogen wurde, als die Software schon am Netz war und mehrere Tausend Nutzerdatensätze verarbeitet hatte. Bei einem anderen Anbieter mit offenen Hintertüren gelang es uns schlicht nicht, den Betreiber oder dessen Datenschutzbeauftragten überhaupt zu erreichen: Die Mail-Adressen aus Impressum und Datenschutzerklärungen existierten nicht, telefonisch waren weder der Datenschutzbeauftragte noch der Geschäftsführer zu erreichen. Schließlich informierten wir den Arzt, der den Dienst in seine Seite eingebettet hatte. Danach verschwand der Dienst erst vom Netz und erschien dann runderneuert und ohne die offensichtliche Schwachstelle wieder (mit neuem Datenschutzbeauftragtem).

Zu einem verantwortungsvollen Umgang mit Nutzerdaten gehört es auch, auf Überflüssiges zu verzichten: Neben den offensichtlichen Datenlecks fanden wir bei vielen Anbietern Google-Analytics-Cookies, Einbettungen (Grafiken und CSS) von Facebook und PayPal, Schriftarten, die von ­Google Fonts nachgeladen wurden, und JavaScript von externen CDN-Servern. Sowas passiert leicht, wenn die Entwickler gedankenlos auf ihren Standardbaukasten zurückgreifen.

Die eindringliche Warnung an alle Betreiber: Lassen Sie in diesem sensiblen Bereich die Finger von solchen Spielereien! Eine Test- oder Impfterminseite für deutsche Patienten gehört komplett auf Server in deutschen oder europäischen Rechenzentren. Tracking und externe Einbindungen haben hier nichts verloren – schon die Information, dass sich jemand überhaupt fürs Impfen interessiert, geht Dritte nichts an. Aus gutem Grund möchten sich viele Nutzer nicht tracken lassen, wenn sie Gesundheitsdaten in ein Formular eingeben sollen.

2. Berechenbare IDs

Der absolute Klassiker unter den Datenleckursachen ist die einfach zu erratende ID. Mit etwas Ausprobieren findet man so schnell fremde Daten. Diese Fälle sind immer ähnlich: Am Ende eines Terminvergabe- oder Anmeldeprozesses bekommt der Besucher eine PDF-Datei zum Ausdrucken – mit URLs wie

https://coronatest.example.org/user/1234/print_result.pdf. 

Generiert werden diese Dateien meist dynamisch, ein Blick in die Metadaten verrät, dass häufig die Bibliothek FPDF dahintersteckt, ausgeführt von PHP-Code. Der Server schlägt beim Generieren dieser Datei den Nutzer mit der ID 1234 in seiner Datenbank nach, schreibt Namen, Geburtstag, Impftermin oder Testergebnis in PDF-Daten und liefert diese direkt an den Browser aus.

Wer als Entwickler in der URL mit natürlichen Zahlen arbeitet und keine weitere Sicherung einbaut, gefährdet leichtsinnig die Daten seiner Nutzer. Denn alle bereits vergebenen IDs sind extrem leicht zu erraten. Tippt ein Nutzer 1233 statt 1234 in die Adresszeile, sieht er die Daten seines Vorgängers im System und kann sich durch über 1000 weitere Datensätze hangeln. Manchmal wird diese ID auch als „Geheimnis“ benutzt. An anderer Stelle im System wird genau sie als Passwortersatz zusammen mit dem Namen in einem Formular verlangt, um sich am System anzumelden und dort den Termin zu stornieren oder zu ändern. Variationen des Fehlers fanden wir oft: mal leicht zu sehen, mal etwas versteckt in einem HTTP-Request im Hintergrund, mal in einen QR-Code eingebacken.

Wann immer Sie vor der Aufgabe stehen, ein ähnliches Szenario zu programmieren, nutzen Sie als ID eine ausreichend lange Folge von Zufallszeichen (nicht beschränkt auf Ziffern). Eine 32 Zeichen lange Kette aus zufälligen Buchstaben und Zahlen oder der Hash einer zufälligen Zeichenkette lassen sich in endlicher Zeit nicht erraten. Überlegen Sie als Entwickler auch, was Sie alles auf ein Negativtest­zertifikat schreiben oder im QR-Code ­kodieren wollen. Wenn sich der Friseur, der nur die Gültigkeit prüfen soll, mit den Informationen auf dem ausgedruckten Testzertifikat am System als Nutzer anmelden kann, enthält das ganze System einen offensichtlichen Denkfehler.

3. Datenhalden

Wenn der Grund für die Datenspeicherung entfallen ist, dürfen die Daten auch nicht mehr auf dem Server liegen. Denn was restlos gelöscht wurde, kann bei Datenlecks auch nicht versehentlich ausgespuckt werden. Bei den problematischen Systemen, die wir uns angesehen haben, war diese Erkenntnis nicht immer angekommen. Datensätze, die wir durch andere Fehler fanden, reichten oft Wochen und Monate zurück (bis zum Start des Angebots).

Dabei kann es so einfach sein: Hat man zum Beispiel einen Termin für eine Impfung bei einem Arzt gebucht, ist der Datensatz ziemlich genau bis zu dem Zeitpunkt relevant, an dem die Impfung stattgefunden hat. Auf dem Server kann also ein Cronjob laufen, der alle halbe Stunde die erledigten Datensätze in der Datenbank löscht – und zwar mit einem DELETE-Befehl, nicht als Soft-Delete über eine Datenbankspalte wie isDeleted, die auf true gesetzt wird. Braucht man die Informationen über die Terminvergabe später noch für statistische Auswertungen, kann der Cronjob alle personenbezogenen Daten (etwa Name, Geburtstag, Anschrift) auch mit Zufallsstrings überschreiben oder anonymisierte Datensätze regel­mäßig in eine andere Tabelle kopieren und die Originale löschen. Monatelang anlasslos auf dem Server herumliegen dürfen die personenbezogenen Daten keinesfalls. Derlei Sorglosigkeit im Umgang mit Daten ist schon vielen zum Verhängnis geworden.

4. Vermeintlich Geheimes

Ein Fall stieß aus der Masse durch besonders undurchdachtes Design heraus. Auf die Spur kamen wir dem Problem leicht mit einem Blick in die Entwicklerwerkzeuge des Browsers (alle Browser haben einen solchen Werkzeugkasten an Bord). Im Reiter „Netzwerk“ (oder „Network“ )kann jeder Besucher einer Seite leicht nachvollziehen, welche Daten der Browser von welchen Servern geladen hat. Wie einfach das geht, war einem Anbieter vermutlich nicht bewusst – sein Server schickte Hunderte Datensätze von Nutzern als JSON-Objekt an den Browser, der dann per JavaScript nur das ei­gene Ergebnis herauspickte und in der Oberfläche darstellte. Unter allen Möglichkeiten, die Bereitstellung der Daten umzusetzen, ist das die schlechteste! Der Webserver darf zu keinem Zeitpunkt mehr Daten ausliefern, als der Benutzer sehen darf.

Programmierer sind gut beraten, sich selbst immer beim naheliegenden Gedanken „Wer soll da schon drauf kommen?“ auf die Finger zu klopfen. Gehen Sie am Ende der Entwicklungsarbeit alle Schritte der Software noch einmal durch und verfolgen Sie jeden HTTP-Aufruf in den Entwicklerwerkzeugen mit einer Frage im Hinterkopf: „Was könnte man hier Unangenehmes anstellen oder ausprobieren?“ Am besten lassen Sie am Ende einen Kollegen (oder noch besser einen professionellen Penetration-Tester) die Anwendung vor der Veröffentlichung noch einmal gründlich unter­suchen.

Denken Sie daran, dass Ihre Anwendung unter besonderer Beobachtung steht. Unter den Impf- und Testwilligen sind sehr sicher auch IT-Experten, die sich Ihre Anwendung genauer ansehen werden. Nicht unbedingt, um sie anzugreifen, sondern im ersten Schritt, um sich ein Skript zu basteln, das automatisch auf freie Termine hinweist. Gerade Impftermine sind aktuell ein knappes Gut und ein Termin-Bot ein nützliches Feierabendprojekt. Bei GitHub sind in letzter Zeit zahlreiche solcher kleiner Projekte aufgetaucht (suchen Sie dort einfach nach „vaccination“).

5. Unbedarfte Kreativität

Auf einen sehr kreativen, aber nicht weniger gruseligen Weg wies uns ein Leser aus Hessen hin. Die Praxis seines Hausarztes hatte für Terminvergaben eine Anleitung auf seiner Homepage veröffentlicht: Die Patienten wurden aufgefordert, dem Link zum Angebot eines Online-Faxdienstes zu folgen. Dieser bietet als Demonstration seines Dienstes ein kostenloses Fax über ein Textfeld an – ausdrücklich nur als Demo gekennzeichnet.

Die Patienten sollten dort neben Kontaktdaten auch intime Details zur Krankengeschichte ins Textfeld eintippen und die Terminanfrage als Testfax an die Nummer der Arztpraxis schicken. Versehen war diese einfallsreiche Schritt-für-Schritt-­Anleitung mit dem Hinweis „Bitte beachten Sie, dass Ihre Daten unverschlüsselt übertragen werden“. Später heißt es noch, man könne selbstverständlich keine Haftung für die Daten im Internet übernehmen.

Was tun?

Ärzte und Apotheker, die eine Lösung für die Terminvergabe suchen, sollten sich die Software sehr gewissenhaft ansehen (oder einen unabhängigen IT-Experten zurate ziehen) – am besten in einem öffentlichen System in einer anderen Praxis. Probieren Sie (oder ein kompetenter Vertrauter) den ganzen Prozess einmal durch und achten Sie mindestens auf den häufigsten und einfachsten Fehler. Sobald eine verdächtige Zahl in einer URL auftaucht, lohnt ein kurzer Test mit benachbarten Zahlen. Wie ernst es ein Anbieter mit Datenschutz nimmt, sehen Fortgeschrittene mit einem Blick in die Entwicklerwerkzeuge ihres Browsers: Wer ganze Arbeit geleistet hat, kommt ohne Google- und Facebook-Tracking aus. Schauen Sie auch, welche Daten genau erfasst werden – je weniger, desto besser. Für eine Impfterminvergabe ist es zum Beispiel nicht erforderlich, den genauen Grund einer Priorisierung (schlimmstenfalls die ganze Krankengeschichte) im System einzutragen.

Nachdem Sie die Seite von außen gründlich untersucht haben, bleibt Ihnen als Patient nur Vertrauen. Wie sicher die Daten hinter den Kulissen aufbewahrt werden, finden Sie nicht so schnell heraus. Wenn ein Bestätigungslink oder ein QR-Code auch Wochen nach dem Test oder Termin funktionieren, ist das aber ein schlechtes Zeichen und es lohnt sich, den Anbieter zur Löschung der Daten aufzufordern. Hierfür können Sie sich auf die DSGVO berufen und unseren kostenlosen Musterbrief nutzen (siehe ct.de/y3vn). Sollten Sie offensichtliche Fehler finden, scheuen Sie sich nicht, den Datenschutzbeauftragten des Betreibers in der Datenschutzerklärung ausfindig zu machen und zu informieren. (jam@ct.de)

DSGVO-Musterbrief: ct.de/y3vn