mod%log

Am 29. Juni 2020 hat unser Kollege Joël Gunzenreiner eine Schwachstelle in der Web-Applikation forAtable entdeckt. Die App dient der Erfassung von Kontaktdaten von Veranstaltungs- und Restaurantgästen, um mögliche COVID-19-Infektionsketten nachverfolgen zu können. Durch die Ausnutzung dieser Schwachstelle war es möglich, sämtliche über die Gäste erfassten Daten auszulesen.

Erster Akt: Die Regeln

Am 06. Juni 2020 wurden in der Schweiz die Corona-Einschränkungen weitreichend gelockert, und am 22. Juni 2020 fast vollständig aufgehoben. Der Schweizer Bundesrat hat in Folge diverse Maßnahmen zur weiteren Eindämmung von Covid-19 erlassen.

Eine dieser sog. "Massnahmen betreffend öffentlich zugängliche Einrichtungen, Betriebe und öffentlichen Veranstaltungen", schreibt vor, dass bestimmte Vorgaben umgesetzt werden müssen, um die Hygiene- und Abstandsregeln einzuhalten. Beispielsweise müssen gemäss Artikel 5 der Corona-Verordnung des Schweizer Bundesrates die Kontaktdaten der Besucher*innen von Restaurants oder Veranstaltern erhoben werden. In einem vom Branchenverband der Schweizer Gastronomie GastroSuisse in Zusammenarbeit mit mehreren Bundesämtern veröffentlichten Schutzkonzept wurden Möglichkeiten der Erhebung sowie die zu erhebenden Daten festgelegt:

Kontaktdaten können insbesondere über Reservations- oder Mitgliedersysteme oder mittels Kontaktformular erhoben werden. Es sind folgende Daten zu erheben:

1. Name, Vorname, Wohnort, Telefonnummer und Tischnummer
2. in Gästebereichen von Restaurationsbetrieben einschliesslich Bar- und Clubbetrieben, in denen die Konsumation stehend erfolgt, sowie in Diskotheken und Tanzlokalen: die Ankunfts- und Weggangszeit;
3. bei Veranstaltungen ohne Sitzplätze mit mehr als 300 Personen: der Sektor, in dem sich die Person aufhalten wird.

(Auszug aus GastroSuisse Schutzkonzept Kapitel 9)

Das Schutzkonzept schreibt weiter vor, dass Betreiber*innen und Organisator*innen die Vertraulichkeit der Daten während der Aufbewahrung sicherstellen müssen. Eine Nutzung der Datensätze zu einem anderen als dem vorgesehenen Zweck ist dabei ebenso vorgeschrieben wie die Löschung der Datensätze nach 14 Tagen.

Zweiter Akt: Lösungen

In den meisten Gaststätten finden Gäste dieser Tage oft einen kleinen Zettel mit einem Stift auf dem Tisch vor. Auf diesem Zettel vermerken die Gäste ihre geforderten persönlichen Daten und ggf. weitere Angaben zur Person.

Der Zettel verschwindet dann im Backoffice des Betriebs und wartet auf den Schredder oder die Behörde. Dies scheint datenschutztechnisch die derzeit schmerzärmste Variante zu sein, da zum einem eine Contact-Tracing-App auf einem Smartphone in einem Restaurant teilweise nur bedingt hilft, und zum anderen jede*r Besucher*in vor dem Einlass zur Handy-Kontrolle antreten müsste.

Zettel und Stift? Es dauerte nicht lang, bis dieser Umstand als Weckruf die Kanäle der Online-Tischreservierungs-Branche erreichte. Letztere produzierte hektisch eine Online-Version der "Zettel und Stift"-Variante: Das Züricher Startup LunchGate bastelte noch schnell eine Corona-Tracing-Funktion in ihre Tischreservierungs-Web-Applikation, und war im Geschäft.

Die Erfassung der erforderlichen Daten erfolgt über ein entsprechendes Formular der forAtable-Web-Applikation. Dies kann über das Scannen eines QR-Codes mit dem Smartphone oder durch die direkte Eingabe der URL geschehen. Auf dem Smartphone des Gastes präsentiert sich das Formular wie in Abbildung 1 links:

Nach der Eingabe der Daten (Vorname, Nachname und Telefonnummer) und dem Akzeptieren der Covid-19-Datenschutzerklärung, die man natürlich vorher gelesen hat, können die Daten an den Server von LunchGate geschickt werden. Der Gast bekommt anschließend auf einer Bestätigungsseite die eingetragenen Daten vorsichtshalber nochmals angezeigt - wie in Abbildung 1 rechts ersichtlich, ergänzt mit einer genauen Uhrzeit des Check-ins.

Herr Meier freut sich darüber, sich progressiv wie lange nicht mehr verhalten zu haben, und wartet auf sein Cordon Bleu.

Dritter Akt: Die Vollkontakt-Datenspeicherung und die Hacker

Nachdem unser Kollege Joël während eines Bar-Besuchs diesen Prozess abgeschlossen hatte, wollte er es dann doch ein bisschen genauer wissen. Glücklicherweise hatte er sich die URL der Bestätigungsseite notiert, um den ganzen Prozess nochmal am Schreibtisch genauer unter die Lupe zu nehmen; so wie es jeder andere interessierte Hacker des Planeten auch getan hätte.

In der URL der Bestätigungsseite ist eine ID enthalten, die für den erstellten Datensatz generiert wurde. Jeder Besuch einer Person generiert eine solche ID und einen dazugehörigen Datensatz. Onkel Kevin hat also eine eindeutige ID für jeden seiner Restaurantbesuche. So auch Joël. Und alle anderen Gäste, die das System von LunchGate nutzen. LunchGate verwendet die ID, um die Daten zu einem Besuch auf der Bestätigungsseite anzuzeigen.

Wenn man nun eins und 174395 zusammenzählt, erkennt man als Hacker mit einschlägigen Erfahrungen im Bereich der Addition natürlicher Zahlen, dass dem Algorithmus zur Generierung eindeutiger IDs möglicherweise eine sehr einfache Funktion zugrunde liegt. Probieren wir es doch einfach mal aus, verkleinern die ID und setzen sie also von beispielsweise 174396 auf 174394. Wenig überraschend: es erscheint ein anderer Datensatz.

In der Web-Applikation ist es also möglich, alle erfassten Eingaben von allen Gästen abzurufen - und das als unberechtigter, anonymer Benutzer.

Die Covid-19-Verordnung des Schweizerischen Bundesrates legt fest, dass man die erhobenen Daten zu keinen anderen Zwecken als der Bekämpfung der Covid-19-Epidemie verwenden darf. Tatsächlich sind aber sämtliche Daten ungeschützt im Internet zugänglich: Name, Telefonnummer, Besuchszeit und teilweise die kompletten Adresse. Damit dürften sie weiteren Zwecken unterlegen sein.

Moment, es gibt doch noch eine andere Regel: die Daten müssen nach 14 Tagen gelöscht werden. Subtrahieren wir ein paar weitere Werte und schauen uns den Datensatz mit der ID 87657 an:

Die obenstehende Abfrage ist vom 02.07.2020. Zu sehen sind aber die Daten eines Restaurantbesuchs vom 12. Juni 2020. Das bedeutet, dass die angezeigten Daten 21 Tagen vor dieser Abfrage erhoben und gespeichert worden sind.

Die vorgeschriebene Datenhaltung von 14 Tagen wurde also weit überschritten.

"Warum ist das ein Problem?" fragt Herr Meier vielleicht.

Im Gegensatz zur Datensatz-ID der Firma LunchGate ist eine Telefonnummer eine weltweit einmalige, eindeutig einer Person zuzuordnende ID. Die Web-Applikation erlaubt es, eine Zuordnung von Namen zu einer Telefonnummer einzusehen. Lädt man sich die komplette Covid-19-Contact-Tracing-Datenbank herunter und korreliert sämtliche Datensätze, lassen sich über einen längeren Zeitraum möglicherweise Bewegungsprofile ganzer Gruppen erstellen.

Insbesondere im Kontext der Covid-19-Epidemie lädt dies regelrecht zu Social-Engineering-Angriffen auf Gaststättenbesucher*innen ein: Kriminelle wissen genau, wann eine Person wo war, sie haben die Telefonnummer und die Namen der Personen - mehr braucht es nicht, um potentiellen Opfern per Anruf unkluge Handlungen plausibel erscheinen zu lassen. Denn genau so funktioniert Social Engineering. Enkeltrick reloaded.

Natürlich erlaubt eine solche Rendezvous-Datenbank noch ganz andere Schlüsse, wenn man die Daten in ihrer Gesamtheit nur entsprechend sortiert und durchsuchbar gestaltet. Dass an den Daten Interesse besteht, hat die Deutsche Polizei in Hamburg schon gezeigt.

Vierter Akt: Probleme sind dazu da, gelöst zu werden

Die oben beschriebene Schwachstelle ist eine sog. IDOR-Schwachstelle (Insecure Direct Object Reference), eine (unsichere) direkte Referenz auf einen Datensatz - in diesem Fall über eine URL.

Angreifer können durch unautorisierte Referenzen auf sensible Informationen zugreifen. Das ist in diesem konkreten Fall besonders trivial, da die einmaligen IDs, die als Referenz dienen, sehr kleine Zahlen sind, die zudem fortlaufend erzeugt werden. Somit sind sie leicht zu erraten und begünstigen Missbrauch enorm. Kennt ein Angreifer irgendeine valide ID, kann er weitere gültige IDs schnell erraten. Eine Schwachstelle wie diese kann auftreten, wenn eine schlechte/schwache Zugriffskontroll-Implementierung oder gar keine vorhanden ist.

Was können die Betreiber dieser Covid-19-Tracing-Datenbank also konkret anstellen, um diese Probleme in den Griff zu bekommen?

1. Wenn Daten nur geschrieben werden sollen, warum kann man sie dann lesen?
   1. Berechtigungskonzepte erstellen (vor der Entwicklung): Gaststätten müssen eine Liste eines bestimmten Zeitraums lesen dürfen, um diese auf Anfrage an die Gesundheits-Behörden weitergeben zu können. Eine Gaststätte darf nur die Datensätze der eigenen Besucher*innen lesen dürfen.
   2. Authentifizierungskonzepte erstellen (vor der Entwicklung): Organisationen, Benutzer und Rollen müssen sich mit angemessen sicheren Konzepten gegenüber der Anwendung legitimieren, bevor sie auf Datensätze zugreifen dürfen.
   3. Eine "Bestätigungsseite" benötigt unmittelbar nach der Registrierung keinen Datenbankzugriff über eine Web-API auf den eigenen Datensatz.
2. Ausschließlich notwendige Daten erheben: Wozu wird ein Realname benötigt, wenn es eine eindeutige und einzigartige ID (Telefonnummer) gibt?
3. Unique IDs, die als PII gelten, also Personen identifizieren, dürfen nicht erratbar sein. Sie sollten üblicherweise zufällig generiert werden und nicht vorhersagbar sein, wie beispielsweise UUIDs.

Das Problem der fehlenden Löschung lässt sich noch viel einfacher lösen:

1. Daten automatisch nach 14 Tagen löschen,
2. Backups dieser Daten automatisch nach 14 Tagen löschen,
3. keine Backups dieser Daten anfertigen.

Alternativ können Gaststätten auch einfach (wieder) zum Papier greifen. Vorausgesetzt, jeder Tisch bekommt seinen eigenen Zettel, und keine zu ergänzende Liste. Diese Zettel werden am Ende eines Tages in ein grosses Couvert gesteckt. Auf das Couvert wird das Datum geschrieben, an dem es vernichtet werden soll, also in 14 Tagen. Anschließend wandert es in die Kiste mit allen anderen Couverts. Und noch bevor ein Mitarbeiter des Restaurants morgens das Kühlaggregat der Zapfanlage in Betrieb nimmt, wirft er alle Couverts mit dem aktuellen Datum in den Schredder.

Ein systematisches Problem müssen die Firmen und Anbieter solcher Lösungen allerdings selber in den Griff bekommen: Behandelt eure Benutzer*innen nicht wie Beta-Tester. Veröffentlicht doch bitte eure Produkte erst dann, wenn alle notwendigen Funktionen, Datenschutz- und Sicherheitsrichtlinien implementiert sind. Danke.

Fünfter Akt: Behauptungen sind dazu da, belegt zu werden

Wir haben einen Screencast angefertigt, um den oben beschriebenen Flow zu dokumentieren und unsere Aussagen zu belegen:

Um die Machbarkeit eines Datendiebstahls zu demonstrieren, hat modzero ein Pythonscript geschrieben, dass die Enumerierung von beliebigen Datensatz-IDs demonstriert. Dieses Script werden wir auf GitHub veröffentlichen sobald LunchGate die Sicherheitslücke geschlossen hat.

Für diesen. Artikel haben wir die abgefragten Datensätze aus Datenschutzgründen auf selbst erstellte Fake-Datensätze beschränkt:

Am Abend des 03. Juli 2020 erreichte uns eine E-Mail eines Managing Partner der LunchGate AG. In der E-Mail wurde uns mitgeteilt, dass die IDOR-Schwachstellen behoben seien. Zur 14-Tage Löschfrist hiess es, hier bestünden keine Probleme.