En pleine re numrique, la scurit informatique n’a jamais t aussi cruciale. Rcemment, une faille de scurit significative a t rvle dans le systme de Zendesk, une plateforme largement utilise pour la gestion des services clients. Cette vulnrabilit, dcouverte par un jeune de 15 ans nomm Daniel, a mis en lumire les lacunes de Zendesk en matire de protection contre le spoofing d’emails, permettant des attaquants potentiels d’accder des tickets de support d’entreprises classes dans le Fortune 500.
La dcouverte de la faille
Zendesk est un outil de service la clientle 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 grer les e-mails entrants et crer des tickets. Vous pouvez grer ces tickets vous-mme ou demander une quipe d’assistance de le faire pour vous.
La faille a t trouve dans la faon dont Zendesk gre les emails entrants. De nombreuses entreprises, dont Cloudflare, utilisent Zendesk pour relayer tous leurs emails de support vers la plateforme, o ces messages sont transforms en tickets. Cependant, cette configuration courante comportait une vulnrabilit potentielle. Un attaquant capable de spoofing d’emails pouvait contourner les mcanismes de scurit et accder des informations sensibles contenues dans ces tickets.
Daniel, un adolescent passionn par la cyberscurit, a dcouvert cette faille en testant les limites du systme de Zendesk.
Pourquoi est-ce dangereux ? De nombreuses entreprises utilisent leur domaine @company.com pour l’authentification unique (SSO), qui permet aux employs de se connecter rapidement aux outils internes. En connectant Zendesk au mme domaine, les entreprises crent sans le savoir une faille de scurit potentielle. Zendesk traite tous les e-mails pour le domaine pour lequel il est configur, ce qui signifie que si votre systme SSO ne valide pas correctement les adresses e-mail, toute personne qui accde votre Zendesk peut potentiellement exploiter cette situation et accder vos systmes internes.
Sa dcouverte a rapidement attir l’attention de la communaut de la cyberscurit et des entreprises concernes, gnrant une vague de proccupations quant la robustesse des protections mises en place par Zendesk.
Envoy par DanielAu dbut de l’anne, j’ai dcouvert une grave vulnrabilit 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 gr par Zendesk. Le plus choquant ? Zendesk ne semblait pas s’en proccuper.
Le bogue lui-mme 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 accder 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 cre un nouveau ticket d’assistance. Pour garder la trace du fil de discussion, Zendesk gnre automatiquement une adresse de rponse, qui ressemble ceci : support+id{id}@company.com, o {id} est le numro de ticket unique. Cette adresse garantit que toutes les rponses que vous enverrez l’avenir iront directement au mme ticket.
Zendesk dispose galement d’une fonction de collaboration sur les tickets. Si vous donnez un CC quelqu’un dans l’une de vos rponses 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 gnralement faciles deviner puisque les ID des tickets sont incrmentiels), il pouvait utiliser l’usurpation d’identit pour se faire passer pour l’expditeur 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 lgitime. Il ajoute alors l’adresse lectronique de l’attaquant au ticket, ce qui lui donne un accs 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 adquates contre l’usurpation d’adresse lectronique.
Conditions pralables au bogue :
- L’email du demandeur
- L’ID du ticket (les ID des tickets Zendesk tant incrmentaux, un attaquant pourrait le forcer ou l’estimer).
- Accs un portail d’assistance public
Daniel alerte Zendesk qui refuse de prendre son rapport en considration parce que l’usurpation d’identit n’est pas prvue dans leur programme de rcompense
Lorsqu’il a dcouvert cette vulnrabilit, il l’a signale dans le cadre du programme bug bounty de Zendesk, s’attendant ce qu’elle soit prise au srieux et corrige rapidement. Une semaine plus tard, il a reu une rponse dcevante :
Parce que son bogue reposait sur l’usurpation d’adresse lectronique, ce qui tait considr comme hors de porte pour leur programme HackerOne, ils ont rejet son rapport.
En fait, cette rponse n’manait mme 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 rsolution des bogues au lieu de vrifier les soumissions. Conscient de cette situation, il a demand ce que le rapport soit transmis un vritable membre de l’quipe Zendesk pour examen. Quelques jours plus tard, il a reu une autre rponse frustrante :
Zendesk a refus de reconsidrer la question. Malgr le risque de scurit, 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 exerce par les clients qui ont t informs.
L’escalade
Daniel aurait pu signaler le bogue d’usurpation d’adresse lectronique aux entreprises concernes, car il tait possible de corriger les cas individuels en dsactivant la collaboration par courrier lectronique et en empchant 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 scurit Inti De Ceukelaire y dtaillait comment il avait exploit Zendesk pour infiltrer les espaces de travail privs Slack de centaines d’entreprises. tant donn que de nombreuses entreprises utilisent Slack SSO sur le mme domaine que Zendesk, le chercheur a compris qu’il pouvait effectuer des vrifications d’email par le biais d’un email support@company.com, et obtenir l’accs des canaux Slack privs. 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 ralis qu’il pouvait reproduire son exploit en utilisant la faille qu’il a dcouverte, mais avec quelques dfis relever
Aprs avoir fait ses tests et trouver des moyens de rpliquer son PoC sur des centaines d’instances Zendesk et Slack vulnrables, il a commenc signaler individuellement le bogue aux entreprises utilisant Zendesk.
Une rcompense de 50 000 $ manant de plusieurs entreprises… et 0 $ de Zendesk, qui a quand mme t contrainte de corriger la faille
J’ai pass environ une semaine signaler la vulnrabilit des entreprises individuelles, certaines d’entre elles ont pris des mesures immdiates et ont corrig leurs instances, tandis que d’autres ont soutenu qu’il s’agissait d’un problme li Zendesk. Puis, quelque chose d’intressant s’est produit : un commentaire est apparu sur mon rapport original de HackerOne :
Je n’ai pas pu m’empcher 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 porte.
Certaines entreprises ont d contacter Zendesk aprs avoir reu mon rapport et la pression exerce par ce problme 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 dcouvert ce moment-l, mais maintenant ils voulaient des tapes de reproduction compltes et dtailles pour la prise de contrle de Slack.
J’ai fourni la preuve de concept pour la vulnrabilit de Slack, et ils ont confirm le problme. Bien qu’ils aient affirm avoir « commenc travailler » sur un correctif, il leur faudra en ralit plus de deux mois pour le rsoudre.
Une fois que les entreprises vulnrables ont t informes du problme, nombre d’entre elles ont rapidement dsactiv la fonction de collaboration par courriel de Zendesk afin de protger leurs instances. Au cours de mon enqute, 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 aprs ma rvlation, annulant purement et simplement leurs accords .
Le 2 juillet 2024, deux mois aprs qu’il a soumis le rapport, Zendesk a finalement confirm qu’ils avaient rsolu le problme. Bien que le problme ait t rsolu, 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 vulnrabilit avec les entreprises concernes : Je n’ai pas pris la peine d’argumenter 
Zendesk contrattaque et rplique dans un billet cherchant discrditer Daniel… mais prend la peine de fermer les commentaires
Envoy par ZendeskNous souhaitons galement aborder le programme Bug Bounty associ ce cas. Bien que le chercheur ait initialement soumis la vulnrabilit par le biais de notre processus tabli, il a viol des principes thiques cls en contactant directement des tiers au sujet de son rapport avant d’y remdier. Il s’agit d’une violation des conditions de service du programme bug bounty , qui sont des normes de l’industrie et qui visent protger la communaut des white hat tout en soutenant une divulgation responsable. Cet abus de confiance a entran la perte de la rcompense, car nous appliquons des normes strictes en matire de divulgation responsable.
Ce quoi un internaute a rpondu sur le fil de Daniel : Honntement, il est assez dcevant que vous n’ayez pas pris ce bogue au srieux au dbut et que vous essayiez maintenant de discrditer le chercheur qui a fait ce qu’il fallait. Daniel a averti de manire responsable d’autres entreprises du problme parce que Zendesk n’tait pas intress le rsoudre ou rcompenser l’effort. En fait, le chercheur mrite la reconnaissance et la compensation pour avoir protg ces entreprises alors que Zendesk ne voulait manifestement pas le faire !
Conclusion
La dcouverte de cette faille de scurit dans le systme de Zendesk rappelle l’importance d’une vigilance constante en matire de cyberscurit. Mme les plus grandes entreprises peuvent tre vulnrables des failles simples mais potentiellement dvastatrices. L’incident souligne la ncessit d’une collaboration troite entre les entreprises et les hackers thiques pour crer des environnements numriques plus srs.
Et vous ?
Que pensez-vous de l’attitude de Zendesk ( la soumission du bogue et aprs la pression des entreprises clientes ) ? tes-vous surpris ? Dans quelle mesure ?
Pensez-vous que les entreprises doivent augmenter les rcompenses pour les dcouvertes de bogues afin de motiver davantage les hackers thiques?
Quelle part de responsabilit incombe aux entreprises dans la prvention des failles de scurit? Sont-elles suffisamment proactives?
Que pensez-vous du rle des hackers thiques dans la scurisation des systmes informatiques? Comment devraient-ils tre intgrs dans la stratgie de scurit des entreprises?
Selon vous, quelles mesures devraient tre mises en place pour viter de futures vulnrabilits similaires?
Est-ce que la dcouverte de telles failles de scurit affecte votre confiance en des plateformes comme Zendesk?