IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un adolescent a reçu 0$ de Zendesk et 50 000$ des clients de Zendesk après avoir divulgué une faille de sécurité qui a exposé les données sensibles de ses clients du Fortune 500

Le , par Stéphane le calme

69PARTAGES

8  0 
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.

Citation 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 :
  • 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

Daniel alerte Zendesk qui refuse de prendre son rapport en considération parce que l'usurpation d'identité n'est pas prévue dans leur programme de récompense

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

Citation 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.
Ce à quoi un internaute a répondu sur le fil de Daniel : « Honnêtement, il est assez décevant que vous n'ayez pas pris ce bogue au sérieux au début et que vous essayiez maintenant de discréditer le chercheur qui a fait ce qu'il fallait. Daniel a averti de manière responsable d'autres entreprises du problème parce que Zendesk n'était pas intéressé à le résoudre ou à récompenser l'effort. En fait, le chercheur mérite la reconnaissance et la compensation pour avoir protégé ces entreprises alors que Zendesk ne voulait manifestement pas le faire ! »

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?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Minato Sensei
Membre habitué https://www.developpez.com
Le 15/10/2024 à 14:51
N'importe quoi !

Les mecs minimisent ta découverte et bottent en touche. Dès lors que ça va toucher au portefeuille (parce que oui, si les clients le savent, on ne peut plus feindre l'ignorance), ils reviennent craché sur le gars qui leur a indiqué le problème et lui dise « pour la peine, tu auras fourni gratuitement tous les éléments qu'on t'a demandé après, t'avais qu'à ne pas cafter »).

Quel comportement dégueulasse.

Pas étonné qu'après ils verrouillent la section commentaire sous leur publication.

Tu t'étonnes après que des white hack se tournent vers des entreprises comme Zerodium qui, elles, paient grassement mais dont les clients (comprendre « utilisateurs finaux ») ne sont pas nécessairement des anges.

Bon, au moins, le gars a eu 50 000 $.

Sinon à 15 ans je n'avais pas les mêmes passions hein. Je ne sais pas pour vous.
5  0 
Avatar de droggo
Expert confirmé https://www.developpez.com
Le 15/10/2024 à 16:08
Bonjour,

Et ça vous étonne ?
2  0 
Avatar de lecorr
Membre à l'essai https://www.developpez.com
Le 16/10/2024 à 12:03
Insert into blacklist(name) values ('Zendesk');
Commit
2  0 
Avatar de Curtis111
Membre à l'essai https://www.developpez.com
Le 16/10/2024 à 12:53
Citation Envoyé par Minato Sensei Voir le message
N'importe quoi !

Les mecs minimisent ta découverte et bottent en touche. Dès lors que ça va toucher au portefeuille (parce que oui, si les clients le savent, on ne peut plus feindre l'ignorance), ils reviennent craché sur le gars qui leur a indiqué le problème et lui dise « pour la peine, tu auras fourni gratuitement tous les éléments qu'on t'a demandé après, t'avais qu'à ne pas cafter »).

Quel comportement dégueulasse.

Pas étonné qu'après ils verrouillent la section commentaire sous leur publication.

Tu t'étonnes après que des white hack se tournent vers des entreprises comme Zerodium qui, elles, paient grassement mais dont les clients (comprendre « utilisateurs finaux ») ne sont pas nécessairement des anges.

Bon, au moins, le gars a eu 50 000 $.

Sinon à 15 ans je n'avais pas les mêmes passions hein. Je ne sais pas pour vous.
Les entreprises devraient soutenir ceux qui découvrent des vulnérabilités, et non les pénaliser. Avec une telle approche, il n'est pas surprenant que de nombreux pirates informatiques partent pour ceux qui valorisent vraiment leur travail.
2  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 15/10/2024 à 23:30
a ce demander si c'est faille n'était pas en fait une "feature", donc une sorte de backdoor, vu leur reaction initiale ...
1  0 
Avatar de Minato Sensei
Membre habitué https://www.developpez.com
Le 16/10/2024 à 11:10
Citation Envoyé par droggo Voir le message
Bonjour,

Et ça vous étonne ?
Pas tant que ça en réalité. Je suis quand même surpris qu'à l'ère de l'hyper-information, Zendesk (qui brasse des centaines de millions d'euros par trimestre) ne la joue pas plus fine que ça (à mon avis la pilule serait - peut-être - mieux passée s'il lui avait fait un cachet). Après ils sont obligés de jouer les gamins pour tenter de justifier leur choix : [voix d'Hollande quand il s'est fait gauler avec l'affaire du scooter] « mais heuuu, en fait on se préparait à l'écouter, promis, et puis on voulait même lui lâcher un petit billet pour son travail. C'est de sa faute si on ne l'a ni écouté, ni payé, il a tout gâché »
0  0 
Avatar de Minato Sensei
Membre habitué https://www.developpez.com
Le 16/10/2024 à 11:10
Citation Envoyé par Aiekick Voir le message
a ce demander si c'est faille n'était pas en fait une "feature", donc une sorte de backdoor, vu leur reaction initiale ...
C'est possible en plus, je n'y avais pas pensé. ça expliquerait justement la première réaction
0  0