L’expérience de piratage d’une app de rencontre (et la mauvaise façon de traiter les chercheurs en sécurité)

• Une faille de sécurité critique a été découverte dans l’app de rencontre Cerca
• Le code OTP était exposé dans la réponse, ce qui permettait à n’importe qui d’accéder à un compte en connaissant seulement le numéro de téléphone
• Plusieurs endpoints API ouverts sans authentification permettaient une fuite facile de données personnelles
• Des informations sensibles sur les utilisateurs, comme leurs préférences sexuelles, le contenu des messages et leurs pièces d’identité, ont été massivement exposées
• Malgré un signalement responsable du chercheur, le service a fourni une réponse inadaptée et des notifications insuffisantes

---

L’importance pour les startups de prendre la sécurité au sérieux

• Ces derniers temps, de nombreuses startups négligent la sécurité en se précipitant vers leur lancement sur le marché
• Bien qu’il s’agisse d’une app de rencontre concentrant des données personnelles, le manque de maturité dans le développement et l’exploitation a exposé les utilisateurs à des risques

Découverte de la faille et procédure de notification

• Le 23 février 2025, un e-mail a été envoyé à Cerca pour décrire la faille de sécurité et les problèmes associés
• Le 24 février, une visioconférence a permis de discuter en détail de la faille, des mesures correctives et de la suite de la procédure
• L’équipe de Cerca a indiqué avoir pris la mesure de la gravité, promis une correction rapide et annoncé qu’elle préviendrait les utilisateurs
• Plusieurs demandes de mise à jour ont ensuite été envoyées, mais au 21 avril, aucune réponse ni communication n’avait été fournie
• Une vérification indépendante a montré que la faille avait bien été corrigée

Faille OTP et processus de piratage très simple

• Lors de la connexion à l’application, le mot de passe à usage unique (OTP) apparaissait tel quel dans la réponse réseau
• Un attaquant pouvait ainsi accéder rapidement et facilement à n’importe quel compte en connaissant seulement le numéro de téléphone

Accès aux endpoints API et fuite d’informations

• Il a été constaté qu’il suffisait de renseigner l’en-tête de version de l’app pour accéder à tous les chemins API
• L’endpoint /docs exposait l’intégralité de la documentation OpenAPI
• À l’aide d’outils comme Burp Suite, il était possible de contrôler les API via l’injection automatique des en-têtes de l’app et des tokens
• Certains endpoints ne modifiaient que la logique métier, mais les endpoints essentiels renvoyaient gravement des données personnelles
• Avec user/{user_id} et d’autres endpoints, il était possible d’obtenir des informations personnelles, des numéros de téléphone, et même de prendre le contrôle de comptes

Exposition massive de données personnelles et de pièces d’identité

• L’endpoint de données personnelles exposait massivement des PII telles que le genre, la ville, la date de naissance, l’e-mail universitaire et des informations d’identité
• En particulier, des champs liés à l’identité comme national_id_verified permettaient d’accéder à des fichiers sensibles, notamment des images de passeports et de cartes d’identité
• Un script d’attaque a permis d’identifier 6017 utilisateurs, dont 207 avaient même renseigné des informations de pièce d’identité
• Parmi eux figuraient aussi certains comptes indiquant une affiliation à l’université Yale
• D’après l’Instagram officiel de Cerca, cela correspond à 10�00 utilisateurs lors de la première semaine

Risques concrets et gravité du problème

• La fuite d’informations extrêmement sensibles comme les préférences sexuelles, le contenu des conversations et les pièces d’identité créait un risque majeur de harcèlement, d’usurpation d’identité et de chantage
• Cerca indiquait respecter les standards du secteur, notamment en matière de chiffrement, mais cela ne correspondait pas à la réalité de l’exploitation
• Les utilisateurs ne pouvant pas le vérifier eux-mêmes, une gestion active et responsable de la sécurité par l’éditeur de l’app est indispensable
• En pratique, il est aussi possible qu’un grand nombre d’acteurs non identifiés aient déjà exfiltré massivement des données personnelles

Conclusion et nécessité d’une culture de sécurité responsable

• L’exploitation d’une app si vulnérable qu’elle peut être piratée par presque n’importe qui constitue un grave problème de société
• Si la protection des données des utilisateurs n’est pas la priorité absolue, des dommages peuvent survenir en temps réel
• Le cas de Cerca, dont la réponse au signalement du chercheur en sécurité et l’information aux utilisateurs ont été insuffisantes, doit servir d’avertissement
• Pour construire un Internet plus sûr, l’établissement de dispositifs de sécurité doit être la priorité absolue pour tous les éditeurs

[GN⁺]

Réactions sur Hacker News

• Même en tenant compte du fait que cette app semble être le produit assez débutant d’étudiants, je pense qu’il faut faire de son mieux sur la sécurité et la communication. Cela dit, quand on voit de grosses boîtes pour adultes financées par de grands VC se heurter aux mêmes problèmes et réagir de façon similaire, je ne pense pas qu’il faille être excessivement dur avec des étudiants. Je partage le lien de l’article

  • Je ne suis pas du tout d’accord. « Ils ne savaient pas » ne peut pas servir d’excuse. Le fait d’avoir foncé sans savoir est plutôt un problème encore plus grave. C’est comme un conducteur inexpérimenté qui blesse quelqu’un dans un accident en conduisant sans permis
  • J’ai aussi cliqué sur le lien source en cherchant des infos sur Cerca, et c’est un article d’avril 2025 qui encense une app créée environ deux mois plus tôt. Ça donne l’impression d’un déchet halluciné par un LLM. Comme le dit l’OP, il affirme avoir contacté l’équipe de Cerca en février, donc soit la faille a été découverte dès le lancement, soit il y a quelque chose d’étrange. Cela dit, on a quand même le combo « vulnérabilité vieille de deux mois » + « service créé par des étudiants il y a deux mois »
  • Si l’app est publiée sous le nom « Cerca Applications, LLC », je ne vois pas comment les gens sont censés savoir qu’ils devraient être plus indulgents parce qu’elle a été faite par des étudiants
  • Ces étudiants feraient peut-être mieux d’étudier autre chose
  • On dirait que vous prenez leur défense. Ce n’est pas parce qu’une app a été faite par des étudiants qu’il faut systématiquement la laisser passer. The Facebook a aussi été lancé au départ par des étudiants. Meta a une longue histoire d’abus de la vie privée et de négligence de la sécurité des données. Donc, ce genre de comportement n’est pas excusable et, à mon avis, le problème ne sera résolu que si c’est correctement régulé et sanctionné par des amendes, quel que soit l’âge ou l’expérience des fondateurs
  • Quand on manipule des données sensibles comme des passeports ou des orientations sexuelles, il faut au minimum répondre quand quelqu’un vous dit que vous êtes en train de les exposer. C’est une catastrophe totale, et l’absence de sécurité ici atteint un niveau absolument inacceptable
  • Si on ne connaît rien à la sécurité applicative, il ne faut tout simplement pas faire d’app. Je vais parler sous le coup de l’émotion, mais quand je vois des amis utiliser des apps de rencontre, l’idée que leurs informations puissent être exposées est terrifiante. Les personnes qui ont fait ça devraient avoir honte. Elles devraient aussi avoir honte d’avoir ignoré les messages d’un chercheur en sécurité. Si on m’avait traité comme ça, j’aurais écrit un billet de divulgation bien plus direct. J’aimerais vraiment qu’on arrête de faire des apps, s’il vous plaît

• En tant que développeur dans une petite entreprise, je m’inquiète parfois de ma responsabilité personnelle. Beaucoup d’entreprises opèrent hors de secteurs soumis à des réglementations comme PCI ou HIPAA. Dans les petites structures, la sécurité est perçue non pas comme un enjeu de toute l’organisation, mais comme un problème d’ingénierie. L’équipe produit se concentre sur les fonctionnalités, les PM sur le planning, la QA sur les bugs, et rares sont ceux qui parlent de sécurité. L’ambiance, c’est que les ingénieurs n’ont qu’à faire les tâches qui leur sont assignées. Si un ingénieur essaie aussi de s’occuper de sécurité, il peut même se faire reprocher de ralentir les choses par les PM ou d’autres. Et on entend toujours les mêmes phrases : « Ça va prendre combien de temps ? », « Quelle est la probabilité que ça arrive vraiment ? », « Sortons vite le MVP et on corrigera plus tard », etc. Du coup, en tant que salarié, je finis par faire ce que l’entreprise me demande. Mais je m’inquiète régulièrement de savoir si, en cas de piratage ou de fuite puis de procès, je pourrais me retrouver seul à porter la responsabilité en tant qu’ingénieur qui « aurait dû mieux savoir »

  • En pratique, comme vous n’êtes pas l’ingénieur certificateur qui signe les documents et garantit la sûreté, vous ne serez probablement pas tenu pour responsable, même si le système se révèle non sûr
  • Si l’entreprise est une LLC ou une Corp, vous êtes protégé par le corporate veil. À moins d’avoir commis un acte criminel consigné noir sur blanc, il n’y a pas grand-chose à craindre. Cela dit, l’absence de standards de sécurité est un énorme problème à toutes les échelles d’entreprise. Sortir de nouvelles fonctionnalités passe presque toujours avant la sécurité
  • En tant qu’ingénieurs dans de petites organisations, je pense que c’est notre responsabilité d’éduquer l’équipe sur ces risques et de défendre fermement du temps de développement consacré à la sécurité. Ce n’est pas facile, mais négliger cet aspect peut mettre l’entreprise elle-même en danger
  • À votre place, je connaîtrais suffisamment le droit pour pouvoir me protéger, je m’opposerais par écrit à toute demande illégale et j’exigerais aussi une validation écrite si on me disait d’ignorer le problème. Mais dans une petite startup, même ça peut être difficile. Si j’avais le sentiment que ce n’est pas légal, je démissionnerais simplement
  • Je n’aime pas la défense du type « je ne faisais qu’obéir aux ordres », mais dans ce genre de situation, il faut absolument laisser des traces écrites : signaler par mail qu’il y a un problème de sécurité, puis conserver la preuve qu’un supérieur répond quelque chose comme « pas la peine de s’en préoccuper ». À ma connaissance, je n’ai jamais vu un employé non dirigeant être personnellement poursuivi pour une fuite de données. En général, personne n’est vraiment tenu responsable et l’entreprise paie juste une amende symbolique
  • Si vous n’êtes pas dirigeant de l’entreprise, je ne pense pas que vous ayez à craindre une responsabilité personnelle
  • D’après mon expérience, non, ça n’arrive pas

• Pour réduire la responsabilité juridique du chercheur, je pense qu’il suffirait de créer un autre compte, ou d’obtenir l’accès avec le consentement d’un ami via un profil créé à cette fin. Il n’y a pas besoin d’aspirer réellement les données : par exemple, si mon id est 12345 et celui de mon ami 12357, on peut démontrer qu’on accède au profil d’un autre compte avec les id intermédiaires. Comme beaucoup l’ont déjà dit, il n’est pas nécessaire d’accéder aux données personnelles de milliers de personnes ; il suffit d’établir et de divulguer l’existence de la faille

  • C’est une méthode standard et évidente que tout chercheur en sécurité connaît. On peut avoir envie de récupérer des données sensibles pour « prouver » le problème, mais c’est inutile et, au fond, assez hypocrite

• Ce billet lui-même me semble assez confus. Il explique que l’API qui reçoit l’OTP (mot de passe à usage unique) est si simple que l’OTP est renvoyé directement dans la réponse du serveur, ce qui permettrait à n’importe qui d’accéder à un compte s’il connaît le numéro de téléphone. Si l’API est juste de la forme otp/numéro-de-téléphone et que l’OTP revient dans la réponse, alors il suffit visiblement de deviner le numéro pour obtenir aussi le code. Ensuite, il dit avoir énuméré les ID utilisateurs par script, en s’arrêtant après 1 000 ID vides consécutifs, ce qui lui a permis d’identifier 6 117 utilisateurs, 207 pièces d’identité et 19 étudiants de Yale. Mais accéder ainsi aux données personnelles d’autrui sans consentement ressemble, même à plus petite échelle, à l’affaire weev et du piratage d’AT&T qui l’a mené en prison. Ce type de recherche est juridiquement risqué, et il est inquiétant que l’auteur semble méconnaître un environnement légal qui ne protège pas les chercheurs en sécurité

  • Il est fait mention du fait que l’API otp/numéro renvoyait directement l’OTP final. Autrement dit, si on connaît le bon numéro de téléphone, on récupère immédiatement l’OTP
  • Si vous lisez la plainte initiale dans l’affaire Auernheimer, il y avait là — contrairement à ce cas — suffisamment d’éléments pour établir une intention criminelle. Ils étaient aussi accusés d’avoir effectivement diffusé des données personnelles à l’extérieur, donc la situation n’est pas équivalente à ce point-là

• J’ai eu une expérience similaire : en voulant signaler un bug sur une autre app de rencontre, je n’arrivais pas à les contacter, alors j’ai modifié le profil du fondateur pour y mettre « contactez-moi », et ils l’ont restauré via une sauvegarde. Quelques années plus tard, j’ai revu cette app dans une pub Instagram et j’ai réessayé : exactement la même faille existait toujours. N’importe qui connaissant simplement l’endpoint API peut obtenir les privilèges admin, ainsi que l’accès à tous les messages et à tous les matchs. J’hésite à reprendre contact

  • Il est suggéré de les contacter, de préciser qu’on agit en développeur responsable, puis de se contenter de révéler le problème avant de passer à autre chose

• Je pense qu’il faut vraiment réfléchir à deux fois avant de collecter dans une app des données sensibles comme un passeport ou une adresse. Ce n’est pas quelque chose qu’on peut balayer d’un revers de main en disant « c’est une app faite par des étudiants »

  • Le gouvernement britannique essaie de rendre les pièces d’identité obligatoires pour accéder aux sites porno, et j’attends de voir quels en seront les résultats
  • Si l’app recueille des informations de pièce d’identité comme un passeport, celles-ci ne devraient jamais avoir besoin d’être exposées à l’extérieur après la saisie. Si l’API sert à afficher les données d’identité dans l’UI, il suffirait de renvoyer uniquement les derniers chiffres au lieu du numéro complet. Pour une app de rencontre, il devrait suffire de renvoyer un booléen ou un enum indiquant si l’identité est vérifiée ou non (non vérifié / passeport / permis de conduire, par exemple). Les systèmes comme les apps de compagnies aériennes, où il faut sélectionner un document précis, sont un cas particulier, mais même l’app United, par exemple, n’affiche que les derniers chiffres ; j’aimerais que les API internes soient limitées de cette manière aussi
  • Un lien est partagé vers le GDPR (règlement européen sur la protection des données)
  • Je pense qu’il faudrait carrément un service de vérification d’identité sûr et privé opéré par l’État. Ou alors par une entreprise jouant un rôle de « quasi-État » comme Apple ou Google
  • En général, on utilise plutôt un service tiers de vérification d’identité, mais je me demande si ce genre de service transmet vraiment jusqu’aux images de pièces d’identité à l’app elle-même

• Le fait de renvoyer l’OTP tel quel dans la réponse de l’API est tellement absurde. Je ne comprends pas pourquoi

  • Ils l’ont probablement fait pour pouvoir comparer immédiatement avec la saisie dans l’UI. Si on ne pense pas à la sécurité, ça peut sembler plausible. Les apps de rencontre brassent une quantité énorme de données personnelles, donc ce genre d’erreur est affreux
  • Comme ça, on réduit d’un coup les coûts de base de données
  • On peut facilement laisser passer ce genre de modèle dans un POC ou un MVP quand, après avoir généré l’OTP, on renvoie directement la réponse de la DB ou du cache
  • Il semble que l’OTP soit exposé directement dans la « réponse à la demande d’envoi du mot de passe à usage unique ». Cela peut venir du fait que le framework sérialise l’objet complet de la base de données pour le renvoyer en HTTP
  • En apparence, c’est séduisant : on économise une requête HTTP et l’UX est plus rapide. Pinterest aussi a déjà exposé dans une ancienne API toutes les informations, y compris le secret 2FA. Je l’avais signalé et j’avais même reçu une récompense, mais ce genre d’erreur arrive parfois même dans la big tech
  • Moi non plus, je ne comprends pas. J’ai l’impression que c’est juste une erreur faite pour simplifier la construction du formulaire

• Quelqu’un partage un lien vers un autre article lié dans le Yale Daily News

• J’aimerais qu’il existe des lois traitant les données personnelles comme des déchets nucléaires. En cas de fuite, non seulement l’entreprise devrait faire faillite, mais les responsables devraient aussi se retrouver en difficulté sur le plan judiciaire. Aujourd’hui, il est non seulement trop facile de collecter les données des utilisateurs, mais en plus, après une fuite, il suffit de s’excuser et de passer à autre chose

  • Traiter les PII comme du nucléaire me paraît excessif. Une adresse e-mail, utilisée uniquement pour l’authentification ou le contact, n’a rien de particulièrement problématique
  • Il faudrait peut-être au moins un peu de prison en col blanc pour que les gens commencent vraiment à s’y intéresser

• Je viens seulement de découvrir l’outil Charle's Proxy sur iOS. Par le passé, je faisais du pentest en recherchant directement des chaînes dans les binaires d’apps. Ça a l’air d’être d’une aide énorme pour analyser des apps iOS

  • C’est un bon outil, je le recommande (sauf en cas de SSL pinning)