Erfahrungen beim Hacken einer Dating-App – und der falsche Umgang mit Sicherheitsforschern

 (alexschapiro.com)
2 Punkte von GN⁺ 2025-05-13 | 1 Kommentare | Auf WhatsApp teilen
  • Bei der Dating-App Cerca führte die Kombination aus telefonnummernbasiertem Login und einer offengelegten API zu einem gefährlichen Zustand: Der OTP-Antwort war der Authentifizierungscode beigefügt, was bis zum Abruf personenbezogener Daten führen konnte
  • Unter api.cercadating.com wurden mit angehängtem App-Versions-Header die Endpunkte über openapi.json unter /docs sichtbar; einige Requests konnten sogar Business-Logik wie das erzwungene Matchen manipulieren
  • user/{user_id} lieferte allein mit einer gültigen Benutzer-ID PII wie Name, Standort, Geburtsdatum, Hochschule, Telefonnummer, E-Mail und Profilstatus zurück, was in Kombination mit der OTP-Schwachstelle zur Kontoübernahme führen konnte
  • Nach dem Kontozugriff waren für Nutzer mit eingereichten Dokumenten sogar Pass- oder Ausweisdaten, Selfie-URLs und private Nachrichten zugänglich; ein Verifikationsskript fand 6.117 Nutzer, 207 Nutzer mit hinterlegten Ausweisdaten und 19 als Yale-Studierende markierte Nutzer
  • Die Schwachstelle wurde Cerca am 23. Februar 2025 gemeldet und am 24. Februar auch telefonisch besprochen, doch bis zur Veröffentlichung am 21. April gab es keine weiteren Antworten und keine Benachrichtigung der Nutzer; nur der Patch-Status wurde unabhängig verifiziert

Abgebrochene Reaktion nach der Meldung

  • Die Dating-App Cerca hatte eine Sicherheitslücke in einer Dating-App, durch die private Nachrichten, Passdaten, sexuelle Präferenzen und weitere personenbezogene Daten offengelegt werden konnten
  • Nach Entdeckung der Schwachstelle wurde das Cerca-Team am 23. Februar 2025 per E-Mail informiert; in einem Videogespräch am nächsten Tag wurden Schwachstelle, Gegenmaßnahmen und weitere Schritte besprochen
  • Das Cerca-Team erkannte die Schwere des Problems an, bedankte sich für die verantwortungsvolle Offenlegung und versprach, die Schwachstelle zu beheben und betroffene Nutzer zu benachrichtigen
  • Danach wurde am 5. März und 13. März um Updates zum Fix und zum Benachrichtigungsplan für Nutzer gebeten, doch bis zur Veröffentlichung am 21. April 2025 erfolgte keine Antwort
  • Vor der Veröffentlichung wurde unabhängig bestätigt, dass die Schwachstelle gepatcht worden war; darauf basierte die Veröffentlichung

Kontozugriff begann beim OTP-Login

  • Die App nutzte ausschließlich einen OTP-basierten Login, bei dem ein Code an die Telefonnummer gesendet wird
  • Um die Netzwerkanfragen zu prüfen, wurden auf der iPhone-App mit Charles Proxy die App-Requests abgefangen
  • In der Antwort, die das OTP auslöste, war das Einmalpasswort direkt enthalten
  • In dieser Struktur war der Zugriff auf das betreffende Konto möglich, wenn nur die Telefonnummer des Nutzers bekannt war
  • Weil dafür ein separater Weg nötig war, an Telefonnummern von Kontoinhabern zu gelangen, wurde anschließend die API auf Endpunkte untersucht

Endpunkte wurden durch die OpenAPI-Dokumentation sichtbar

  • Für api.cercadating.com wurden mit einem Directory Fuzzer Pfade enumeriert
  • Ohne appbezogene Header war kein Teil der Website erreichbar
  • Als mit Gobuster Requests mit diesem Header gesendet wurden, wurde der Endpunkt /docs gefunden, der openapi.json bereitstellte
  • Mit der Match-and-Replace-Funktion von Burp Suite wurde eingestellt, den App-Versions-Header und das aus Charles Proxy extrahierte Bearer-Token immer anzuhängen
  • Einige ungeschützte Endpunkte beeinflussten die Business-Logik; so waren sogar Requests möglich, die zwei Personen zwangsweise matchten

Offenlegung von Nutzerprofilen und personenbezogenen Daten

  • Der Endpunkt user/{user_id} gab bei einer gültigen Benutzer-ID verschiedenste personenbezogene Daten zurück
  • Die Antwort enthielt unter anderem folgende Informationen
    • Name, Geschlecht, bevorzugtes Geschlecht, Stadt, Breitengrad und Längengrad
    • Hochschul-E-Mail und Verifizierungsstatus, Branche, Beruf, Geburtsdatum, Körpergröße
    • Hochschul-ID und Hochschulname, Status der Profilvervollständigung
    • Status der National-ID-Verifizierung sowie Mobil- und E-Mail-Verifizierung
    • Premium-Status, Kontoaktivität, Sperr- und Onboarding-Status
    • Telefonnummer, E-Mail, Benutzer-ID, verbleibende Anzahl von Suchen
    • Profilbilder, Match-Präferenzen, Nutzer-Prompts, gegenseitige Kontaktdaten, Erstellungs- und Änderungszeitpunkt, Alter usw.
  • Mit einem Python-Skript konnten gültige Benutzer-IDs gefunden und Nutzerdaten in großem Umfang enumeriert werden
  • Die zurückgegebenen Telefonnummern konnten zusammen mit der OTP-Schwachstelle für den vollständigen Kontozugriff genutzt werden
  • Personenbezogene Daten der Nutzer waren also selbst ohne OTP-Login offengelegt

Zugriff bis hin zu Ausweisdokumenten und privaten Nachrichten

  • Das Feld national_id_verified zeigte, dass Pass- oder Ausweisdaten im System gespeichert wurden
  • Antworten im Zusammenhang mit Ausweisdokumenten enthielten folgende Informationen
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • Status, ID, Benutzer-ID
  • Diese Informationen wurden nur eingeloggten Nutzern bereitgestellt, doch wegen der OTP-Schwachstelle war ein Login als beliebiger Nutzer möglich
  • Für Nutzer mit eingereichten Dokumenten war die Struktur so, dass die ID-Daten jeder beliebigen Person eingesehen werden konnten; nach eigenen Angaben wurde das jedoch nicht tatsächlich getan
  • Auch private Nachrichten mit potenziellen Dating-Partnern konnten eingesehen werden, und bei eingereichten Dokumenten sogar Passinformationen

Bestätigtes Ausmaß der Offenlegung

  • Mit einem schnellen Skript wurde gezählt, wie viele Nutzer Informationen abrufbar hatten, wie viele als Yale-Studierende registriert waren und wie viele Ausweisdaten eingegeben hatten
  • Das Skript stoppte, wenn es beim Durchzählen gültiger Benutzer-IDs 1.000 Mal in Folge keine gültige ID fand
  • Diese Methode schließt nicht aus, dass es noch mehr Nutzer gab
  • Cerca hatte angegeben, in der ersten Woche 10.000 Nutzer erreicht zu haben
  • Bestätigt wurden folgende Zahlen
    • 6.117 Nutzer
    • 207 Nutzer mit hinterlegten Ausweisdaten
    • 19 Nutzer, die als Yale-Studierende markiert waren

Datenschutzversprechen und tatsächliches Risiko

  • In der Datenschutzerklärung von Cerca heißt es, Daten würden „durch Verschlüsselung und andere branchenübliche Maßnahmen geschützt“
  • Verglichen mit dem tatsächlichen Zustand der Schwachstelle ist diese Aussage irreführend
  • Betroffen sein konnten sexuelle Präferenzen, private Nachrichten und verschiedenste personenbezogene Daten
  • Wenn böswillige Akteure Zugriff auf diese Informationen erhalten, kann das zu Identitätsdiebstahl, Stalking oder Erpressung führen
  • Dating-Apps verarbeiten sensible Daten; deshalb sollte die Sicherheit der Nutzerdaten Vorrang vor der Geschwindigkeit beim App-Launch haben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-13
Hacker-News-Kommentare

  • Diese App wirkt wie ein ziemlich frühes Projekt von Studierenden. Natürlich sollten sie ihr Bestes tun, um Sicherheits- und Kommunikationspraktiken ordentlich einzuhalten, aber wenn man bedenkt, dass auch „erwachsene Unternehmen“ mit großen VC-Investments bei ähnlichen Problemen miserabel reagieren, möchte ich nicht zu hart mit ihnen ins Gericht gehen.
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • Da widerspreche ich entschieden. „Sie wussten nicht, was sie tun, also sollten wir sie nicht zu streng beurteilen“ ist eine merkwürdige Aussage. Wenn sie nicht wussten, was sie tun, aber es trotzdem bis zum Launch durchgezogen haben, ist das eher ein erschwerender als ein mildernder Umstand.
      Das ist ähnlich wie bei einem Fahrer, der bei einem Unfall jemanden tötet, und dann stellt sich heraus, dass er nicht einmal einen Führerschein hatte.
    • Auf der Suche nach Informationen zu „Cerca“ habe ich denselben Link gesehen; der Artikel ist von April 2025 und lobt eine App, die zwei Monate zuvor gebaut wurde, daher wirkt er wie LLM-halluzinierter Müll.
      Im Originalbeitrag steht, dass man das Cerca-Team im Februar kontaktiert habe; entweder war es also ein Fehler, der am Launch-Tag gefunden wurde, oder die zeitliche Abfolge ist irgendwie seltsam. So oder so handelt es sich um eine „zwei Monate alte Schwachstelle“ und eine „zwei Monate alte von Studierenden gebaute App/einen zwei Monate alten Dienst“.
    • Wenn die App unter dem Namen Cerca Applications, LLC veröffentlicht wurde, wie soll man dann erkennen, ob das nur ein paar Script Kiddies sind, bei denen man ein Auge zudrücken sollte?
    • Diese Leute sollten vermutlich besser ein anderes Fach studieren.
    • Da ist etwas dran, aber trotzdem ist das hier zu viel. Einen geheim zu haltenden OTP nicht im Response-Body zurückzugeben, ist ziemlich grundlegender Menschenverstand, egal ob erfahrener Entwickler oder Schüler.
      Außerdem ist das kein Spaßprojekt, sondern ein kommerzielles Produkt. In-App-Käufe sind gelistet als Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99.

  • Als Ingenieur in einem kleinen Unternehmen mache ich mir manchmal Sorgen um meine persönliche Haftung. Es gibt so viele Unternehmen in nicht regulierten Branchen, in denen PCI oder HIPAA nicht greifen, und in kleinen Organisationen wird Sicherheit nicht als organisatorische Pflicht behandelt, sondern einfach als Engineering-Anliegen abgeschoben.
    Das Produktteam konzentriert sich auf Features, PMs auf Zeitpläne, QA darauf, Bugs zu finden, und kaum jemand erhebt vernünftig die Stimme zum Thema Sicherheit. Von Ingenieuren wird nicht erwartet, viel mehr zu tun, als die Aufgaben im Board abzuarbeiten. Wenn man etwas ohne Auswirkungen auf den Zeitplan sicher machen kann, ist das gut; wenn nicht, bekommt man Druck von PMs und anderen.
    Dann hört man Dinge wie: „Wie lange dauert das denn?“, „Wie hoch ist wirklich das Risiko, dass so etwas passiert?“, „Kümmern wir uns später um die Sicherheit und bringen erst mal das MVP zu den Kunden.“ Als Angestellter tue ich, was mein Arbeitgeber mir aufträgt; wenn das Unternehmen wegen eines Hacks oder Datenlecks verklagt wird, frage ich mich, ob ich persönlich haftbar gemacht werde, nur weil ich die einzige Person bin, die „es hätte wissen müssen“.

    • Streng genommen bist du kein echter Ingenieur im klassischen Sinne. Du wirst keine Konstruktionspläne unterschreiben, die Sicherheit zertifizieren, und du wirst auch nicht dafür haften, wenn sich etwas als unsicher erweist.
    • Wenn es eine LLC oder Kapitalgesellschaft ist, bist du wahrscheinlich durch den Corporate Veil geschützt, solange nicht dokumentiert ist, dass du eine Straftat begangen hast.
      Allerdings ist der Mangel an Sicherheitsstandards in Organisationen jeder Größe erbärmlich. Neue Features auszuliefern scheint immer Vorrang davor zu haben, gute Security Practices sicherzustellen.
    • Persönlich würde ich genug Recht kennen wollen, um mich selbst zu schützen, illegalen Dingen schriftlich widersprechen und mir auch Anweisungen, diese Bedenken zu ignorieren, schriftlich bestätigen lassen.
      Ich verstehe aber, dass selbst das in einem Startup mit nur ein oder zwei Entwicklern schwierig ist. Wenn ich den Eindruck hätte, dass dort keine legalen Ziele verfolgt werden, würde ich wohl gehen.
    • Als Ingenieur in einer kleinen Organisation hast du meines Erachtens die Verantwortung, dem restlichen Team solche Sicherheitsrisiken zu vermitteln und darauf zu drängen, dass Engineering-Zeit für deren Minderung bereitgestellt wird.
      Das ist nicht einfach, aber es ist wichtig und kann das gesamte Geschäft versenken, wenn man es nicht ernst nimmt.
    • Auch wenn ich die Verteidigung „Ich habe nur Befehle befolgt“ nicht mag: In so einem Fall sollte man unbedingt schriftliche Nachweise haben.
      Man braucht E-Mail-Aufzeichnungen, in denen man Bedenken wegen mangelnder Sicherheit vorgebracht hat, und Antworten der Vorgesetzten, in denen steht, man solle sich nicht darum kümmern. Ich weiß nicht, um welche Gerichtsbarkeit es geht, aber mir ist kein Fall bekannt, in dem ein gewöhnlicher Angestellter persönlich rechtlich für ein Datenleck haftbar gemacht wurde. Meist hat bei Datenlecks niemand echte Konsequenzen zu tragen, und das Unternehmen zahlt nur eine symbolische Strafe und macht weiter.

  • Um als Forscher die rechtliche Angriffsfläche zu verringern, hätte es wohl gereicht, ein zweites Konto anzulegen oder einen Freund ein Profil erstellen zu lassen und sich dessen Zustimmung zum Zugriff zu holen.
    Um eine Enumeration-Schwachstelle nachzuweisen, muss man nicht tatsächlich Daten scrapen. Wenn meine ID 12345 ist und ein Freund sich anmeldet und 12357 erhält, reicht das als Beleg dafür, dass man die ID eines beliebigen Nutzers finden und auf dessen Profil zugreifen kann.
    Wie andere gesagt haben: Um eine Schwachstelle zu verifizieren und offenzulegen, muss man nicht in diesem Umfang auf personenbezogene Daten anderer Nutzer zugreifen.

    • Das ist die standardmäßige und offensichtliche Vorgehensweise, die die meisten Sicherheitsforscher ignorieren.
      Zu wollen, dass personenbezogene Daten geschützt werden, sie aber gleichzeitig zu scrapen, um den Punkt zu beweisen, ist unnötig und heuchlerisch.

  • Der Text ist ziemlich verwirrend. Die Stelle, dass bei einem OTP-basierten Login in der Antwort auf die Anfrage nach dem Einmalpasswort das OTP direkt enthalten ist, ist unzureichend erklärt, aber vermutlich bedeutet es, dass es eine API wie api.cercadating.com/otp/ gibt und man durch Erraten einer Telefonnummer den OTP-Code erhalten kann, ohne diese Nummer zu besitzen.
    Außerdem schreibt der Autor, er habe mit einem Skript, das stoppt, wenn es bei 1.000 aufeinanderfolgenden IDs keine gültigen Nutzer findet, 6.117 Personen gefunden, 207 Personen, die Ausweisdaten hinterlegt hatten, und 19 Personen, die angaben, Yale-Studierende zu sein. Ich bin mir nicht sicher, ob ihm klar ist, wie riskant das ist. Im Grunde ähnelt das der Methode, mit der weev AT&T kompromittiert hat, und er landete dafür im Gefängnis[0].
    Das war zwar ein größeres Unternehmen und ein größerer Leak, aber ich würde nicht öffentlich damit prahlen, über eine Sicherheitslücke unbefugt auf Daten von Tausenden Menschen zugegriffen zu haben. Ich will hier keine Moralbewertung vornehmen, und ich finde, dass Sicherheitsforscher Spielraum zum Warnen haben sollten, aber das Gesetz ist Sicherheitsforschern gegenüber ziemlich ungnädig.
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • Er erwähnt das Erraten von Telefonnummern, und es heißt, dass der API-Aufruf zum Senden des OTP buchstäblich das OTP zurückgibt.
    • Wenn man die ursprüngliche Anklageschrift im Fall Auernheimer liest, hatte die Staatsanwaltschaft dort umfangreiche Beweise für Vorsatz, die es hier wahrscheinlich nicht gibt.
      Den Angeklagten in diesem Fall wurde außerdem vorgeworfen, zugrunde liegende personenbezogene Daten veröffentlicht zu haben; hier sieht es nicht so aus, als wäre das passiert.

  • Ich habe bei einer anderen Dating-App etwas Ähnliches erlebt, und dort kam am Ende nie eine Antwort. Um die Aufmerksamkeit des Gründers zu bekommen, habe ich seinen Profiltext in „Bitte melde dich“ geändert, woraufhin er ein Backup wiederherstellte.
    Ein paar Jahre später sah ich eine Instagram-Werbung und prüfte, ob das Problem noch bestand: Es war immer noch da. Wer nur die API-Endpunkte kannte, die sich leicht über App–Proxy–Server finden ließen, hatte vollständige Admin-Rechte und Zugriff auf alle Nachrichten, Matches usw.
    Ich frage mich, ob ich noch einmal hingehen und es erneut versuchen sollte.

    • Als verantwortungsvoller Entwickler würde es doch reichen, einfach über die Kontaktadresse eine Vulnerability Disclosure zu machen und es dabei zu belassen, oder?

  • Bevor man sensible Informationen wie Reisepass- oder Adressdaten entgegennimmt, sollte man Menschen dazu zwingen, zweimal darüber nachzudenken. So etwas kann man nicht einfach als Kinder haben eine App gebaut abtun.

    • Es gibt keinerlei Grund, Reisepass- oder andere Ausweisdaten nach der Eingabe öffentlich offenzulegen. Selbst wenn die UI Daten per API abrufen muss, um sie anzuzeigen, muss sie nicht die vollständige Pass- oder Ausweisnummer enthalten; mindestens sollte man sie maskieren und nur die letzten paar Stellen senden.
      Bei einer Dating-Site würde es völlig reichen, wenn die API zum Ausweisstatus ein Boolean verified/not-verified oder einen Enum-Wert wie „not-verified“, „passport“ oder „drivers-license“ zurückgibt. Es gibt keinen echten Bedarf, Details im Client bzw. in der UI anzuzeigen.
      Fälle wie Airline-Apps, bei denen man Reisedokumente für Einreise-/Ausreisezwecke auswählen muss, sind eine Ausnahme und können mehr Informationen anzeigen, aber wie in der United-App reicht es, nur die letzten paar Stellen der Passnummer zu zeigen. Ich würde hoffen, dass auch interne APIs nur so viel senden.
    • Die britische Regierung arbeitet eifrig daran, für den Zugriff auf Pornoseiten Ausweisprüfungen verpflichtend zu machen; ich freue mich schon auf den Tag, an dem ihnen das um die Ohren fliegt.
    • Es sollte so etwas wie einen staatlich betriebenen, sicheren und privaten Identitätsprüfungsdienst geben.
      Oder notfalls könnten auch „staatsähnliche“ Akteure wie Apple oder Google das übernehmen.
    • Siehe DSGVO.
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • Haben sie keinen Drittanbieter-Dienst zur Identitätsprüfung genutzt? Normalerweise machen Apps das doch so. Hoffentlich geben solche Drittanbieter-Dienste nicht etwa die Ausweis-Originale wie echte Bilder unverändert an die App weiter?

  • Dass die API-Antwort auf die Anfrage das OTP zurückgibt, ergibt keinen Sinn. Warum sollte man das so machen?

    • Vielleicht wollte man die UI prüfen lassen, ob der vom Nutzer eingegebene Wert korrekt ist.
      Wenn man Sicherheit nicht bedenkt, ist das eine sehr plausible und offensichtliche Lösung. Dating-Apps gehören wegen der zwangsläufig vielen personenbezogenen Daten zu den riskantesten Arten von Apps, die man bauen kann; das hier ist furchtbar.
    • Möglicherweise wurde das OTP erzeugt und gespeichert und anschließend einfach die Antwort der Datenbank oder des Caches unverändert zurückgegeben.
      Bei schnellen Proofs of Concept oder MVPs verwendet man aus Zeitgründen oft direkt das Speichermodell als API-Antwort, daher kann so etwas leicht übersehen werden.
    • Ein einfacher Trick, um Datenbankkosten zu vermeiden.
    • Es spart eine HTTP-Anfrage und macht die User Experience schneller. Was soll man daran nicht mögen?
      Als die neue Pinterest-API herauskam, verteilte sie an alle Apps mit OAuth-Integration sämtliche Nutzerdaten, sogar inklusive 2FA-Secret. Ich habe es gemeldet und eine Prämie bekommen, aber solche Dinge passieren selbst bei APIs großer Unternehmen, die es besser wissen müssten.
    • Das OTP scheint in der „Antwort, die das Einmalpasswort ausgelöst hat“, gesendet worden zu sein.
      Es könnte am Framework liegen. Vermutlich wurde ein Objekt, das in die Datenbank geschrieben wird, direkt aus dem ORM oder einem anderen Speichersystem serialisiert und als HTTP-Antwort zurückgegeben.

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    Ein weiterer Artikel zu diesem Fall.

    • „Entwickler sollten Best Practices verwenden, aber das reicht möglicherweise nicht. Daten sicher aufzubewahren ist ein ungelöstes Problem“ – ach so, na dann. Kann man wohl nichts machen.

  • Ich wünschte, es gäbe Gesetze, die das Speichern personenbezogener Daten so gefährlich machen wie die Lagerung von Atommüll. Bei einem Leak sollte das Unternehmen mit ziemlicher Sicherheit bankrottgehen, und die Verantwortlichen sollten rechtlichen Risiken ausgesetzt sein.
    Ich halte das für den besten Weg, die Anreize richtig zu setzen. Derzeit gibt es kaum Nachteile, möglichst viele Nutzerdaten zu speichern. Datenleck? Einen Entschuldigungs-Tweet posten und weitermachen.

    • Personenbezogene Daten wie Atommüll zu behandeln, halte ich für etwas extrem. Zu personenbezogenen Daten gehören auch relativ harmlose Daten wie E-Mail-Adressen für Authentifizierung und Kontaktzwecke.
    • Vielleicht brauchen wir Gefängnisstrafen für Wirtschaftskriminalität.
      Dann würde dieses Problem vielleicht die Aufmerksamkeit bekommen, die es verdient.

  • Wenn man „überhaupt keine Antwort erhalten hat“, ist es an der Zeit mitzuteilen, dass man die Schwachstelle nach 90 Tagen offenlegen wird, falls das Schweigen anhält

    • Das wäre für unschuldige Nutzer eine größere Strafe als für das Unternehmen
    • Hier gibt es nicht einmal etwas, das man als Schwachstelle bezeichnen könnte. Es ist schlicht offen zugänglich
    • So etwas ist ein guter Weg, um verklagt und sogar strafrechtlich angezeigt zu werden