Avoir piraté une appli de rencontre, et la mauvaise façon de traiter les chercheurs en sécurité

 (alexschapiro.com)
2 points par GN⁺ 2025-05-13 | 1 commentaires | Partager sur WhatsApp
  • L’application de rencontre Cerca combinait une connexion par numéro de téléphone et une API exposée, dans un état risqué où le code d’authentification figurait directement dans la réponse OTP, ouvrant potentiellement l’accès aux données personnelles
  • Sur api.cercadating.com, l’ajout de l’en-tête de version de l’app exposait les endpoints via openapi.json dans /docs, et certaines requêtes permettaient même de manipuler la logique métier, par exemple pour forcer un match
  • user/{user_id} renvoyait des PII avec un simple ID utilisateur valide — nom, localisation, date de naissance, école, numéro de téléphone, e-mail, état du profil, etc. — ce qui, combiné à la faille OTP, pouvait mener à une prise de contrôle de compte
  • Une fois l’accès au compte obtenu, il était possible, pour les utilisateurs ayant soumis ces données, d’accéder à des informations de passeport ou de carte d’identité, à des URL de selfie et à des messages privés ; un script de vérification a recensé 6 117 utilisateurs, 207 ayant saisi des informations d’identité, et 19 indiqués comme étudiants de Yale
  • La vulnérabilité a été signalée à Cerca le 23 février 2025 et un appel a eu lieu le 24 février, mais jusqu’à la divulgation du 21 avril, il n’y a eu ni réponse de suivi ni notification aux utilisateurs ; seul le correctif a été vérifié indépendamment

Une réponse interrompue après le signalement

  • L’application de rencontre Cerca présentait une vulnérabilité de sécurité pouvant exposer des messages privés, des informations de passeport, des préférences sexuelles et d’autres données personnelles
  • Après la découverte de la faille, un e-mail a été envoyé à l’équipe de Cerca le 23 février 2025, puis un appel vidéo le lendemain a permis de discuter de la vulnérabilité, des mesures d’atténuation et des suites à donner
  • L’équipe de Cerca a reconnu la gravité du problème, remercié pour la divulgation responsable et promis de corriger la faille ainsi que d’informer les utilisateurs concernés
  • Des demandes de mise à jour sur le correctif et le plan de notification ont ensuite été envoyées les 5 et 13 mars, mais aucune réponse n’est arrivée avant la publication du 21 avril 2025
  • Avant la divulgation, le fait que la vulnérabilité avait été corrigée a été vérifié indépendamment, ce qui a motivé la publication

Un accès aux comptes qui commence avec la connexion OTP

  • L’application utilisait uniquement une connexion par OTP envoyée au numéro de téléphone
  • Pour inspecter les requêtes réseau, Charles Proxy a été utilisé sur l’application iPhone afin d’intercepter les requêtes
  • La réponse qui déclenchait l’OTP contenait directement le mot de passe à usage unique
  • Dans cette architecture, connaître le numéro de téléphone d’un utilisateur suffisait pour accéder à son compte
  • Il fallait donc trouver un autre moyen d’obtenir les numéros de téléphone des titulaires de compte, ce qui a conduit à l’exploration des endpoints de l’API

Des endpoints révélés par la documentation OpenAPI

  • Un fuzzer de répertoires a été utilisé sur api.cercadating.com pour énumérer les chemins
  • Sans les en-têtes liés à l’application, aucune partie du site n’était accessible
  • En ajoutant ces en-têtes à Gobuster, l’endpoint /docs a été trouvé, avec un openapi.json disponible à cet emplacement
  • La fonction match-and-replace de Burp Suite a été configurée pour toujours ajouter l’en-tête de version de l’application ainsi que le bearer token extrait via Charles Proxy
  • Certains endpoints non protégés avaient un impact sur la logique métier, et permettaient même des requêtes pour forcer une mise en relation entre deux personnes

Exposition des profils utilisateurs et des données personnelles

  • L’endpoint user/{user_id} renvoyait de nombreuses données personnelles dès lors qu’un ID utilisateur valide était fourni
  • La réponse incluait notamment :
    • nom, sexe, sexe recherché, ville, latitude et longitude
    • e-mail universitaire et statut de vérification, secteur, profession, date de naissance, taille
    • ID de l’école et nom de l’école, état de complétion du profil
    • statut de vérification de l’identité nationale, vérification du mobile et de l’e-mail
    • statut premium, état actif/suspendu/onboarding du compte
    • numéro de téléphone, e-mail, ID utilisateur, nombre de recherches restantes
    • image de profil, préférences de matching, prompts utilisateur, coordonnées mutuelles, dates de création et de modification, âge, etc.
  • Un script Python permettait de trouver des ID utilisateurs valides et d’énumérer massivement les données des utilisateurs
  • Les numéros de téléphone renvoyés pouvaient être combinés avec la faille OTP pour obtenir un accès complet aux comptes
  • Les données personnelles des utilisateurs étaient donc exposées même sans passer par la connexion OTP

Un accès allant jusqu’aux pièces d’identité et aux messages privés

  • Le champ national_id_verified montrait que des informations de passeport ou de carte d’identité étaient stockées dans le système
  • Les réponses liées aux pièces d’identité incluaient les informations suivantes :
    • verification_type: PASSPORT
    • document_number
    • front_side_url
    • back_side_url
    • selfie_url
    • statut, ID, ID utilisateur
  • Ces informations n’étaient fournies qu’à l’utilisateur connecté, mais la faille OTP permettait de se connecter comme n’importe quel utilisateur
  • Il était donc techniquement possible de consulter les informations d’identité de toute personne les ayant soumises, même si l’auteur précise ne pas l’avoir fait
  • Il était également possible de voir les messages privés échangés avec de potentiels partenaires, ainsi que les informations de passeport lorsque celles-ci avaient été soumises

L’ampleur de l’exposition confirmée

  • Un script rapide a permis de compter le nombre d’utilisateurs dont les informations étaient accessibles, le nombre d’utilisateurs enregistrés comme étudiants de Yale et le nombre d’utilisateurs ayant saisi des informations d’identité
  • Le script s’arrêtait après 1 000 ID consécutifs sans trouver d’ID valide
  • Cette méthode n’exclut pas qu’il y ait davantage d’utilisateurs
  • Cerca a indiqué avoir atteint 10 000 utilisateurs dès sa première semaine
  • Les chiffres confirmés sont les suivants :
    • 6 117 utilisateurs
    • 207 utilisateurs ayant saisi des informations d’identité
    • 19 utilisateurs indiqués comme étudiants de Yale

Promesses de protection des données et risque réel

  • La politique de confidentialité de Cerca affirme que les données sont protégées « par le chiffrement et d’autres mesures conformes aux standards de l’industrie »
  • Comparée à l’état réel de la vulnérabilité, cette formulation est trompeuse
  • Les données exposées pouvaient inclure des préférences sexuelles, des messages privés et diverses informations personnelles
  • Si un acteur malveillant y accédait, cela pouvait mener à des usurpations d’identité, du harcèlement ou du chantage
  • Les applications de rencontre traitent des données sensibles : la sécurité des données utilisateurs doit donc primer sur la vitesse de lancement d’une application

À lire aussi

1 commentaires

 
GN⁺ 2025-05-13
Avis sur Hacker News

  • Cette appli semble être un projet assez rudimentaire réalisé par des étudiants. Bien sûr, ils devraient faire de leur mieux pour appliquer de bonnes pratiques de sécurité et de communication, mais quand on voit que des « entreprises adultes » ayant levé beaucoup d’argent auprès de VC réagissent n’importe comment à des problèmes similaires, je n’ai pas trop envie de les accabler
    https://georgetownvoice.com/2025/04/06/georgetown-students-c...

    • Je ne suis absolument pas d’accord. Dire « ils ne savaient pas ce qu’ils faisaient, donc ne les jugeons pas trop sévèrement » est étrange. S’ils ne savaient pas ce qu’ils faisaient mais sont quand même allés jusqu’au lancement, ce n’est pas une circonstance atténuante, c’est plutôt aggravant
      C’est un peu comme un conducteur qui tue quelqu’un dans un accident, et dont on découvre ensuite qu’il n’avait même pas le permis
    • En cherchant des informations sur « Cerca », je suis tombé sur le même lien ; l’article date d’avril 2025 et fait l’éloge d’une appli créée deux mois plus tôt, donc ça ressemble à un texte poubelle halluciné par un LLM
      Le billet original dit qu’ils ont contacté l’équipe de Cerca en février, donc soit la faille a été découverte le jour du lancement, soit il y a quelque chose de bizarre dans la chronologie. Dans tous les cas, c’est à la fois une « vulnérabilité vieille de deux mois » et une « appli/service étudiant vieux de deux mois »
    • Si l’appli est publiée au nom de Cerca Applications, LLC, comment savoir s’il s’agit simplement de quelques script kiddies à qui il faudrait passer l’éponge ?
    • Ces personnes feraient probablement mieux d’étudier autre chose.
    • L’argument se tient, mais là, c’est quand même trop. Ne pas renvoyer dans le corps de la réponse un OTP censé rester secret, c’est quasiment du bon sens, que l’on soit développeur expérimenté ou lycéen
      En plus, ce n’est pas un truc fait pour s’amuser, c’est un produit commercial. Les achats intégrés listés sont 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

  • En tant qu’ingénieur dans une petite entreprise, je m’inquiète parfois de ma responsabilité personnelle. Il y a énormément d’entreprises dans des secteurs non réglementés, qui ne relèvent ni de PCI ni de HIPAA, et dans les petites structures, la sécurité n’est pas traitée comme une obligation au niveau de l’organisation, mais reléguée au rang de simple sujet d’ingénierie
    L’équipe produit se concentre sur les fonctionnalités, le PM sur les délais, la QA sur la recherche de bugs, et rares sont ceux qui s’expriment de manière raisonnable sur la sécurité. On n’attend pas d’un ingénieur davantage que de terminer les tâches inscrites au tableau. Si on peut rendre les choses sûres sans impact sur le planning, tant mieux ; sinon, on subit la pression du PM ou d’autres personnes
    On entend des choses comme « ça prendrait combien de temps ? », « quel est le risque que ça arrive vraiment ? », « on s’occupera de la sécurité plus tard, sortons d’abord le MVP pour les clients ». En tant qu’employé, je fais ce que mon employeur me demande, mais si l’entreprise est poursuivie à cause d’un piratage ou d’une fuite de données, est-ce que je risque d’être personnellement responsable parce que je suis la seule personne qui « aurait dû savoir » ?

    • À proprement parler, ce n’est pas vraiment un ingénieur au sens de l’ingénierie réglementée. Il ne signera probablement pas de plans de conception certifiant la sécurité, et il ne sera pas tenu responsable si ceux-ci se révèlent dangereux
    • S’il s’agit d’une LLC ou d’une société, il y a de bonnes chances d’être protégé par le voile de la personnalité morale, sauf à avoir laissé par écrit la preuve d’un acte criminel
      Cela dit, le manque de standards de sécurité à l’échelle de l’organisation, quelle que soit sa taille, est désolant. La sortie de nouvelles fonctionnalités semble toujours passer avant la garantie de bonnes pratiques de sécurité
    • Personnellement, je voudrais connaître suffisamment le droit pour me protéger, m’opposer par écrit à tout ce qui est illégal, et obtenir aussi une validation écrite quand on me demande de l’ignorer
      Cela dit, je comprends que ce soit difficile dans une startup où il n’y a qu’un ou deux développeurs. Si j’avais l’impression qu’on ne cherche pas à agir légalement, je pense que je partirais
    • En tant qu’ingénieur dans une petite organisation, j’estime qu’on a la responsabilité de sensibiliser le reste de l’équipe à ce risque de sécurité et de pousser pour obtenir du temps d’ingénierie afin de l’atténuer
      Ce n’est pas facile, mais c’est un sujet important qui peut faire couler l’entreprise elle-même s’il n’est pas pris au sérieux
    • Même si je n’aime pas la défense du type « je n’ai fait qu’obéir aux ordres », dans ce genre de cas, il faut absolument laisser une trace écrite
      Il faut un historique d’e-mails où l’on soulève des inquiétudes sur le manque de sécurité, et une réponse du supérieur indiquant de ne pas s’en préoccuper. Je ne sais pas dans quelle juridiction cela se passe, mais je ne connais pas de cas où un simple employé a été tenu légalement responsable personnellement d’une fuite de données. En général, les fuites de données n’entraînent aucune conséquence réelle pour personne, et l’entreprise s’en sort avec une amende symbolique

  • Pour réduire son exposition juridique en tant que chercheur, il aurait probablement suffi de créer un second compte, ou de demander à un ami de créer un profil et de donner son consentement pour y accéder
    Il n’est pas nécessaire d’aspirer réellement des données pour démontrer une vulnérabilité d’énumération. Si mon ID est 12345 et qu’un ami s’inscrit et reçoit 12357, cela suffit à prouver qu’on peut trouver l’ID de n’importe quel utilisateur et accéder à son profil
    Comme d’autres l’ont dit, il n’est pas nécessaire d’accéder à autant d’informations personnelles identifiables d’autres utilisateurs pour vérifier et divulguer la vulnérabilité

    • C’est la méthode standard et évidente que la plupart des chercheurs en sécurité ignorent
      Vouloir que les informations personnelles identifiables soient protégées tout en les aspirant pour le prouver est inutile et hypocrite

  • Le billet est assez confus. Dans la connexion basée sur OTP, le passage disant que l’OTP est renvoyé tel quel dans la réponse à la demande de mot de passe à usage unique manque d’explications, mais cela semble probablement vouloir dire qu’avec une API du type api.cercadating.com/otp/, si l’on devine un numéro de téléphone, on peut recevoir le code OTP sans posséder ce numéro
    Il dit aussi avoir trouvé 6 117 personnes avec un script qui s’arrête lorsqu’il ne trouve aucun utilisateur valide sur 1 000 identifiants consécutifs, 207 personnes ayant renseigné des informations de pièce d’identité, et 19 se déclarant étudiants à Yale ; je ne sais pas si l’auteur réalise à quel point c’est dangereux. En pratique, c’est proche de la méthode utilisée par weev pour compromettre AT&T, et il est allé en prison[0]
    C’était une plus grosse entreprise et une plus grosse fuite, mais je ne pense pas que je me vanterais publiquement d’avoir accédé sans autorisation aux données de milliers de personnes en exploitant une faille de sécurité. Je ne cherche pas à juger la morale de l’affaire, et je pense qu’il doit y avoir une marge pour que les chercheurs en sécurité puissent alerter, mais la loi est largement défavorable aux chercheurs en sécurité
    [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

    • Il a mentionné la devinette de numéros de téléphone, et il est bien indiqué que l’appel API qui envoie l’OTP renvoie littéralement l’OTP
    • Si l’on lit la plainte initiale dans l’affaire Auernheimer, l’accusation disposait de nombreuses preuves d’intention qui n’existent probablement pas ici
      Les prévenus dans cette affaire étaient aussi accusés d’avoir publié des informations personnelles identifiables de base, ce qui ne semble pas avoir été le cas ici

  • J’ai vécu quelque chose de similaire avec une autre app de rencontre, et ils n’ont finalement jamais répondu. Pour attirer l’attention du fondateur, j’ai modifié sa bio en « contactez-moi », et ils ont restauré une sauvegarde
    Quelques années plus tard, j’ai vu une publicité Instagram et j’ai vérifié si le problème existait encore : il était toujours là. Avec simplement les endpoints API faciles à trouver via app-proxy-serveur, n’importe qui pouvait obtenir des droits d’administration complets et accéder à tous les messages, matchs, etc.
    Je me demande si je devrais y retourner et réessayer

    • En développeur responsable, il suffirait peut-être de faire une divulgation de vulnérabilité via les coordonnées de contact et de s’arrêter là

  • Avant de demander aux gens des informations sensibles comme un passeport ou une adresse, il faudrait les obliger à y réfléchir à deux fois. On ne peut pas balayer ça d’un revers de main en disant que ce sont juste des gamins qui ont fait une app

    • Les informations de passeport ou d’autres pièces d’identité n’ont absolument aucune raison d’être exposées publiquement après saisie. Même s’il faut récupérer des données via l’API pour les afficher dans l’UI, il n’est pas nécessaire d’inclure le numéro complet de passeport ou de pièce d’identité ; au minimum, il peut être masqué pour ne transmettre que les derniers chiffres
      Pour un site de rencontre, il suffit que l’API renvoie un booléen verified/not-verified pour l’état de la pièce d’identité, ou une valeur énumérée comme « not-verified », « passport », « drivers-license ». Il n’y a aucun besoin réel d’afficher les détails côté client/UI
      Les apps de compagnies aériennes, où l’on doit choisir un document d’identité à des fins d’immigration, peuvent exceptionnellement afficher davantage d’informations, mais il suffit de montrer les derniers chiffres du numéro de passeport, comme dans l’app United. J’aimerais que même les API internes n’envoient que cela
    • Le gouvernement britannique pousse fort pour rendre obligatoire la vérification d’identité afin d’accéder aux sites porno ; j’attends avec impatience le jour où ça leur explosera à la figure
    • Il faudrait un service de vérification d’identité sûr et privé, géré par l’État
      Ou, à défaut, confié à un acteur « quasi gouvernemental » comme Apple ou Google
    • Il suffit de regarder le RGPD
      https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
    • Ils n’utilisaient pas de service tiers de vérification d’identité ? En général, les apps traitent ça de cette façon. J’espère quand même que ces services tiers ne renvoient pas directement à l’app les originaux des pièces d’identité, comme les images réelles

  • Ça n’a aucun sens qu’une réponse d’API de demande renvoie l’OTP. Pourquoi auraient-ils fait ça ?

    • C’était peut-être pour laisser l’UI vérifier que la valeur saisie par l’utilisateur est correcte
      Si l’on ne pense pas à la sécurité, c’est une solution très plausible et évidente. Les apps de rencontre font partie des types d’apps les plus dangereux à développer, car elles contiennent nécessairement beaucoup d’informations personnelles identifiables, et là c’est catastrophique
    • Ils ont peut-être généré et stocké l’OTP, puis renvoyé tel quel la réponse de la base de données, du cache, etc.
      Dans un proof of concept rapide ou un MVP, on réutilise souvent le modèle de stockage directement comme réponse d’API pour gagner du temps, donc c’est facile à rater
    • C’est une astuce simple pour supprimer les coûts de base de données
    • Ça économise une requête HTTP et accélère aussi l’expérience utilisateur. Qu’y aurait-il à ne pas aimer ?
      Quand la nouvelle API de Pinterest est sortie, elle diffusait toutes les informations utilisateur à toutes les apps utilisant l’intégration OAuth, y compris les secrets d’authentification à deux facteurs. Je l’ai signalé et j’ai reçu une prime, mais ce genre de chose arrive même dans les API de grandes entreprises qui devraient pourtant être mieux informées
    • Il semble que l’OTP ait été envoyé dans la « réponse qui a déclenché le mot de passe à usage unique »
      C’est peut-être la faute du framework. Probablement une architecture où l’objet inséré en base de données était directement sérialisé par l’ORM ou un autre système de stockage, puis renvoyé dans la réponse HTTP

  • https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
    Un autre article sur cette affaire

    • « Les développeurs doivent utiliser les bonnes pratiques, mais cela peut ne pas suffire. Garder les données en sécurité est un problème non résolu » : ah, d’accord. On n’y peut rien, alors

  • J’aimerais qu’il existe une loi rendant le stockage d’informations personnelles identifiables aussi dangereux que le stockage de déchets nucléaires. En cas de fuite, l’entreprise devrait presque certainement faire faillite, et les responsables devraient s’exposer à des risques juridiques
    À mon avis, c’est la meilleure façon d’aligner correctement les incitations. Aujourd’hui, il n’y a presque aucun inconvénient à stocker autant d’informations utilisateur que possible. Une fuite de données ? On publie un tweet d’excuses et on continue

    • Traiter les informations personnelles identifiables comme des déchets nucléaires me paraît un peu extrême. Les informations personnelles identifiables incluent aussi des données relativement inoffensives, comme les adresses e-mail utilisées pour l’authentification et le contact
    • Il faudrait peut-être une prison pour cols blancs
      C’est peut-être ce qui permettrait à ce problème de recevoir l’attention qu’il mérite

  • Si « vous n’avez reçu aucune réponse », c’est le moment d’indiquer que, si le silence se poursuit, la vulnérabilité sera divulguée au bout de 90 jours

    • Ce serait une sanction plus lourde pour des utilisateurs innocents que pour l’entreprise
    • Ici, il n’y a même pas vraiment de vulnérabilité à proprement parler. C’est simplement laissé ouvert au grand jour
    • En faisant cela, vous vous engagez sur une voie idéale pour vous faire poursuivre en justice, voire faire l’objet de poursuites pénales