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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
