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!

Brechstange, Lizenz: CC0

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

goldene Uhr, Lizenz: CC0 MoMA

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

goldene Uhr, Lizenz: CC0 MoMA

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.

”The purpose of computing is insight, not numbers.” (Richard Hamming) Ulrich Greveler studierte in Gießen Mathematik und Informatik, arbeitete sechs Jahre in der Industrie im In- und Ausland, bevor er als Wissenschaftler an die Ruhr-Universität nach Bochum wechselte. Seit 2006 lehrt er Informatik mit dem Schwerpunkt IT-Sicherheit an der Fachhochschule Münster (bis 03/2012) und der Hochschule Rhein-Waal (seit 03/2012). Sein besonderes Interesse gilt datenschutzfördernden Technologien und dem Spannungsverhältnis zwischen Privatsphäre und digitaler Vernetzung.

7 Kommentare

  1. Ich rief daher gegen 09.30 Uhr die bayerische Behörde an

    Gelesen und gelacht.
    Mehrere Jahre war ich selber Teil einer Behörde mit wenig Publikumsverkehr. Wenn einmal zwischen 9:00 und 10:00 ein Bürger im Amt aufschlug habe ich den zuständigen Kollegen aus der Kantine geholt. Weil so gegen 9:00 fand die große Zusammenrottung statt und dann ging es zum Frühstück in die Kantine. Privat und früher auch dienstlich verkehre ich mit Behörden nur schriftlich. Wenn man telefonisch etwas geregelt hat, muss man sich darüber eine Notiz machen um den Überblick zu behalten, da kann ich es auch gleich schreiben.
    Nicht zuständig ist mit die dümmste Ausrede. Wenn man etwas auf den Schreibtisch bekommt für das man nicht zuständig ist, dann gibt man das an die zuständige Behörde ab und dem Bürger eine Abgabenachricht. So dürfte das in den meisten ADAs, Allgemeine Dienstanweisung, geregelt sein.
    Irgendwann bekamen wir Netzwerkdrucker. Das Paßwort aus der Bedienungsanleitung wurde natürlich nicht geändert. Wer sich um 11:00 eine Datei mit Namen sudoko Rätsel ausdrucken läßt, der kann seinem Chef auch gleich sagen nichts zu tun zu haben.
    Wenn mir eine Absurdität aus einer Behörde berichtet wird, dann glaub ich die erst mal.

  2. Sie „macht(t)en“ eine Erfahrung, die in allen Bereichen digitalisierter Datenerfassung mittlerweile „Standard“ ist. Vermeintlich geschützte Daten sind es genauso lange, bis diese ungeschützt sind. Bedeutet in Analogie: Sie sind lebendig, bis Sie tot sind. Sie sind solange gesund, bis Sie krank sind. Fazit: Es gab und gibt keine Datensicherheit! (Ohne das hier komplexer auszuführen)
    Ihr Hinweis auf ein „Datenleck“ ist gemäß Meldestruktur sprich automatisierter, verschachtelter Maschinenantwort und im weiteren Verlauf durch Inkompetenz einer fremdbestimmt Arbeitenden nicht ernst genommen worden. „Willkommen“ in der Wirklichkeit. Hier waren es „nur sensible“ Kundendaten. Nach gleichem Muster stehen die Räder still bzw. fliegen Flugzeuge nicht, weil Softwarefehler teils erst nach Tagen behoben werden (können) oder ertranken Menschen in Deutschland (siehe Ahrtal) usw. und sofort.

  3. Bihli
    24.04.2022, 13:17 Uhr

    Um unfreundlichen Reaktionen zu vermeiden, könnte man das auch anonym an https://www.heise.de/investigativ/ melden. Oder hätte das andere Nachteile?

    Wir wissen doch, wie empfindlich man reagiert, wenn die Presse eingeschaltet wird. Die “vierte Gewalt” ist immer nur dann wichtig, wenn es in die eigene Sache passt. Sonst ist sie meist banal, lästig oder aufdringlich. Dem stimme ich sogar zu. Die Erfahrungen haben es hinreichend bewiesen: Die vierte Gewalt wird praktisch nur noch missbraucht für Manipulation und “Unter”haltung.

    Das Zuständigkeitsproblem ist allerdings auch absurd. Behörden haben die Pflicht, Vorfälle an die jeweilig zuständige Stelle/Behörde weiter zu leiten. Die vertikalen Sackgassen dürfen gar nicht existieren. Oder bin ich da zu naiv?

    Übrigens: meine Bank-App auf dem Handy zur Identifizierung funktioniert auch, wenn die Simkarte aus dem Handy genommen wird. Wenn ich mich richtig erinnere, geht das auch nach dem Neustart des Handysystems. Ich meine, so sollte das nicht sein. Ein Sicherheitsfaktor ist somit schon mal ausgefallen. Dabei müsste das nicht sein.
    Dazu frage ich mich, warum solche Autentifizierungssysteme mit Prepaid-Cards funktionieren, die vor der Registrierungspflicht der Prepaid-Karten ausgegeben wurden. Das mag nicht so relevant sein und der Aufwand zur Prüfung auf solche Details ist wohl zu aufwändig, oder? Letztlich ist die Nutzung der Apps an die Telefonnummer geknüpft und mit dem Kunden vereinbart. Vertraglich wäre der Bank kein Vorwurf zu machen, wenn die Prepay-Karte missbraucht wird, weil in der Aufsichtspflicht des Kunden gelegen.

    • Übrigens: meine Bank-App auf dem Handy zur Identifizierung funktioniert auch, wenn die Simkarte aus dem Handy genommen wird. Wenn ich mich richtig erinnere, geht das auch nach dem Neustart des Handysystems. Ich meine, so sollte das nicht sein. Ein Sicherheitsfaktor ist somit schon mal ausgefallen. Dabei müsste das nicht sein.

      Sicherheit, wie sie die IT i.p. Authentifizierungsverfahren bereit stellt, kann sozusagen beliebig gehärtet werden.
      Oft ist dies gut, allerdings gilt es Sicherheit mit Funktionalität und Kunden- und letztlich auch Unternehmensnutzen miteinander aufzuwägen.

  4. Kenne persönlich (‘unverschlüsselt per http überträgt, zudem war die Ticketnummer prominenter letzter Teil der URL’ – SQL und so, Rechtesystem) ähnliche Fälle.
    Ein Angebot i.p. Beratung wird dann abgelehnt, macht auch nichts, relationale Datenhaltung inklusive Rechtesystem schwierig.
    Mit freundlichen Grüßen
    Dr. Webbaer

  5. Daten auf dem Handy
    Grundsätzlich gibt es drei Möglichkeiten, Daten auf dem Handy zu speichern.
    1. auf der SIM-Karte
    2. auf dem internen Speicher des Handys
    3. auf beidem
    Wer ganz sicher gehen will vor Datenklau, der sollte für Privatzwecke ein anderes Handy benutzen als im öffentlichen Verkehr.

Schreibe einen Kommentar