Un adolescent de 15 ans gagne 50 000 $ en découvrant un bug de porte dérobée dans Zendesk

• Un adolescent de 15 ans, qui pratique le bug hunting pendant son temps libre, a découvert un bug lié à la vérification des e-mails dans Zendesk, utilisé par des entreprises du Fortune 500
• En l’ayant signalé à plusieurs entreprises, il a gagné plus de 50 000 $, mais cet article raconte aussi comment Zendesk a corrigé le problème sans jamais verser la moindre récompense au chercheur

Présentation de Zendesk

• Zendesk est un outil de service client utilisé par certaines des plus grandes entreprises du monde
• Lorsqu’une entreprise connecte son e-mail de support à Zendesk, celui-ci gère les e-mails entrants et crée des tickets
• Il est surprenant de voir autant de grandes entreprises dépendre de Zendesk au lieu de construire leur propre système de tickets

Le maillon le plus faible

• Comme le dit l’expression « aussi fort que son maillon le plus faible », Zendesk est souvent perçu comme un simple outil de tickets et utilisé sans configuration suffisamment prudente
• Lorsqu’un domaine comme « @company.com » est utilisé pour le single sign-on (SSO) et connecté à Zendesk, cela peut créer une faille de sécurité
• Comme Zendesk traite les e-mails du domaine, si le système SSO ne vérifie pas correctement les adresses e-mail, toute personne ayant accès à Zendesk peut potentiellement abuser des systèmes internes

Usurpation d’e-mail

• Une vulnérabilité critique a été découverte dans Zendesk, permettant à un attaquant de lire les tickets du support client d’une entreprise utilisant Zendesk
• Zendesk ne disposait pas de protections efficaces contre l’usurpation d’e-mail
• Si un attaquant connaissait l’adresse e-mail du support et l’identifiant du ticket, il pouvait accéder au ticket en se faisant passer pour l’expéditeur d’origine via l’usurpation d’e-mail
• L’auteur a signalé le bug, mais Zendesk n’y a d’abord pas prêté attention
  • Il lui a été répondu que l’usurpation d’e-mail (problèmes SPF, DKIM, DMARC) était hors périmètre
• Le signalement a été traité via HackerOne, et sa demande de le transmettre directement à un membre de l’équipe Zendesk a été refusée

Escalade du problème jusqu’à la prise de contrôle de Slack

• L’auteur aurait pu signaler le bug à chaque entreprise individuellement, mais il voulait obtenir un impact plus important
• Dans le passé, un autre chercheur avait déjà compromis le Slack de centaines d’entreprises via Zendesk (TICKETTRICK)
• L’auteur a essayé de reproduire cela avec son propre bug, mais a rencontré plusieurs difficultés
• Slack avait modifié son système pour vérifier les adresses e-mail en y ajoutant un jeton aléatoire
• Toutefois, lors de la connexion avec un identifiant Apple via OAuth, ce jeton n’était pas utilisé, ce qui permettait de contourner la protection

Étapes de reproduction : Apple → Zendesk → Slack

1. Créer un identifiant Apple avec « [e-mail] » et demander un code de vérification, ce qui génère un ticket Zendesk
2. Créer un ticket avec sa propre adresse e-mail sur le portail de support de company.com afin de suivre la plage d’identifiants
3. Utiliser le bug d’usurpation d’e-mail pour tenter de s’ajouter à tous les tickets de cette plage d’identifiants
4. Se connecter au portail de support de l’entreprise avec le compte [e-mail] et vérifier les tickets mis en copie
5. Saisir le code de vérification dans l’identifiant Apple
6. Utiliser la fonctionnalité « Se connecter avec Apple » de Slack avec l’identifiant Apple lié à une adresse @company.com pour se connecter à Slack
   L’auteur a appliqué ces 6 étapes à des centaines d’instances Zendesk et Slack

Les conséquences de l’affaire

• Pendant une semaine, l’auteur a signalé individuellement la vulnérabilité à plusieurs entreprises ; certaines ont agi immédiatement, tandis que d’autres ont affirmé qu’il s’agissait d’un problème de Zendesk
• Après que certaines entreprises ont contacté Zendesk, Zendesk a finalement demandé que le signalement reste privé et a réclamé les étapes de reproduction de la vulnérabilité Slack
• Après la remise d’une preuve de concept de prise de contrôle de Slack, Zendesk a confirmé le problème mais a mis 2 mois à le corriger
• De nombreuses entreprises ont protégé leur instance en désactivant les fonctions de collaboration par e-mail
• Grâce à ce signalement bug bounty, l’auteur a reçu plus de 50 000 $ de récompenses de la part d’entreprises individuelles sur HackerOne et d’autres plateformes
• Certaines entreprises ont résilié leur contrat avec Zendesk

La correction de Zendesk et ma prime de 0 dollar

• Deux mois plus tard, Zendesk a confirmé avoir résolu le problème
• Zendesk utilisait les filtres anti-spam Cloudmark et Rspamd EAP, mais comme le score Rspamd n’était pas exploité, de nombreux e-mails n’étaient pas retenus
• La première correction consistait à basculer automatiquement vers Rspamd dans certaines conditions
• Ensuite, un filtre a été mis en place pour mettre automatiquement en attente les e-mails de vérification d’Apple et Google
• Malgré la correction du problème, Zendesk a finalement décidé de ne pas verser de récompense pour ce signalement de bug bounty
  • Selon Zendesk, l’auteur avait enfreint les règles de divulgation de HackerOne en partageant la vulnérabilité avec les entreprises affectées

Conclusion

• Un petit bug lié aux e-mails a conduit à la compromission de systèmes internes de certaines des plus grandes entreprises du monde
• Zendesk a fini par corriger la vulnérabilité, mais le processus a été difficile entre refus, lenteur de réaction et ignorance du signalement
• C’est la réalité du bug hunting : parfois on gagne, parfois on perd

L’avis de GN⁺

• L’affaire Zendesk montre les risques d’une adoption non critique de solutions tierces. Même pour les produits d’entreprises très connues, un audit de sécurité reste indispensable.
• La compromission de systèmes internes de grandes entreprises peut provoquer des dégâts considérables, et la lenteur de réaction de Zendesk a été très irresponsable. Refuser de payer une prime démotive aussi les chercheurs en sécurité.
• Les entreprises doivent choisir avec soin leur domaine SSO et renforcer leur processus de vérification des e-mails. Il faut utiliser activement des technologies d’authentification e-mail comme DMARC, SPF et DKIM.
• Les règles de divulgation de HackerOne sont trop rigides du point de vue des chercheurs. Pour les vulnérabilités graves, un partage rapide est nécessaire, et une application plus souple selon le contexte semble souhaitable.
• Le bug hunting devrait être gagnant-gagnant pour les entreprises comme pour les chercheurs. On peut espérer l’émergence d’une culture qui respecte la bonne foi et les efforts des chercheurs et les récompense de manière appropriée.

[aer0700]

Quand on voit ce genre de problème, on se dit qu’en matière de sécurité, il vaut bien mieux faire venir des experts et les former en interne que simplement utiliser des solutions toutes faites, snif snif

[GN⁺]

Avis Hacker News

• Un utilisateur mentionne avoir signalé le même bug à Zendesk, Apple et Slack en juin 2024, et que la raison pour laquelle ils n’ont probablement pas versé de récompense est qu’il n’était sans doute pas le premier

  • L’option SSO non-directory, Sign in with Apple (SIWA), a été mal implémentée, et c’est également le cas dans de grandes entreprises comme Slack
  • Un SSO non-directory ne peut pas bénéficier du même niveau de confiance qu’un SSO directory, et les fournisseurs de SSO ne sont pas interchangeables entre eux, même s’ils utilisent la même adresse e-mail

• Un autre utilisateur affirme que Zendesk a créé un faux groupe appelé "Zendesk Alternative" pour polluer les résultats de recherche Google

  • Il précise que ce n’est pas illégal, mais que c’est une pratique manipulatrice qui en dit long sur leur façon de penser

• Un utilisateur se dit déçu que Zendesk ait refusé de récompenser le bug, ajoutant que c’est le meilleur moyen de dissuader de participer à de grands programmes de récompense

  • Il ajoute que son expérience d’entretien avec Zendesk a été très mauvaise

• Un autre utilisateur indique que les programmes de bug bounty inefficaces ont un impact négatif sur les services logiciels

  • Il soutient que Zendesk devrait verser une récompense, présenter des excuses et corriger son programme

• Un utilisateur critique la vision à court terme de Zendesk, qui ne verse pas de récompense alors qu’il s’agit d’une entreprise réalisant 1,3 milliard de dollars de chiffre d’affaires

  • Il affirme que ce n’est pas une décision rationnelle et que le capital privé réduit les coûts tout en épuisant la marque

• Un autre utilisateur explique que Zendesk a probablement ignoré le problème parce qu’il n’en comprenait pas correctement l’impact

  • Il mentionne que, sans impact clair, de nombreuses vulnérabilités peuvent sembler n’être que de simples bugs

• Un utilisateur souligne que Zendesk n’a corrigé que le problème de l’e-mail de vérification du compte Apple, sans résoudre le problème de fond

  • Il mentionne qu’avec la configuration par défaut, toute personne connaissant l’adresse e-mail et l’ID du ticket pourrait potentiellement détourner un ticket de support

• Il est expliqué qu’il existe deux vulnérabilités distinctes

  • Zendesk permettait d’origine d’envoyer des réponses depuis l’adresse e-mail du demandeur initial tout en ajoutant un CC
  • Slack autorisait une connexion à l’échelle de tout le domaine via Sign in with Apple sans vérification supplémentaire

• Certains critiquent le fait que Zendesk a ignoré le problème et tenté de le garder non public

  • Ils estiment qu’il s’agit d’une attitude non professionnelle, ce qui pourrait expliquer l’absence de récompense

• Enfin, un utilisateur critique le refus de Zendesk de récompenser le bug, en soulignant que le déclarant a suivi correctement toute la procédure