Erfahrung mit dem Hack einer Dating-App (und wie man Sicherheitsforscher falsch behandelt)

• In der Dating-App Cerca wurde eine schwerwiegende Sicherheitslücke entdeckt
• Das OTP wurde in der Antwort offengelegt, sodass jeder mit nur der Telefonnummer auf ein Konto zugreifen konnte
• Über mehrere ohne Authentifizierung offene API-Endpunkte konnten personenbezogene Daten leicht abfließen
• Sexuelle Präferenzen, Messenger-Inhalte, Ausweisdokumente und andere sensible Informationen der Nutzer wurden in großem Umfang offengelegt
• Der Dienst reagierte trotz verantwortungsvoller Meldung durch den Forscher nicht angemessen und informierte die Nutzer nur unzureichend

---

Warum Startups Sicherheit ernst nehmen müssen

• In letzter Zeit wird bei Startups, die ihren Marktstart beschleunigen wollen, die Sicherheit oft vernachlässigt
• Obwohl es sich um eine Dating-App mit hochkonzentrierten personenbezogenen Daten handelt, wurden Nutzer durch mangelhafte Entwicklung und Betriebsführung Risiken ausgesetzt

Entdeckung der Schwachstellen und Meldeprozess

• Am 23. Februar 2025 wurden die Sicherheitslücken und damit verbundene Probleme per E-Mail an Cerca erläutert
• Am 24. Februar wurden in einer Videokonferenz die Details der Schwachstellen, Gegenmaßnahmen und das weitere Vorgehen besprochen
• Das Cerca-Team teilte mit, man habe den Ernst der Lage erkannt, schnelle Maßnahmen zugesagt und plane eine Nutzerbenachrichtigung
• Danach wurden mehrfach Anfragen zum Fortschritt gestellt, doch bis zum 21. April gab es keine Antwort und keine Mitteilung
• Eine unabhängige Überprüfung ergab, dass die Schwachstelle inzwischen gepatcht war

OTP-Schwachstelle und einfacher Hacking-Ablauf

• Beim Login in die App wurde das One-Time Password (OTP) unverändert in der Netzwerkantwort offengelegt
• Ein Angreifer konnte mit nur einer Telefonnummer einfach und schnell auf jedes Konto zugreifen

Zugriff auf API-Endpunkte und Datenabfluss

• Es wurde bestätigt, dass der Zugriff auf sämtliche API-Pfade bereits durch das Setzen eines App-Version-Headers möglich war
• Über den Endpunkt /docs wurde die gesamte OpenAPI-Dokumentation offengelegt
• Mit Tools wie Burp Suite war durch automatisches Einfügen von App-Headern und Tokens eine Kontrolle der APIs möglich
• Einige Endpunkte änderten nur Business-Logik, doch zentrale Endpunkte gaben in schwerwiegender Weise personenbezogene Daten zurück
• Über user/{user_id} und ähnliche Pfade waren personenbezogene Daten, Telefonnummern und sogar Kontoübernahmen möglich

Offenlegung großer Mengen personenbezogener Daten und Ausweisinformationen

• Über Endpunkte für personenbezogene Daten wurden Geschlecht, Stadt, Geburtstag, Hochschul-E-Mail, Ausweisinformationen und weitere PII in großem Umfang offengelegt
• Besonders über ausweisbezogene Felder wie national_id_verified war der Zugriff auf sensible Dateien wie Passbilder oder Bilder von Personalausweisen möglich
• Mit einem Angriffsskript wurden 6.117 Nutzer identifiziert; bei 207 davon waren sogar Ausweisdaten hinterlegt
• Darunter befanden sich auch einige Konten, die eine Zugehörigkeit zur Yale University angaben
• Laut dem offiziellen Instagram von Cerca entsprach dies dem Umfang von 10.000 Nutzern in der ersten Woche

Konkretes Schadensrisiko und Schwere des Problems

• Durch das Leck von sexuellen Präferenzen, Gesprächsinhalten, Ausweisdokumenten und anderen extrem sensiblen Informationen bestand ein erhebliches Risiko für Stalking, Identitätsdiebstahl und Erpressung
• Cerca hatte erklärt, man halte Branchenstandards wie Verschlüsselung ein, doch das passte nicht zum tatsächlichen Betriebszustand
• Da Nutzer dies nicht selbst verifizieren können, ist ein aktives und verantwortungsvolles Sicherheitsmanagement durch den App-Anbieter unerlässlich
• Faktisch besteht auch die Möglichkeit, dass bereits eine unbestimmte Zahl Dritter in großem Umfang personenbezogene Daten abgegriffen hat

Fazit und die Notwendigkeit einer verantwortungsvollen Sicherheitskultur

• Der Betrieb einer App, die sich so leicht hacken lässt, ist ein schwerwiegendes gesellschaftliches Problem
• Wenn der Schutz von Nutzerdaten nicht oberste Priorität hat, kann in Echtzeit Schaden entstehen
• Der Fall Cerca, der auf die Meldung eines Sicherheitsforschers nicht aktiv genug reagierte und Nutzer unzureichend informierte, sollte anderen als Warnung dienen
• Um ein sichereres Internet aufzubauen, muss für alle Entwicklerunternehmen der Aufbau belastbarer Sicherheitsstrukturen oberste Priorität haben

[GN⁺]

Hacker-News-Kommentare

• Selbst wenn man berücksichtigt, dass diese App offenbar von Studierenden auf ziemlich niedrigem Niveau gebaut wurde, finde ich, dass man bei Sicherheit und Kommunikation sein Bestes geben muss. Gleichzeitig stoßen selbst von großen VCs finanzierte Adult-Unternehmen auf solche Probleme und verhalten sich ähnlich, daher sollte man mit den Studierenden vielleicht nicht übermäßig hart ins Gericht gehen. Hier ist der verlinkte Artikel.

  • Dem stimme ich entschieden nicht zu. „Sie wussten es nicht“ kann kein Freibrief sein. Dass sie ohne Wissen einfach weitergemacht haben, ist eher ein noch größeres Problem. Das ist so, als würde ein unerfahrener Fahrer ohne Führerschein einen Unfall bauen und jemanden verletzen.
  • Ich habe auch auf den Quellenlink geklickt, als ich etwas über Cerca herausfinden wollte, und es war ein Artikel von April 2025, der eine App lobt, die etwa zwei Monate zuvor erstellt wurde. Das wirkt wie von einem LLM halluzinierter Müll. Laut OP wurde das Cerca-Team im Februar kontaktiert, also entweder wurde die Schwachstelle direkt nach dem Launch entdeckt oder hier stimmt etwas nicht. Trotzdem bleibt es dabei: eine „zwei Monate alte Schwachstelle“ in einem „zwei Monate alten, von Studierenden gebauten Dienst“.
  • Wenn die App unter dem Namen „Cerca Applications, LLC“ veröffentlicht wird, ist mir nicht klar, wie Leute wissen sollen, dass sie nachsichtiger sein sollten, weil sie von Studierenden gebaut wurde.
  • Diese Studierenden sollten vielleicht etwas anderes lernen.
  • Das klingt, als würdest du sie verteidigen. Man sollte eine von Studierenden gebaute App nicht automatisch schonen. The Facebook wurde anfangs auch von Studierenden gestartet. Metas lange Geschichte des Missbrauchs von Privatsphäre und der Missachtung von Datensicherheit ist inzwischen gut dokumentiert. Deshalb ist so ein Verhalten nicht zu entschuldigen, und ich denke, nur richtige Regulierung und Geldstrafen helfen — unabhängig vom Alter oder der Erfahrung der Gründer.
  • Wenn man mit sensiblen Daten wie Pässen und sexueller Orientierung arbeitet, sollte man zumindest reagieren, wenn jemand darauf hinweist, dass Daten offengelegt werden. Das ist ein komplettes Desaster, und das Ausmaß des fehlenden Sicherheitsniveaus ist hier absolut inakzeptabel.
  • Wenn man nichts von App-Sicherheit versteht, sollte man einfach keine App bauen. Das ist jetzt emotional formuliert, aber wenn ich Freunde Dating-Apps nutzen sehe, finde ich es furchtbar, dass ihre Daten offengelegt werden könnten. Die Leute, die das gebaut haben, sollten sich schämen. Sie sollten sich auch dafür schämen, auf Hinweise eines Sicherheitsforschers nicht geantwortet zu haben. Wenn ich so ignoriert worden wäre, hätte ich einen viel direkteren Enthüllungspost geschrieben. Bitte hört auf, Apps zu bauen.

• Als Entwickler in einem kleinen Unternehmen mache ich mir manchmal Sorgen über meine persönliche Verantwortung. Viele Unternehmen operieren in Bereichen, die nicht unter Regulierungen wie PCI oder HIPAA fallen. In kleinen Organisationen wird Sicherheit nicht als Aufgabe der ganzen Organisation gesehen, sondern als Engineering-Thema. Das Produktteam fokussiert Features, PMs fokussieren Zeitpläne, QA fokussiert Bugs, und nur wenige erheben ihre Stimme zur Sicherheit. Bei Ingenieuren herrscht dann die Haltung, dass es reicht, einfach die zugewiesene Arbeit zu erledigen. Wenn ein Engineer sich zusätzlich um Sicherheit kümmern kann, gut — sonst bekommt er dafür sogar noch Kritik von PMs und anderen. Und man hört ständig Dinge wie: „Wie lange dauert das?“, „Wie wahrscheinlich ist es überhaupt, dass das passiert?“, „Lasst uns erst mal schnell das MVP launchen und später nachbessern.“ Also mache ich als Angestellter am Ende einfach das, was das Unternehmen verlangt. Aber wenn die Firma wegen eines Hacks oder Datenlecks verklagt wird, frage ich mich oft, ob ich dann als der Engineer, der es „besser hätte wissen müssen“, die Verantwortung tragen müsste.

  • De facto bist du kein Engineer, der irgendwelche Zertifizierungsunterlagen unterschreibt und Sicherheit garantiert, also wirst du auch nicht haften, selbst wenn nachgewiesen wird, dass es unsicher war.
  • Wenn die Firma eine LLC oder Corp ist, bist du durch den corporate veil geschützt. Solange du nicht nachweislich Straftaten begangen hast, trägst du keine Verantwortung. Aber fehlende Sicherheitsstandards sind auf allen Unternehmensebenen ein großes Problem. Das Ausrollen neuer Features wird immer wichtiger behandelt als Sicherheit.
  • Ich denke, als Engineer in einer kleinen Organisation ist es unsere Verantwortung, das Team über diese Risiken aufzuklären und entschieden dafür zu plädieren, Entwicklungszeit für Sicherheit einzuplanen. Es ist nicht leicht, aber wenn man das vernachlässigt, kann man das Unternehmen selbst in Gefahr bringen.
  • Ich würde genug über das Recht wissen wollen, um mich selbst zu schützen, schriftlich gegen rechtswidrige Anweisungen Einspruch einlegen und mir auch schriftlich bestätigen lassen, dass sie ignoriert werden dürfen. In einem kleinen Startup kann selbst das schwierig sein. Wenn es sich nicht legal anfühlt, würde ich einfach kündigen.
  • Ich mag die Verteidigung „Ich habe nur Befehle befolgt“ nicht, aber in solchen Fällen sollte man unbedingt schriftliche Spuren hinterlassen: per Mail festhalten, dass es ein Sicherheitsproblem gibt, und Belege sichern, wenn der Vorgesetzte mit etwas wie „Darum musst du dich nicht kümmern“ antwortet. Soweit ich weiß, habe ich noch nie gesehen, dass ein normaler Angestellter wegen eines Datenlecks rechtlich haftbar gemacht wurde. Meist wird niemand persönlich verantwortlich gemacht, und die Firma zahlt nur eine symbolische Geldstrafe.
  • Wenn du kein Geschäftsführer oder sonstiger leitender Angestellter bist, wirst du vermutlich keine persönliche Haftung tragen.
  • Meiner Erfahrung nach passiert so etwas nicht.

• Um das rechtliche Risiko für Forschende zu senken, sollte es ausreichen, ein weiteres Konto anzulegen oder mit Zustimmung eines Freundes ein Profil zu erstellen, um Zugriffsrechte zu erhalten. Man müsste die Daten nicht tatsächlich scrapen; wenn zum Beispiel meine id 12345 ist und die meines Freundes 12357, reicht es zu zeigen, dass man über die IDs dazwischen auf andere Profile zugreifen kann. Wie viele schon gesagt haben: Es ist nicht nötig, Zugriff auf Tausende personenbezogene Datensätze zu nehmen; es reicht, die Schwachstelle nachzuweisen und offenzulegen.

  • Das ist ein standardmäßiges, klares Vorgehen, das jeder InfoSec-Forscher kennen sollte. Man könnte versucht sein, sensible Informationen zu scrapen, um es zu beweisen, aber das ist unnötig und eher heuchlerisch.

• Dieser Text selbst wirkt ziemlich verwirrend. Es heißt, die API zum Empfangen eines OTP (Einmalpassworts) sei so simpel gewesen, dass das OTP einfach in der Serverantwort offengelegt wurde und damit jeder mit einer Telefonnummer auf ein Konto zugreifen konnte. Wenn die API einfach otp/Telefonnummer war und das OTP in der Antwort enthalten war, scheint es so zu sein, dass man nur die Telefonnummer erraten musste, um auch den Code zu bekommen. Dann wird erklärt, dass per Skript Nutzer-IDs aufgelistet wurden und nach 1.000 aufeinanderfolgenden leeren IDs gestoppt wurde, wodurch insgesamt 6.117 Nutzer, 207 Ausweisdaten und 19 Yale-Studierende identifiziert wurden. Aber in diesem Umfang ohne Einwilligung auf die personenbezogenen Daten anderer zuzugreifen, ähnelt dem Fall, in dem weev wegen des AT&T-Hacks im Gefängnis landete. Auch wenn der Umfang kleiner ist, ist solche Forschung rechtlich riskant, und es ist beunruhigend, dass der Autor die Rechtslage, die Sicherheitsforschende nicht schützt, offenbar nicht kennt.

  • Es wird darauf hingewiesen, dass die API unter otp/Nummer das endgültige OTP direkt zurückgegeben habe. Das bedeutet, dass man das OTP sofort bekam, wenn man nur die Telefonnummer richtig hatte.
  • Wenn man die ursprüngliche Anklageschrift im Fall Auernheimer liest, findet man dort — anders als hier — genügend Belege für kriminelle Absicht. Dort wurde ihnen auch vorgeworfen, personenbezogene Daten tatsächlich nach außen veröffentlicht zu haben; so weit geht dieser Fall nicht.

• Ich hatte eine ähnliche Erfahrung: Ich wollte bei einer anderen Dating-App einen Bug melden, konnte niemanden erreichen und habe dann das Gründerprofil auf „Bitte kontaktieren Sie mich“ geändert. Sie haben es einfach aus einem Backup wiederhergestellt. Jahre später sah ich die App in einer Instagram-Anzeige und habe es noch einmal probiert — dieselbe Schwachstelle existierte immer noch. Wer nur den API-Endpunkt kennt, bekommt Admin-Rechte sowie Zugriff auf alle Nachrichten und Matches. Ich überlege, ob ich noch einmal Kontakt aufnehmen soll.

  • Es wird vorgeschlagen, Kontakt aufzunehmen, sich als verantwortungsbewusster Entwickler zu erkennen zu geben und dann nur das Problem offenzulegen und es dabei zu belassen.

• Wenn Apps sensible Informationen wie Pässe oder Adressen sammeln, sollte das einen wirklich zweimal nachdenken lassen. Das ist nichts, was man mit „Ist halt eine von Studierenden gebaute App“ abtun sollte.

  • Die britische Regierung versucht, Ausweise für den Zugang zu Pornoseiten verpflichtend zu machen, und ich bin gespannt, wohin das führen wird.
  • Wenn Pass- oder andere Ausweisdaten eingegeben wurden, sollte es nie nötig sein, sie danach wieder nach außen offenzulegen. Wenn es eine API gibt, um Ausweisdaten im UI anzuzeigen, reichen statt der vollständigen Nummer die letzten paar Ziffern. Bei einer Dating-App würde es genügen, nur zurückzugeben, ob die ID verifiziert wurde, etwa als Boolean oder Enum (nicht verifiziert / Reisepass / Führerschein). Systeme wie Airline-Apps, in denen man gezielt unter mehreren IDs wählen muss, sind eine Ausnahme, aber selbst die United-App zeigt zum Beispiel nur die letzten paar Ziffern. So sollten auch interne APIs eingeschränkt sein.
  • Es wird ein Link mit dem Hinweis geteilt, auf die DSGVO zu verweisen.
  • Ich denke, wir brauchen eigentlich einen sicheren, privaten Identitätsdienst, der direkt vom Staat betrieben wird. Oder alternativ sollte das eine Firma übernehmen, die fast wie ein Staat funktioniert, etwa Apple oder Google.
  • Normalerweise nutzt man möglichst einen externen Identitätsdienst, aber ich frage mich, ob solche Dienste wirklich sogar Ausweisbilder an die App weitergeben.

• Ein OTP unverändert in der API-Antwort zurückzugeben, ist so absurd, dass ich nicht verstehe, warum man das tun würde.

  • Damit das UI die Eingabe direkt vergleichen kann. Wenn man Sicherheit nicht mitdenkt, klingt das vielleicht plausibel. Dating-Apps haben einen enormen Umfang an erforderlichen personenbezogenen Daten, deshalb ist so ein Fehler besonders schrecklich.
  • Damit lassen sich Datenbankkosten auf einen Schlag senken.
  • Man könnte ein OTP erzeugen und dann die DB- oder Cache-Antwort direkt zurückgeben; in einem POC oder MVP übersieht man so ein Modell leicht.
  • Offenbar wurde das OTP direkt in der „Antwort auf die Anforderung zum Versand eines Einmalpassworts“ offengelegt. Das könnte daran liegen, dass ein Framework einfach das komplette DB-Objekt serialisiert und per HTTP zurückgibt.
  • Man spart sich einen HTTP-Request und die UX wirkt schneller, also sieht es oberflächlich gut aus. Pinterest hat in einer früheren API auch einmal alle Informationen offengelegt, einschließlich des 2FA-Secrets. Ich habe das gemeldet und sogar eine Belohnung bekommen, aber solche Fehler passieren selbst Big Tech gelegentlich.
  • Ich verstehe es auch nicht. Ich kann mir nur vorstellen, dass es ein Fehler war, um den Formularbau zu vereinfachen.

• Es wird ein Link zu einem weiteren relevanten Artikel in den Yale Daily News geteilt.

• Ich wünschte, es gäbe Gesetze, die mit personenbezogenen Daten so umgehen, als wären sie auf dem Gefährdungsniveau von Atommüll. Bei einem Leak sollte nicht nur das Unternehmen pleitegehen, sondern auch die Verantwortlichen in rechtliche Schwierigkeiten geraten. Im Moment ist es viel zu leicht, Nutzerdaten zu sammeln, und wenn sie dann geleakt werden, entschuldigt man sich einfach und macht weiter.

  • PII wie Nuklearmaterial zu behandeln, scheint übertrieben. Eine E-Mail-Adresse, die nur zur Authentifizierung oder Kontaktaufnahme dient, ist nicht besonders problematisch.
  • Selbst ein white-collar-Gefängnis würde vermutlich erst die nötige Aufmerksamkeit erzeugen.

• Ich habe auf iOS gerade erst von dem Tool Charles Proxy erfahren. Früher habe ich Pentests gemacht, indem ich direkt in App-Binaries nach Strings gesucht habe. Für die Analyse von iOS-only-Apps dürfte das eine enorme Hilfe sein.

  • Solides Tool, klare Empfehlung (funktioniert allerdings nicht, wenn SSL pinning aktiv ist).