Zum hauptinhalt springen

zerforschung

Wir wissen noch immer, wie du getestet wurdest. Der Tragödie nächster Teil

Modifizierter Screenshot der Testbuchungsseite, mit dem Text: 'Datenleck buchen - Wie viele Daten sollen enthalten sein?'

Was haben Berlin, Ravensburg und München gemeinsam? Sie haben Testzentren, die mit der gleichen Software arbeiten. Und wenn wir über Testzentren schreiben, ist es leider wenig überraschend, dass es mal wieder um ein Datenleck geht. Betroffen sind diesmal mehr als 80.000 Testergebnisse bei vier verschiedenen Testzentrums-Firmen.

Testergebnisse raten

[…] Ein deutschlandweit genutztes System von Testzentren, Google-Cloud und Url-Shortener aus der Karibik (meines Wissens sogar ohne Datenschutzerklärungserwähnung) inklusive. […] Habt ihr Lust, euch das mal ein wenig näher anzusehen?

Mit dieser Nachricht wurden wir gleich auf vier Testzentren-Betreibende hingewiesen, die alle die gleiche Software verwenden: Neben Berlin und München auch noch in Ravensburg, Weingarten, Bad Waldsee und Markdorf. Ein Blick in OpenStreetMap verrät, dass die letzten alle im Großraum Ravensburg liegen.

Wir bekommen in letzter Zeit immer mal wieder Hinweise, aber haben nicht immer die Zeit uns alles genauer anzuschauen. In diesem Fall hat es zeitlich gerade gepasst und wir haben mal einen Blick drauf geworfen.

Die Testergebnisse werden per SMS zugestellt. Da aber das Versenden von SMS mit mehr als 160 Zeichen zuätzliche Kosten verursacht, wollten die Anbieter die SMS vermutlich möglichst kurz halten. Deswegen benutzen sie für den Link zum Ergebnis-PDF den URL-Shortner is.gd.

URL-Shortlink-Anbieter ermöglichen, eine sehr lange und komplexe URL durch eine wesentlich kürzere zu ersetzen, die aber zur gleichen Website führt. So lassen sich URLs einfacher weitergeben, etwa in einem Telefonat. Richtig beliebt wurden diese Services aber mit dem Aufkommen von Twitter, da bei anfangs 140 Zeichen jedes zusätzliche Zeichen einer URL wertvollen Platz für Text kostete. Viele Anbieter änderten ihr Konzept von möglichst merkbaren URLs auf möglichst kurze. Oft wurden die Kurzlinks nicht mal zufällig generiert, sondern die Zeichen nur hochgezählt. Technisch sind Kurz-URLs nichts anderes als eine Weiterleitung und intern nur eine Datenbank, welche die Abkürzungen den langen URLs zuordnet.

Die Links bei unseren Testzentren waren nach diesem Schema aufgebaut: is.gd/ABC123, wobei ABC123 eine 6-stellige Kombination von Groß-, Kleinbuchstaben und Ziffern ist.

Schon das ist ein riesiges Problem. Sechs Stellen sind wirklich nicht viel. Und bei 62 möglichen Zeichen pro Stelle und 6 Stellen gibt es insgesamt nur etwa 57 Milliarden mögliche Kombinationen. Das klingt jetzt erstmal nach einer Menge Möglichkeiten, aber es ist mit vertretbarem Aufwand möglich, all diese URLs durchzuprobieren.

Die E-Mails, die ich schrieb, werd ich nun nicht los

Unsere Erfahrung sagt: Wenn schon bei den SMS nicht auf Sicherheit geachtet wird, ist vermutlich auch das Datenleck nicht weit. Deshalb haben wir uns auch die Terminbuchungsseite angeschaut und einen Blick in den Quellcode geworfen.

Das geht mit jedem Browser: Ein Rechtsklick genügt, um die Entwicklertools zu öffnen, den Code zu lesen und nachzuvollziehen, was genau der eigene Browser tun soll.

Dabei schauen wir in der Regel auf die Teile des Codes, die Daten vom Server abrufen. Eine dieser Code-Stellen fragt eine Liste der Testzentren-Betreibenden ab:

console.log("getting teststationen from "+'operators/' + operator + '/');

// get Teststationen
db.collection('operators/').get().then(querySnapshot => {
    querySnapshot.forEach(doc => {

        if (doc.id == operator) {
            var data = doc.data();
            location_codes = data.location_codes;
            location_names = data.location_names;
        [...]

Diese Abfrage passiert also jedes Mal, wenn der Browser die Seite neu lädt. Und immer, wenn im Browser Daten abgerufen werden, kann man diese mitlesen. Auch hierfür braucht man keine speziellen Werkzeuge, denn mit einem Rechtsklick ins Browserfenster kann man nicht nur den Code anschauen, sondern auch den Datenverkehr “untersuchen”.

Aus den dort geladenen Daten fällt die Liste der Betreibenden mit zusätzlichen Informationen:

{
    "test_types": [
        "fastonly"
    ],
    "location_names": [
        "Testcenter Friedrichstraße"
    ],
    "baseURL": "https://www.corona-gurgeln.de/",
    "location_addresses": [
        "Ecke Friedrichstraße/Torstraße"
    ],
    "positivemail": "info@corona-gurgeln.de",
    "SMSsenderName": "Teststation",
    "sendinbule_api_key": "xkeysib-████████████████████████████████████████-████████████████",
    "companyAddressLine2": "10717 Berlin",
    "companyAddressLine1": "Uhlandstr. 68",
    "location_codes": [
        "AN03"
    ],
    "companyName": "Deckert Vertriebs GmbH"
}

Eine Information sprang uns direkt ins Auge: Der sendinbule_api_key (sic!), der bei jeder Testzentrums-Firma aufgeführt war. Einen Dienst namens “sendinbule” haben wir leider nicht gefunden. Stattdessen probierten wir aus, ob der API-Key vielleicht beim E-Mail-Provider “Sendinblue” funktionieren könnte.

Sendinblue ist ein sogenannter transaktioneller E-Mail-Provider. In den letzten Jahren ist es schwieriger geworden, als neuer Anbieter E-Mails selber so zu versenden, dass sie in der Inbox landen und nicht sofort im Spamfilter hängen bleiben. Statt sich also selbst um den Mailversand zu kümmern, bezahlen immer mehr Anbieter Unternehmen wie Sendinblue, Sendgrid oder Mailjet, damit diese die E-Mails für sie versenden. Das kennen wir schon von unserem Ausflug in den Code von Gorillas.

Mal wieder Volltreffer: Dort funktionierten die API-Keys wunderbar. Die API von Sendinblue kann aber nicht nur E-Mails versenden, sondern es lassen sich darüber auch alle jemals gesendeten E-Mails abrufen.

Screenshot der Sendinblue API Dokumentation - Funktion 'Get the list of transactional emails on the basis of allowed filters'

Die alles entscheidende Frage ist: »Welche E-Mails könnte ein Testzentrum wohl verschicken?«. Da müssen wir nicht allzu lange nachdenken – surprise, surprise: Filtern wir die E-Mails nach dem Betreff “Ergebnis”, erhalten wir über 80.000 Treffer.

Bei jedem positiven Test wird zusätzlich eine E-Mail an den jeweiligen Anbieter des Testzentrums verschickt, vermutlich damit diese dann das Gesundheitsamt informieren können. Filtern wir nur nach solchen E-Mails, bekommen wir 190 Ergebnisse.

Zusammengefasst ist es in etwa so, als würde man die Zugangsdaten zum eigenen E-Mail-Account öffentlich auf seine Webseite schreiben.

Datenschutz, nein Danke?

Über die Untersuchen-Funktion des Browsers kommen wir leider nicht nur an die API-Keys für Sendinblue, sondern auch an die E-Mail-Adressen der Testzentren. An diese werden, wie oben erwähnt, die positiven Ergebnisse gesendet. Wir mussten dann doch sehr staunen, als wir die genauen Mail-Adressen gesehen haben: Für die Testzentren der “Leif Ventures UG”, die testcenter.berlin betreibt, ist eine normale Google-Mail-Adresse hinterlegt. Die Postfächer der “Gemeinsam neue Wege GmbH”, die coronatest-rv.de betreibt, liegen bei Office 365.

Auch sonst wird anscheinend mit den erhobenen Gesundheitsdaten eher sorglos umgegangen, obwohl diese eigentlich besonders geschützt werden müssen. So werden die Daten nicht nur über den oben genannten E-Mail-Anbieter Sendinblue versendet, sondern dort auch für mindestens einen Monat gespeichert. Die Ergebnis-PDFs liegen außerdem alle in der Google-Cloud.

Durch Sendinblue können wir abschätzen, wie viele Testergebnisse betroffen sind:

Betreiber*inAnzahl Tests
corona-gurgeln.de~17.500
coronatest-rv.de~37.500
testcenter.berlin~26.000
rapidtestberlin.de~1.500

In den E-Mails standen dann auch die Links zu den Testergebnis-PDFs. Somit waren folgende Daten zugänglich:

  • Name
  • Geschlecht
  • Geburtsdatum
  • Adresse
  • E-Mail-Adresse
  • Telefon-Nummer
  • Testergebnis

Wozu noch ins Testzentrum?

coronatest-rv.de verschickt nach dem Test auch einen QR-Code. Dieser findet sich sowohl in der E-Mail mit dem Testergebnis als auch auf dem PDF und soll dann im Einzelhandel gescannt werden, um schnell zu überprüfen, dass ein negatives Ergebnis vorliegt.

Screenshot eines fingierten Online-Testergebnis

Diese URL aus dem QR-Code enthält eine Reihe von Parametern. Darin ist unter anderem vermerkt, wann der Test durchgeführt wurde, an welcher Teststation, das Ergebnis und der Name des Testlings. Diese Daten sind allerdings weder signiert, noch werden sie mit den ermittelten Testergebnisse abgeglichen.

Obwohl der Anbieter von diesem Problem weiß, hat er es bis heute nicht gefixt. Dadurch könnten wir uns selbst ein negatives Schnelltestergebnis generieren:

Halbherzige Reaktionen

Nachdem wir die Lücken entdeckt hatten, haben wir sie, wie üblich, fein säuberlich dokumentiert und dann dem CERT-Bund beim BSI und den Landesbeauftragten für Datenschutz und Informationsfreiheit in Baden-Württemberg und Berlin geschickt. Bei keinem der Testzentren war zu erfahren, wer diese Software entwickelt hat. Auch eine security.txt war nicht vorhanden. Deswegen konnten wir uns nicht direkt an die Softwareanbieterin wenden.

Zwei Tage nachdem wir die Reports versendet haben, wurde die Lücke geschlossen, zuerst nur halbherzig. Zwar wurden die API-Keys aus den abrufbaren Daten entfernt, allerdings wurden die kompromitierten Keys nicht widerrufen. Damit konnten alle, die die Keys bereits kannten, weiterhin auf die Daten zugreifen. Diese Zugangsdaten wurden erst einige Tage später deaktiviert, nachdem wir auch Sendinblue über die kompromitierten Keys informierten. Wir wissen nicht, ob die Betreiber*innen dies selber veranlasst haben oder ob die Keys aufgrund unseres Hinweises an Sendinblue deaktiviert wurden.

Fazit

Das Handeln der Testzentrenbetreibenden ist hier wieder extrem verantwortungslos. Wer Kund*innen-Daten verarbeitet oder speichert, muss dafür Sorge tragen, dass diese ausreichend geschützt sind. Das gilt ganz besonders bei Testzentren, die sensible Gesundheitsdaten verwalten.

Auch in der aktuellen Phase der Pandemie ist es wichtig, sich regelmäßig testen lassen zu können. Das muss möglich sein, ohne Angst zu haben, dass die eigenen Daten danach offen im Internet zugänglich sind.

Und so gilt, wie schon bei Flink: Wenn das Produkt marktreif genug ist, um Kund*innendaten zu speichern, muss es auch reif genug sein, diese für sich zu behalten.

Die schlechte Ausrede, dass die Software schnell entwickelt werden musste, zählt nach vielen Monaten Betrieb von Schnelltestzentren erst recht nicht mehr.

Selbst wenn es keine gravierenden Sicherheitslücken gäbe, muss man sich immer um Datenschutz kümmern. Das heißt zum Beispiel, Daten nicht länger abrufbar zu speichern als nötig, sie nicht mit Diensten zu teilen, die sie nicht brauchen und bei der Diensteauswahl darauf zu achten, dass dort die Daten DSGVO-konform gespeichert werden.

Der Landesbeauftragte für Datenschutz und Informationsfreiheit Baden-Württemberg hat vor wenigen Tagen eine Liste veröffentlicht, was Testzentren-Betreibende beachten müssen und kommentiert:

Wir müssen gerade in dieser Phase der Pandemie sorgsam mit den personenbezogenen Daten der Bürger_innen umgehen. Es darf keine ‚Nebenwirkung‘ von Corona-Tests sein, dass persönliche und sensible Daten von vielen Menschen irgendwo im Internet landen und für Dritte einsehbar sind.

Wir können uns dem nur anschließen und allen Betreibenden von Testzentren nochmal nahelegen, die vom LfDI BW genannten Punkte erneut zu überprüfen.

In diesem Fall kommt erschwerend hinzu, dass die als kompromittiert bekannten Zugangsdaten ganze drei Tage lang nicht ungültig gemacht wurden. Eigentlich ist das mit zwei Klicks über das Webinterface von Sendinblue möglich. Dass dies nicht schnellstmöglich passierte, bedeutet, dass die Betreiber*innen bewusst in Kauf nahmen, dass weitere Daten abgerufen und unter Umständen missbraucht werden.

Es ist eine absolute Frechheit, dass hier so sorglos mit solchen hochsensiblen Daten umgegangen wird. Wir hoffen, dass die Datenschutzbehörden hier ihre Möglichkeiten nutzen und empfindliche Bußgelder gegen die Unternehmen verhängen.

Disclosure Timeline

  • 2021-05-16: Wir bekommen Hinweis und finden nach kurzer Suche die Sendinblue-API-Keys
  • 2021-05-17: Reports werden an CERT-Bund und LfDIs versendet; LfDI BaWü kann Lücken nachstellen und leitet, soweit zuständig, die nötigen Maßnahmen in die Wege
  • 2021-05-19: API-Keys sind nicht mehr über Buchungsseite abrufbar
  • 2021-05-20: Wir bitten Sendinblue, die Keys zu widerrufen
  • 2021-05-21: Die API-Keys sind revoked

Wenn ihr zerforschung unterstützen wollt, findet ihr hier Möglichkeiten: https://zerforschung.org/unterstuetzen/