Datenleck: Kundendaten von eBay- und Amazon-Nutzern gelangen ins Netz

Es gibt mal wieder ein Datenleck, betroffen sind dieses Mal europäische Kunden von Amazon und eBay aber auch PayPal, Stripe und Shopify. Entstanden ist das Problem offenbar durch APIs für Bezahlungen und allgemeine Marketplace-Transaktionen. Die Daten waren für mehrere Tage lang ungesichert über die Amazon Web Services (AWS) abgreifbar.

Passiert ist der Fehler offenbar am 3. Februar 2020. Eine MongoDB-Datenbank war für ca. 5 Tage durch Suchmaschinen indexierbar. Enthalten gewesen sind Angaben zu den Liefer- und E-Mail-Adressen, Telefonnummern, gekauften Waren, Bezahlungen, Bestellnummern, Teile von Kreditkartendaten (die letzten vier Ziffern der Kartennummer) und im Falle von Stripe und Shopify auch Links zu den jeweiligen Rechnungen.

Ebenfalls mit von der Partie waren etwa MWS-Authentifizierungs-Tokens und auch eine AWS-Access-Key-ID. Auch Anfragen der Amazon Marketplace Web Services (MWS) waren auf diese Weise einsehbar. Offen ist nun, wie viele Kunden genau betroffen gewesen sind, da ein einzelner Kunde viele Einträge generieren kann. Klar ist, dass die Hälfte der durchgesickerten Kundendaten offenbar aus Großbritannien stammt und möglicherweise mehrere Millionen Kunden betroffen sind, verteilt über mehrere europäische Länder.

Als Ursache des Fehlers ist wohl ein Drittanbieter ausgemacht, der für die Analyse von Steuern verantwortlich ist, die grenzüberschreitend in Europa erhoben werden. Deswegen hat im Grunde keiner der Privatkunden mit diesem Anbieter zu tun, der nun verantwortlich zu sein scheint. Das Datenleck zeigt dabei anschaulich, dass bei einer Bestellung oder Zahlung online mittlerweile mehr als nur zwei Parteien involviert sind, was auch das Risiko erhöht, dass irgendwo in der Kette eine Schwachstelle entsteht.

Amazon reagierte offenbar schnell und schloss die Lücke sofort, nachdem das Unternehmen Kenntnis davon erlangte. Ob Kriminelle möglicherweise vorher Zugriff gewonnen und Daten gestohlen haben, ist unbekannt. Es gab eben für einige Tage die Möglichkeit, sodass man es nicht zu 100 % ausschließen kann.

Gefällt dir der Artikel? Dann teile ihn mit deinen Freunden.

André Westphal

Hauptberuflich hilfsbereiter Technik-, Games- und Serien-Geek. Nebenbei Doc in Medienpädagogik und Möchtegern-Schriftsteller. Hofft heimlich eines Tages als Ghostbuster sein Geld zu verdienen oder zumindest das erste Proton Pack der Welt zu testen. Mit geheimniskrämerischem Konto auch bei Facebook zu finden. PayPal-Kaffeespende an den Autor.

Neueste Beiträge

Mit dem Absenden eines Kommentars stimmst du unserer Datenschutzerklärung und der Speicherung von dir angegebener, personenbezogener Daten zu.

28 Kommentare

  1. Hoert sich danach an, als ob Avalara oder ein aehnlicher Anbieter der Verursacher ist. Mir erschliesst sich jedoch nicht, warum Amazon, Shopify, Stripe etc. im Artikel genannt werden, der Verursacher jedoch nicht.

  2. Wolfgang D. says:

    Das Übliche.
    Unsereiner wird mit lächerlichen immer neuen Passwortregeln und -wechseln zur Verzweiflung getrieben, während die Anbieter samt Diensten meine Daten schön überall verteilen. Damit mich auch der letzte Spammer und Phisher endlich persönlich ansprechen kann.

  3. Hm… Amazon reagierte also schnell und schloss das Leck? Und wie sieht es aus mit den Benachrichtigung der Betroffenen? Das wäre aus meiner Sicht von gleicher Priorität, wenn meine Kreditkartennummer da draussen unterwegs ist, dann muss ich die JETZT sperren, und nicht, wenn deren PR-Abteilung fertig ist mit dem weisswaschen der Lücke.

    • André Westphal says:

      Die komplette Nummer ist nicht durchgesickert, ein Teil der Nummer war aber erkennbar.

      • Bestimmte Teile einer einer Kreditkarten-Nr. sind für den gleichen Typ auch immer gleich sind.
        Daher ist die Rede von bestimmten Teilen völlig nichtssagend.
        Hoffen wir mal das wenigstens die CSV und Gültigkeitsdauer nicht in den Daten mit dabei waren.

        Darüber hinaus frage ich mch warum es immer neue Datenschutzgesetze gibt, die NICHTS bringen.
        Betroffene Personen müsten eine ordentliche ENtschädigung pro Kopf bekommen, damit die Firmen endlich einmal anfangen sorgfältig mit meinen Daten umzugehen.

        • André Westphal says:

          Habs konkretisiert im Beitrag, damit es deutlicher ist :-).

        • Auch das beste Gesetz kann nicht verhindern, dass Fehler passieren. Ich jedenfalls würde nicht annehmen, dass die Daten in diesem Fall vorsätzlich „offen“ waren.

          • Stop!

            Wenn man einen Fehler in seinem Deployment-Script hat, der dazu führt, dass bei einer MongoDB der Standardzugang nicht geschützt wird, wegen „In Zeile 7 fehlt ein Semikolon“, DAS ist ein Fehler, die passieren, da kann man nix sagen.

            Wenn man aber vorher die Entscheidung trifft, seine MongoDB überhaupt dem Internet auszusetzen, statt sie im Intranet hinter einem VPN mit zusätzlicher IP-Blockade zu platzieren — das ist kein „Fehler“. Das ist grobe, unfassbare Fahrlässigkeit.

            Das ist der geplante Vorsatz, sich auf eine völlige Fehlerfreiheit im Rest-Prozess zu verlassen.

            Das ist wie das Losfahren mit einem Auto ohne Bremsen, weil man auf der Karte gesehen hat, dass es von Flensburg nach München ja meistens bergauf geht. Wer dann Höhe Kasseler Berge mit 240 km/h in einen Tankwagen brettert, kann sich nicht mehr auf „Oh, Fehler, menschlich“ berufen.

            Hier gehört ein Manager weggesperrt.dafür, dass er einen ITler mit so einem Setup beauftragt hat.

            Hint: Andere Unternehmen machen das ordentlich und haben daher höhere Kosten. Wir müssen diese ganzen Wild-West-Setups mal in den Griff kriegen.

            • Nur weil etwas aus dem Internet erreichbar ist heißt es nicht automatisch, dass es im öffentlichen Netz steht.
              Die Mongo DB kann im internen Netz (VPC) stehen und über Loadbalancer öffentlichen verfügbar gemacht werden.
              Zumindest ist das ein Ansatz für AWS.

              Und auch da können Fehler passieren.
              Heutzutage nutzt man infrastructure as code um sowas zu deployen und da passieren die gleichen Fehler, wie in jedem anderen Script auch.

              Schnell nen Port aufgemacht und nicht geprüft ob die Mongo DB nur mit Authentifizierung erreichbar ist, passiert halt.

              Man muss die Mongo DB aus dem Internet erreichbar machen, wenn man sich mit anderen Firmen verbinden möchte. Schließlich lässt man ja die andere Firma nicht in sein eigenes Netz, um Daten auszutauschen.
              VPN zwischen zwei Stellen geht auch, aber hat auch vor und Nachteile.

              Es gibt sehr viele Möglichkeiten solche technischen Probleme zu lösen und jeder Ansatz hat vor und Nachteile.

              Es ist keine Frage ob, sondern wann etwas schief geht.
              Und hier wurde schnell informiert.
              Betroffene zu kontaktieren ist schwierig in solchen Fällen.
              Oft ist es sogar für die Techniker schwer abzuschätzen, wie viel und was abgerufen wurde.

              • > Nur weil etwas aus dem Internet erreichbar ist heißt es nicht automatisch,
                > dass es im öffentlichen Netz steht.
                Soweit klar. Es ist aber dem öffentlichen Netz gegenüber exponiert, und allein schon das ist für keine Datenbank akzeptabel, die über einen Blumenladen-Wordpress hinausgeht.

                > Die Mongo DB kann im internen Netz (VPC) stehen und über Loadbalancer
                > öffentlichen verfügbar gemacht werden.

                Und hier geht es dann los. „Kann“, ja, technisch klar. Darf aber unter keinen Umständen.

                > Zumindest ist das ein Ansatz für AWS.

                Und der Artikel zeigt genau das auf, warum das eben kein „erlaubter“ Ansatz ist. Vor eine Datenbank gehört „etwas davor“. Das kann ein VPN sein, oder wenn man einen Zugriff benötigt, dann SOAP/REST mit einer Filterung in der Implementation, oder oder oder. Es kommt halt immer drauf an, was man braucht. Authentifizierung allein ist kein Sicherheitskriterium. Die greift nicht bei Fehlern im Deployment, die greift nicht bei Sicherheitslücken, die kann keine Limits, die kann garnix ausser Nutzer zuordnen, dafür ist sie da.

                > Heutzutage nutzt man infrastructure as code um sowas zu
                > deployen und da passieren die gleichen Fehler, wie in jedem anderen Script auch.
                >
                > Schnell nen Port aufgemacht und nicht geprüft ob die Mongo DB nur
                > mit Authentifizierung erreichbar ist, passiert halt.

                1. Kritische Infrastruktur muss immer mindestens doppelt abgesichert werden. Genau deswegen, weil EIN Fehler passiert. Ein Fehler im Deployment, wie immer man das Kind auch nennt, darf nichts offenlegen.

                2. Kritische Infrastruktur muss immer durch automatisierte Tests abgesichert sein. So selbstverständlich wie man in der Erstellung der Software Unit-Tests verwendet, explorative Tests am Userinterface, Integrationstests an den Schnittstellen, so selbstverständlich sind auch automatisierte Penetrationstests auf die Systeme. Es gibt keine Rechtfertigung für einen unbemerkten MongoDB-Zugang, das ist in jedem Standard-Test enthalten.

                Ich meine, über was reden wir hier eigentlich? Das Netz ist eine kritische Infrastruktur, und Kundendaten sind höchst sensible Daten. Wer hier nicht doppelt und dreifach absichert, obwohl die Mechanismen dazu längst „best practice“ für jeden eShop für selbst gestrickte Mützen ist, dessen Problem liegt nicht in der Technik, sondern im Management. Das sind Basics, und die wurden weggespart. Ist uns zu teuer. Machen wir einfach nicht und sind dann billiger als der Wettbewerber, der es ordentlich macht. So läuft’s doch.

                Und deswegen muss sich der Gesetzgeber mal die Unternehmen so richtig zur Brust nehmen, die so einen SCHEISS online stellen.

        • Kleiner Tipp zur KK: SMS Benachrichtigung aktivieren. So wird man benachrichtigt wenn eine Buchung durchgeführt oder versucht wurde. So kann man umgehend reagieren.

      • Bartenwetzer says:

        Und warum steht das nicht gleich im Artikel? Muss man auch hier schon ständig bohren um vollständige Infos zu kriegen ?

        • ja, wirklich eine Frechheit… wir sollten da wirklich über eine Klage nachdenken, findest du nicht? zumindest einen Screenshot solltest du schon mal an deinen Anwalt schicken!

          ich hoffe, es ist klar, dass das hier Ironie ist…

  4. Gibt es irgendwo ne Seite wo man checken kann ob man selbst von dem Leck betroffen ist?

  5. tomasioBLITZ says:

    An alle Security Experten und auch an den Autoren: Gibt es noch Maßnahmen die man jetzt treffen sollte? zB Passwort ändern?

    • André Westphal says:

      Passwörter sind ja offenbar nicht durchgesickert, es ist auch überhaupt nicht klar, ob überhaupt ein Dritter auf die Daten zugegriffen hat. Eigentlich sollte man nur wie immer vorsichtig sein, falls entsprechende Scam- / Phishing-Mails eintrudeln. Sonst dürfte keine große Gefahr bestehen. Ist aber natürlich dennoch ärgerlich, auch wegen der E-Mail-Adressen.

    • Zwei-Faktor-Authentifizierung nutzen.

  6. Bezahlst du denn dafür? Veröffentliche doch deine eigenen Artikel, wenn du es soviel besser kannst. Dir werden bestimmt keine Fehler passieren.

  7. Dieser Scheiß nervt nur noch! Ich gehe wieder in den Einzelhandel in bezahle in Bar. Bei mir ist wieder Spam angesagt. Irgendwie sind die wieder an meine E-Mail Adresse gekommen. Warum soll ich mich weiter mit diesen Nervensägen rum machen? So macht Online keinen Spaß mehr. Das positive daran ich spare in nächster Zeit einen Haufen Euros. Das sollte jeder machen, damit unsere Politiker endlich was gegen Onlinebetrug unternehmen. Wenn keine Steuern mehr sprudeln müssen die etwas tun.

    • Mach ich auch. Online nur, wenn ich keine andere Wahl habe. Onlinebetrug hat viele Facetten, die meisten sind dabei wie der Enkeltrick. Vor 20 Jahren ausgedacht und funktioniert heute immer noch.

  8. Ich habe daraufhin unaufgefordert eine neue Visakarte mit dem Hinweis auf das Datenleck bekommen.
    Vorbildliche DKB-Bank!

  9. Heisenberg says:

    Erst MasterCard, dann PayPal, und jetzt eBay, und Amazon gleichzeitig?
    Da steckt doch Absicht dahinter!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Du willst nichts verpassen?
Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den Hauptfeed abonnieren. Alternativ könnt ihr euch via E-Mail über alle neuen Beiträge hier im Blog informieren lassen. Einfach eure E-Mail-Adresse hier eingeben, dann bekommt ihr 1x täglich morgens eine Zusammenstellung. Mit dem Absenden willigst du unserer Datenschutzerklärung und der Speicherung von dir angegebener, personenbezogener Daten zu.