Datenpannen melden, Abenteuer erleben

Ein Erfahrungsbericht

Am vergangenen Donnerstag meldete sich ein ehemaliger Student, Marvin Keller, bei mir, denn er hatte etwas Beunruhigendes entdeckt. Herr Keller hatte meine Lehrveranstaltungen im Pflicht- und Wahlbereich zu IT-Sicherheit und technischem Datenschutz besucht, später betreute ich seine Bachelorarbeit. Er ist mir gut in Erinnerung geblieben, ich hatte damals im Wahlmodul mit Studierenden diskutiert, wie man potentielle Sicherheitslücken entdeckt und an die Verantwortlichen meldet, wie weit man dabei technisch gehen sollte und was bei gefundenen Datenpannen zu tun ist. Fast alle Studierenden waren mit mir der Ansicht, dass Responsible Disclosure ein geeignetes Verfahren zur Offenlegung von Sicherheitslücken darstellt: Schwachstellen werden zuerst den Systemverantwortlichen bzw. Entwicklern gemeldet, erst nach einer angemessenen Frist zur Behebung wird etwas veröffentlicht. Das Einfordern eines Finderlohns oder der dreiste Vertrieb von Beratungsdienstleistungen verbietet sich bei seriösen Sicherheitsforschern. Responsible Disclosure bewahrt Dritte davor, Schaden zu nehmen. Umgekehrt heißt das, dass man den Tippgebern Dank und Respekt schuldet – und diese nicht drangsaliert oder gar mit einer Rache-Anzeige kriminalisiert.

Wer meldet, riskiert eine Anzeige

Leider gibt es immer wieder Vorfälle, bei denen auf den uneigennützigen Hinweis eine Anzeige folgt. Prominentes Beispiel war 2021 die Staatsanwaltschaft Berlin mit dem Verfahren gegen die Sicherheitsforscherin Lilith Wittmann, die Schwachstellen der Wahlkampf-App der CDU aufgezeigt hatte. Später entschuldigt sich die Partei für die Anzeige, eine gefühlte Unsicherheit verbleibt jedoch in solchen Fällen. Welcher Ärger droht mir für eine gute Tat? Was geschieht mit dem Überbringer der schlechten Nachricht? Sollte ich besser anonym anzeigen? Und genau darum ging es bei Herrn Keller: Er hatte eine Datenpanne entdeckt. Ein Unternehmen hatte einen Webshop-SQL-Dump (also eine vollständige Sicherung aller Kunden- und Transaktionsdaten) erzeugt und versehentlich öffentlich abrufbar abgelegt. Jeder konnte per Webbrowser und Eingabe einer Serveradresse auf die Datei zugreifen: Mehr als 8 GB Kundendaten! Nicht einmal ein Pfad oder Dateiname musste eingegeben werden, denn der Webserver half mit einem Directory-Index weiter.

Fehlerkultur

Mitteilungen von Sicherheitslücken sind für mich kein seltener Vorgang. Meist geschieht dies jedoch im Kontext von F&E-Projekten und Begutachtungen, dann erwartet der Adressat meine Meldung und freut sich gelegentlich sogar über die Identifizierung von neuen Schwachstellen, weil es um Prototypen geht, die noch keine sensiblen Daten verarbeiten und ohnehin verbessert werden sollen. In der IT-Sicherheits-Community herrscht generell eine professionelle Fehlerkultur und die Bereitschaft zu offener Diskussion. Strafanzeigen oder extreme emotionale Reaktionen sind mir im Austausch mit Fachkolleg*innen noch nicht begegnet. Aber auch bei bereits produktiven Systemen, bei denen ich etwas gegenüber leicht genervten Systemverantwortlichen aufzeige, betrifft es oft rein konzeptionelle Schwächen, die nicht direkt ausnutzbar sind oder es geht um einzelne Datensätze bzw. wenig sensible Daten.

Die Daten hatten es in sich!

Das Ausmaß dieser Datenpanne war jedoch enorm. Es handelte sich um einen 8,4 GB großen SQL-Dump mit über 50.000 Kundendaten (Namen, Adressen, E-Mail, Telefonnummern, Passwörter-Hashes) und Webshop-Verkaufstransaktionen. Eine so große Datenmenge könnten viele potentielle Datendiebe gar nicht herunterladen, die Bandbreite auf dem Land ist dafür unzureichend. Das betroffene Unternehmen ist spezialisiert auf Luxus-Uhren und Metallprodukte (Gold & Silber). Da hierbei private Adressen von Kunden, die Gegenstände von hohem Wert erworben haben, enthalten sind, bestand auch aus meiner Sicht akuter Handlungsbedarf. Wer Schwierigkeiten hat, das Ausmaß einzuschätzen: Stellen Sie sich vor, in einer beliebigen großen Stadt in Deutschland zu wohnen; wenn Sie dann einen Umkreis von einem Kilometer um Ihren Wohnort ziehen, dürfte mehr als eine Handvoll betroffene Kunden eingekreist sein. Und nun stellen Sie sich vor, Sie wären freiberuflich mit einem Brecheisen tätig.

 

Was macht man nun?

Die Sorge von Herrn Keller, inzwischen Masterstudent an einer anderen Hochschule, war berechtigt. Angesichts des Ausmaßes und der Sensibilität des Datenschatzes war mit einer unfreundlichen Reaktion zu rechnen. Er bat um Unterstützung. Ich schlug vor, die Meldung umgehend vorzunehmen, ihn als Entdecker namentlich zu benennen, aber mich als meldende Person anzugeben und meine private sowie dienstliche Anschrift zu verwenden. Die Meldung erfolgte dann gleichzeitig per E-Mail an die Datenschutzaufsichtsbehörden und an das Unternehmen. Ich genieße zwar keine Immunität, aber als Professor mit einschlägiger Fachrichtung und damit als quasi amtlicher Sicherheitsforscher kann ich hierbei etwas argloser auftreten als Studierende, die man vielleicht per Anzeige einzuschüchtern versuchen würde. So jedenfalls meine optimistische Hoffnung.

Meldung nach Art. 33

Am Freitag, um 07.53 Uhr, ging die Mitteilung von meiner Mailadresse raus an das Unternehmen selbst und nachrichtlich an die Behörde des Bayerischen Landesbeauftragten für den Datenschutz und auch die Österreichische Datenschutzbehörde in Wien, da hier jeweils betroffene Niederlassungen bestanden. Rechtlicher Hintergrund: Im Falle einer Verletzung des Schutzes personenbezogener Daten ist dies gemäß Art. 33 DSGVO unverzüglich der Aufsichtsbehörde zu melden.

Erste Reaktion kommt automatisch

Umgehend traf eine automatische Empfangsbestätigung ein: “Mitteilung ist in der Datenschutzbehörde eingelangt und wird einer Bearbeitung zugeführt.” Ja, die Meldung kam aus Wien; das Verb war bis dahin auch nicht in meinem aktiven Wortschatz. Aus Bayern gab es keine Rückmeldung. Da meine Mail mehrere Links und die gefährliche Zeichenkette “.SQL” enthielt (richtig! Spam-/Malwarefilter arbeiten mit solchen simplen Ansätzen, auch wenn sie mit Sandboxing-Magie werben), fürchtete ich, dass sie leicht als Spam oder Phishingmail ausgefiltert werden könnte. Ich rief daher gegen 09.30 Uhr die bayerische Behörde an, um mir den Eingang vorsorglich bestätigen zu lassen. Leider war nur eine Ansage zu hören, die mutmaßlich auf ein preisgünstiges Mikrofon und einen niederbayerischen Dialekt hindeutete. Kernaussage war wohl, dass man später erneut anrufen sollte. Das wiederholte sich später mit gleichem Ergebnis.

Zuständigkeit beachten

Ich schrieb dann eine zweite kurze Mail nach Bayern ohne URLs und fragte, ob die erste Mail empfangen wurde oder gerade Betriebsferien sind; das triggerte eine umgehende Antwort: Man habe erstens keine Betriebsferien und sei zweitens nicht zuständig. Oh je! Das stimmt. In Bayern ist der Landesbeauftragte für den Datenschutz in der Aufsichtszuständigkeit auf bayerische öffentliche – insbesondere staatliche und kommunale – Stellen beschränkt. Beim betroffenen Unternehmen handelt es sich jedoch um eine nicht-öffentliche Stelle. Zuständig für die datenschutzrechtliche Aufsicht über nicht-öffentliche Stellen mit Sitz in Bayern ist das Bayerische Landesamt für Datenschutzaufsicht. Eine Freistaat-Besonderheit. Das habe ich sogar mal gewusst, aber im Eifer des Gefechtes vergessen. Die Meldung ging dann um 10.55 Uhr an die zuständige Stelle raus, von der ich dann aber auch nichts mehr hörte, aber gut: Es war schon fast Freitagmittag.

Daten weiter ungeschützt im Netz

Ärgerlicher als meine lösbaren Schwierigkeiten mit bayerischen Zuständigkeiten und Dialekten (ich bin nördlich des Mains aufgewachsen), war allerdings die Tatsache, dass es vom Unternehmen keine Reaktion gab und auch die Daten weiterhin öffentlich abrufbar blieben. Unsere Mühen sollten sich doch wenigstens lohnen und etwas Gutes bewirken! Hatten sie die Mail nicht bekommen? Um 12.22 Uhr öffnete ich ein Ticket im Kundenportal des Unternehmens und übermittelte eine Kopie des Mailtextes. Zu meiner Überraschung wurde das Ticket umgehend bearbeitet und um 12.47 Uhr als ‘gelöst’ markiert. Die Daten waren jedoch noch immer im Netz! Das empfand ich schon als etwas dreist, aber nun ja: Wir kennen uns mit Ticketsystemen und ihren Unzulänglichkeiten aus. Vielleicht war ‘gelöst’ ja auch der verklausulierte Hinweis, dass man es an die IT und die Chefin gemeldet hat, dann wird wohl bald etwas passieren. Und wie schwierig kann es denn sein, eine große Datei zu löschen?!

Achja, das Ticketsystem. Man geht ja als Sicherheitsforscher mit offenen Augen durch die Welt. Mir fiel dann gleich auf, dass der Webserver dieses Systems kein TLS-Zertifikat aufweist und die Daten unverschlüsselt per http überträgt, zudem war die Ticketnummer prominenter letzter Teil der URL, was mindestens nachdenklich macht. Aber angesichts der Tatsache, dass das Unternehmen ohnehin die gesamte Kundendatenbank ungeschützt ins Netz stellt, erschien mir dieses Detail dann doch vernachlässigbar und ich ließ es auf sich beruhen.

Am Ende des Arbeitstages … – noch immer nichts passiert

Da es ein normaler Arbeitstag war, konnte ich erst abends wieder auf den Vorgang zurückkommen. Die Daten waren nach 18 Uhr noch immer nicht entfernt! Ich schrieb dann eine weitere Mail kurz vor 19 Uhr an den aktualisierten Verteiler (ja: Datenschutzaufsicht, nicht Landesbeauftragter für den Datenschutz; Unternehmen; Wiener Behörde) und wies auf den Status quo und das unfreundlich geschlossene Ticket hin – und erläuterte den Begriff “akuter Handlungsbedarf” für eine nichttechnische Zielgruppe. Herr Keller hatte noch eine gute Idee und machte sich die Mühe, persönliche Mailadressen der Leitungsebene zu ermitteln bzw. mit mir gemeinsam zu erraten, die ich dann auch noch anschrieb, damit der Text nicht nur an mail@… geht und im Supportpostfach versandet. Um 19.52 Uhr schrieb ich drei Personen an, die wohl das C-Level bilden. Alle Adressen existierten.

Erste Antwort kurz vor 23h

Um 22.52 Uhr gab es dann doch noch eine erste Reaktion. Eine Mail des E-Commerce-Leiters des Unternehmen bestätigte die Meldung und vermeldete: “das Datenleck wurde behoben” – ca. 15 Stunden, nachdem wir die Meldung erstellten. Meine erste Mail sei irrtümlich von einer Beschäftigten (!) als Spam angesehen worden; die Belegschaft würde dazu noch geschult werden. Eine gute Idee, finde ich, falls wieder einmal die gesamte Kundendatenbank publiziert wird und dann eine Hinweis-Mail kommt. Dankesworte waren nicht enthalten, aber immerhin wurde auch nicht mit einer Anzeige gedroht. Man freut sich auch über Kleinigkeiten.

Dank am Morgen und Fragenkatalog

Am gestrigen Samstagmorgen, dem Folgetag, kam dann eine weitere Mail, offenbar wurden zwischenzeitlich Aktivitäten entfaltet. Diesmal war knapper Dank enthalten, verbunden mit weniger knapper Inquisition:

^{wir danken für die Aufdeckung der Datenpanne. Wir bitten um Beantwortung folgender Fragen, damit wir die richtigen Schritte in Zusammenarbeit mit den Behörden setzen können:
Haben Sie die Daten noch gespeichert?
Wann wurde die Datenpanne genau entdeckt?
Wie wurde die Datenpanne entdeckt?
Hatten weitere Personen Einsicht in die Daten aus ihrem Umfeld?
Welche Daten haben Sie ausgewertet?
Vielen Dank für die Zusammenarbeit.}

Die interne Aufarbeitung ist wohl abgeschlossen, nun erfolgt die Befragung des Überbringers. Die Fragen erscheinen teilweise berechtigt, wobei “wann & wie” schon in der Meldung adressiert wurde. Eine Beantwortung erübrigt sich aber ohnehin, denn die anfragende Person ist gemäß Impressum nicht vertretungsberechtigt für das Unternehmen, und, sorry … – da könnte ja jeder kommen. Priorität sollte ohnehin die Benachrichtigung der Betroffenen und die Stellungnahme gegenüber den Aufsichtsbehörden haben. Gegenüber letzteren würde ich mich auch äußern. Aus Bayern (Datenschutzaufsicht) habe ich aber noch nichts gehört, nicht mal eine automatische Eingangsbestätigung …

Die Daten wurden übrigens tatsächlich entfernt.