En pleine ère numérique, la sécurité informatique n'a jamais été aussi cruciale. Récemment, une faille de sécurité significative a été révélée dans le système de Zendesk, une plateforme largement utilisée pour la gestion des services clients. Cette vulnérabilité, découverte par un jeune de 15 ans nommé Daniel, a mis en lumière les lacunes de Zendesk en matière de protection contre le spoofing d'emails, permettant à des attaquants potentiels d'accéder à des tickets de support d'entreprises classées dans le Fortune 500.La découverte de la faille
Zendesk est un outil de service à la clientèle utilisé par certaines des plus grandes entreprises du monde. Il est facile à mettre en place : vous le reliez à l'e-mail d'assistance de votre entreprise (comme support@company.com) et Zendesk commence à gérer les e-mails entrants et à créer des tickets. Vous pouvez gérer ces tickets vous-même ou demander à une équipe d'assistance de le faire pour vous.
La faille a été trouvée dans la façon dont Zendesk gère les emails entrants. De nombreuses entreprises, dont Cloudflare, utilisent Zendesk pour relayer tous leurs emails de support vers la plateforme, où ces messages sont transformés en tickets. Cependant, cette configuration courante comportait une vulnérabilité potentielle. Un attaquant capable de spoofing d'emails pouvait contourner les mécanismes de sécurité et accéder à des informations sensibles contenues dans ces tickets.
Daniel, un adolescent passionné par la cybersécurité, a découvert cette faille en testant les limites du système de Zendesk.
Pourquoi est-ce dangereux ? De nombreuses entreprises utilisent leur domaine @company.com pour l'authentification unique (SSO), qui permet aux employés de se connecter rapidement aux outils internes. En connectant Zendesk au même domaine, les entreprises créent sans le savoir une faille de sécurité potentielle. Zendesk traite tous les e-mails pour le domaine pour lequel il est configuré, ce qui signifie que si votre système SSO ne valide pas correctement les adresses e-mail, toute personne qui accède à votre Zendesk peut potentiellement exploiter cette situation et accéder à vos systèmes internes.
Sa découverte a rapidement attiré l'attention de la communauté de la cybersécurité et des entreprises concernées, générant une vague de préoccupations quant à la robustesse des protections mises en place par Zendesk.
Envoyé par Daniel
Usurpation d'adresse électronique
Au début de l'année, j'ai découvert une grave vulnérabilité dans Zendesk qui permettait aux attaquants de lire les tickets de support client de n'importe quelle entreprise utilisant Zendesk. Tout ce qu'ils avaient à faire, c'était d'envoyer un courrier électronique élaboré à un courrier électronique d'assistance géré par Zendesk. Le plus choquant ? Zendesk ne semblait pas s'en préoccuper.
Le bogue lui-même était étonnamment simple. Zendesk n'avait pas de protection efficace contre l'usurpation d'adresse électronique, et cet oubli a permis d'exploiter la fonction de collaboration par courriel pour accéder aux tickets d'autres personnes.
Voici comment cela fonctionnait : lorsque vous envoyez un e-mail au portail d'assistance Zendesk d'une entreprise (par exemple, support@company.com), Zendesk crée un nouveau ticket d'assistance. Pour garder la trace du fil de discussion, Zendesk génère automatiquement une adresse de réponse, qui ressemble à ceci : support+id{id}@company.com, où {id} est le numéro de ticket unique. Cette adresse garantit que toutes les réponses que vous enverrez à l'avenir iront directement au même ticket.
Zendesk dispose également d'une fonction de collaboration sur les tickets. Si vous donnez un CC à quelqu'un dans l'une de vos réponses par courriel, Zendesk l'ajoute automatiquement au ticket, ce qui lui permet de consulter l'historique complet du ticket dans le portail d'assistance.
L'exploit était simple : si un attaquant connaissait l'adresse électronique de l'assistance et l'ID du ticket (qui sont généralement faciles à deviner puisque les ID des tickets sont incrémentiels), il pouvait utiliser l'usurpation d'identité pour se faire passer pour l'expéditeur d'origine. En envoyant un faux e-mail à support+id{id}@company.com à partir de l'adresse e-mail du demandeur et en mettant son propre e-mail en copie conforme, Zendesk pense que l'e-mail est légitime. Il ajoute alors l'adresse électronique de l'attaquant au ticket, ce qui lui donne un accès complet à l'ensemble de l'historique du ticket.
Cela signifie qu'un attaquant peut effectivement rejoindre n'importe quelle conversation d'assistance en cours et lire des informations sensibles, tout cela parce que Zendesk n'a pas de mesures de protection adéquates contre l'usurpation d'adresse électronique.
Conditions préalables au bogue :
Au début de l'année, j'ai découvert une grave vulnérabilité dans Zendesk qui permettait aux attaquants de lire les tickets de support client de n'importe quelle entreprise utilisant Zendesk. Tout ce qu'ils avaient à faire, c'était d'envoyer un courrier électronique élaboré à un courrier électronique d'assistance géré par Zendesk. Le plus choquant ? Zendesk ne semblait pas s'en préoccuper.
Le bogue lui-même était étonnamment simple. Zendesk n'avait pas de protection efficace contre l'usurpation d'adresse électronique, et cet oubli a permis d'exploiter la fonction de collaboration par courriel pour accéder aux tickets d'autres personnes.
Voici comment cela fonctionnait : lorsque vous envoyez un e-mail au portail d'assistance Zendesk d'une entreprise (par exemple, support@company.com), Zendesk crée un nouveau ticket d'assistance. Pour garder la trace du fil de discussion, Zendesk génère automatiquement une adresse de réponse, qui ressemble à ceci : support+id{id}@company.com, où {id} est le numéro de ticket unique. Cette adresse garantit que toutes les réponses que vous enverrez à l'avenir iront directement au même ticket.
Zendesk dispose également d'une fonction de collaboration sur les tickets. Si vous donnez un CC à quelqu'un dans l'une de vos réponses par courriel, Zendesk l'ajoute automatiquement au ticket, ce qui lui permet de consulter l'historique complet du ticket dans le portail d'assistance.
L'exploit était simple : si un attaquant connaissait l'adresse électronique de l'assistance et l'ID du ticket (qui sont généralement faciles à deviner puisque les ID des tickets sont incrémentiels), il pouvait utiliser l'usurpation d'identité pour se faire passer pour l'expéditeur d'origine. En envoyant un faux e-mail à support+id{id}@company.com à partir de l'adresse e-mail du demandeur et en mettant son propre e-mail en copie conforme, Zendesk pense que l'e-mail est légitime. Il ajoute alors l'adresse électronique de l'attaquant au ticket, ce qui lui donne un accès complet à l'ensemble de l'historique du ticket.
Cela signifie qu'un attaquant peut effectivement rejoindre n'importe quelle conversation d'assistance en cours et lire des informations sensibles, tout cela parce que Zendesk n'a pas de mesures de protection adéquates contre l'usurpation d'adresse électronique.
Conditions préalables au bogue :
- L'email du demandeur
- L'ID du ticket (les ID des tickets Zendesk étant incrémentaux, un attaquant pourrait le forcer ou l'estimer).
- Accès à un portail d'assistance public
Lorsqu'il a découvert cette vulnérabilité, il l'a signalée dans le cadre du programme bug bounty de Zendesk, s'attendant à ce qu'elle soit prise au sérieux et corrigée rapidement. Une semaine plus tard, il a reçu une réponse décevante :
Parce que son bogue reposait sur l'usurpation d'adresse électronique, ce qui était considéré comme « hors de portée » pour leur programme HackerOne, ils ont rejeté son rapport.
En fait, cette réponse n'émanait même pas d'un membre de l'équipe Zendesk. De nombreuses entreprises, comme Zendesk, utilisent un service HackerOne pour trier les rapports afin que leur propre équipe puisse se concentrer sur la résolution des bogues au lieu de vérifier les soumissions. Conscient de cette situation, il a demandé à ce que le rapport soit transmis à un véritable membre de l'équipe Zendesk pour examen. Quelques jours plus tard, il a reçu une autre réponse frustrante :
Zendesk a refusé de reconsidérer la question. Malgré le risque de sécurité, ils n'ont pas voulu donner suite au rapport parce qu'il sortait du cadre de leur programme. Bien entendu, ils ont changé d'avis quelques semaines plus tard suite à la pression exercée par les clients qui ont été informés.
L'escalade
Daniel aurait pu signaler le bogue d'usurpation d'adresse électronique aux entreprises concernées, car il était possible de corriger les cas individuels en désactivant la collaboration par courrier électronique et en empêchant les attaquants de s'ajouter aux tickets. Mais il voulait avoir un impact plus important.
C'est alors qu'il est tombé sur TICKETTRICK, un billet de blog datant de 2017. Le chercheur en sécurité Inti De Ceukelaire y détaillait comment il avait exploité Zendesk pour infiltrer les espaces de travail privés Slack de centaines d'entreprises. Étant donné que de nombreuses entreprises utilisent Slack SSO sur le même domaine que Zendesk, le chercheur a compris qu'il pouvait effectuer des vérifications d'email par le biais d'un email support@company.com, et obtenir l'accès à des canaux Slack privés. À l'époque, Zendesk n'était pas aussi important et il y avait des bogues qui permettaient à n'importe qui de voir vos tickets s'il avait votre courriel.
Il a alors réalisé qu'il pouvait reproduire son exploit en utilisant la faille qu'il a découverte, mais avec quelques défis à relever
Après avoir fait ses tests et trouver des moyens de répliquer son PoC sur des centaines d'instances Zendesk et Slack vulnérables, il a commencé à signaler individuellement le bogue aux entreprises utilisant Zendesk.
Une récompense de 50 000 $ émanant de plusieurs entreprises... et 0 $ de Zendesk, qui a quand même été contrainte de corriger la faille
« J'ai passé environ une semaine à signaler la vulnérabilité à des entreprises individuelles, certaines d'entre elles ont pris des mesures immédiates et ont corrigé leurs instances, tandis que d'autres ont soutenu qu'il s'agissait d'un problème lié à Zendesk. Puis, quelque chose d'intéressant s'est produit : un commentaire est apparu sur mon rapport original de HackerOne :
« Je n'ai pas pu m'empêcher de trouver cela amusant - ils me demandaient maintenant de garder le rapport confidentiel, alors qu'ils l'avaient d'abord rejeté comme étant hors de portée.
« Certaines entreprises ont dû contacter Zendesk après avoir reçu mon rapport et la pression exercée par ce problème a essentiellement forcé la main de Zendesk. Je n'avais pas mentionné l'exploit Slack dans mon rapport initial parce que je ne l'avais pas découvert à ce moment-là, mais maintenant ils voulaient des étapes de reproduction complètes et détaillées pour la prise de contrôle de Slack.
« J'ai fourni la preuve de concept pour la vulnérabilité de Slack, et ils ont confirmé le problème. Bien qu'ils aient affirmé avoir "commencé à travailler" sur un correctif, il leur faudra en réalité plus de deux mois pour le résoudre.
« Une fois que les entreprises vulnérables ont été informées du problème, nombre d'entre elles ont rapidement désactivé la fonction de collaboration par courriel de Zendesk afin de protéger leurs instances. Au cours de mon enquête, j'ai gagné plus de 50 000 dollars en primes de la part d'entreprises individuelles sur HackerOne et d'autres plateformes.
« Comme on pouvait s'y attendre, Zendesk n'a pas fait bonne figure. Au moins une ou deux entreprises auraient coupé les ponts avec Zendesk après ma révélation, annulant purement et simplement leurs accords ».
Le 2 juillet 2024, deux mois après qu'il a soumis le rapport, Zendesk a finalement confirmé qu'ils avaient résolu le problème. Bien que le problème ait été résolu, Zendesk a finalement choisi de ne pas accorder de prime pour son rapport. Leur raisonnement ? Daniel avait enfreint les directives de divulgation de HackerOne en partageant la vulnérabilité avec les entreprises concernées : « Je n'ai pas pris la peine d'argumenter
»Zendesk contrattaque et réplique dans un billet cherchant à discréditer Daniel... mais prend la peine de fermer les commentaires
Envoyé par Zendesk
Nous souhaitons également aborder le programme Bug Bounty associé à ce cas. Bien que le chercheur ait initialement soumis la vulnérabilité par le biais de notre processus établi, il a violé des principes éthiques clés en contactant directement des tiers au sujet de son rapport avant d'y remédier. Il s'agit d'une violation des conditions de service du programme « bug bounty », qui sont des normes de l'industrie et qui visent à protéger la communauté des « white hat » tout en soutenant une divulgation responsable. Cet abus de confiance a entraîné la perte de la récompense, car nous appliquons des normes strictes en matière de divulgation responsable.
Conclusion
La découverte de cette faille de sécurité dans le système de Zendesk rappelle l'importance d'une vigilance constante en matière de cybersécurité. Même les plus grandes entreprises peuvent être vulnérables à des failles simples mais potentiellement dévastatrices. L'incident souligne la nécessité d'une collaboration étroite entre les entreprises et les hackers éthiques pour créer des environnements numériques plus sûrs.
Sources : Daniel, Zendesk
Et vous ?
Que pensez-vous de l'attitude de Zendesk (à la soumission du bogue et après la pression des entreprises clientes ) ? Êtes-vous surpris ? Dans quelle mesure ? Pensez-vous que les entreprises doivent augmenter les récompenses pour les découvertes de bogues afin de motiver davantage les hackers éthiques? Quelle part de responsabilité incombe aux entreprises dans la prévention des failles de sécurité? Sont-elles suffisamment proactives? Que pensez-vous du rôle des hackers éthiques dans la sécurisation des systèmes informatiques? Comment devraient-ils être intégrés dans la stratégie de sécurité des entreprises? Selon vous, quelles mesures devraient être mises en place pour éviter de futures vulnérabilités similaires? Est-ce que la découverte de telles failles de sécurité affecte votre confiance en des plateformes comme Zendesk? 
