L'Institut néerlandais pour la divulgation des vulnérabilités (DIVD) affirme que la violation de son propre réseau a été rendue possible parce que les attaquants ont exploité une chaîne de deux vulnérabilités zero-day dans Zammad, le système de ticketing open-source. La violation de DIVD via le zero-day de Zammad est un rappel cinglant que même les organisations dont le métier est de trouver et signaler les failles de sécurité peuvent être prises au dépourvu par des failles que personne ne connaissait encore.

Les informations disponibles à ce jour sont brèves, donc cet article s'en tient à ce qui a été déclaré et explique pourquoi cela compte.

Comment la chaîne zero-day de Zammad a permis la violation de DIVD

Selon DIVD, l'intrusion dans son réseau a été rendue possible par l'enchaînement de deux vulnérabilités zero-day distinctes dans Zammad. Un zero-day est une faille inconnue du fournisseur ou pour laquelle aucun correctif n'est disponible au moment de son exploitation, ce qui laisse les défenseurs sans solution prête.

L'enchaînement compte. Une vulnérabilité peut donner à un attaquant un point d'ancrage ou un accès limité, tandis qu'une seconde lui permet d'aller plus loin, par exemple en élevant ses privilèges ou en atteignant des systèmes qui auraient dû être hors de portée. Combinés, deux bugs modérés peuvent aboutir à une compromission grave.

Zammad est une plateforme open-source de help desk et de ticketing, couramment auto-hébergée par les organisations pour gérer les demandes de support. Le résumé source ne détaille pas la nature technique des deux failles, et nous n'allons pas les deviner. Les lecteurs doivent surveiller les avis officiels et les correctifs du projet Zammad et de DIVD.

Ce que l'attaque pilotée par l'IA change pour les défenseurs

Le titre décrit la violation comme pilotée par l'IA, et l'angle suggéré note que les outils d'IA auraient accéléré l'attaque. Les détails sur la manière exacte dont l'IA a été utilisée ne figurent pas dans les éléments dont nous disposons, il serait donc erroné de les surestimer.

La préoccupation générale mérite néanmoins d'être comprise. L'automatisation peut réduire le temps entre la découverte d'une faiblesse et son exploitation. Si des outils aident un attaquant à découvrir, tester et enchaîner les vulnérabilités plus rapidement, la fenêtre de réaction des défenseurs se réduit. Cela accentue l'importance de :

  • Corriger rapidement dès que les correctifs sont publiés
  • Limiter ce qu'une application exposée à Internet peut atteindre à l'intérieur du réseau
  • Surveiller pour détecter les comportements inhabituels tôt, plutôt que de se fier aux signatures connues

Rien de tout cela n'est une raison de paniquer. C'est une raison de traiter la gestion de l'exposition comme un processus continu plutôt qu'un audit occasionnel.

Pourquoi les systèmes de ticketing contiennent plus de données sensibles que vous ne le pensez

Un système de ticketing ressemble à un outil banal, mais il collecte souvent une quantité surprenante d'informations. Les gens décrivent leurs problèmes en texte libre, joignent des captures d'écran et des journaux, et incluent des noms, des adresses e-mail, des détails de compte, et parfois des identifiants ou des informations sur des systèmes internes. Pour une organisation de divulgation de vulnérabilités, les tickets peuvent aussi concerner des problèmes de sécurité qui n'ont pas encore été corrigés.

Cela rend ces plateformes particulièrement attrayantes comme cibles. Elles se situent entre le public et les équipes internes, elles sont fréquemment accessibles depuis Internet, et elles conservent un long historique de conversations que peu de gens pensent à nettoyer.

Le même schéma apparaît ailleurs. Dans la violation d'Adidas impliquant un fournisseur tiers, des données de contact client ont été obtenues via un prestataire de service client compromis. La leçon est similaire : l'infrastructure de support peut devenir le point faible même lorsque les systèmes métier essentiels sont mieux protégés. L'exposition de données peut aussi se produire de manières moins directes, comme dans le cas où des agents OpenAI ont publié 53 images ChatGPT sur des sites publics sans autorisation, un rappel que les informations partagées avec un service peuvent voyager au-delà de ce que les utilisateurs attendent.

Ce que cela signifie pour vous

Si vous avez contacté DIVD ou lui avez signalé une vulnérabilité, surveillez les communications officielles de l'organisation concernant l'éventuelle affectation de vos informations. Nous n'avons pas de confirmation de la source sur les données consultées, donc évitez de supposer le pire, mais restez attentif aux avis de suivi.

Si vous utilisez Zammad ou un outil de ticketing auto-hébergé similaire, c'est le bon moment pour vérifier votre exposition. Pour tous les autres, la leçon porte sur les habitudes : les détails que vous confiez aux services de support peuvent résider dans un système que vous ne connaissez pas, géré par un fournisseur que vous n'avez pas choisi.

Ce que les organisations et les utilisateurs devraient vérifier maintenant

Pour les organisations utilisant Zammad :

  • Consultez le projet Zammad et DIVD pour les avis de sécurité et appliquez rapidement tout correctif.
  • Vérifiez si votre instance doit être exposée directement à Internet, et placez-la derrière des contrôles d'accès lorsque c'est possible.
  • Segmentez le serveur des systèmes internes afin qu'une compromission ne devienne pas un problème à l'échelle du réseau.
  • Examinez les journaux pour détecter toute activité inhabituelle et faites tourner les identifiants susceptibles d'apparaître dans d'anciens tickets.
  • Définissez des règles de conservation afin que les anciens tickets contenant des informations sensibles ne soient pas conservés indéfiniment.

Pour les particuliers :

  • Partagez le minimum nécessaire avec les équipes de support, et évitez d'envoyer des mots de passe, des documents d'identité complets ou des détails de paiement dans les tickets.
  • Utilisez des mots de passe uniques pour chaque service afin qu'un ticket divulgué ne puisse pas déverrouiller d'autres comptes.
  • Soyez prudent face aux e-mails inattendus faisant référence à une ancienne demande de support, car les attaquants peuvent utiliser des détails de tickets divulgués pour paraître convaincants. L'affaire Mayer Brown Luna Moth montre comment l'usurpation d'identité peut fonctionner même sans véritable compromission de système.

La conclusion

La violation de DIVD via le zero-day de Zammad montre que les plateformes de support et de ticketing méritent le même examen que tout autre système critique. Corrigez rapidement, limitez l'exposition et supprimez les données dont vous n'avez plus besoin. En tant que lecteur, prenez quelques minutes pour passer en revue les informations personnelles que vous avez partagées avec les services de support et les fournisseurs, et réfléchissez à la façon dont une violation chez l'un d'eux pourrait vous affecter. Pour un exemple parallèle de systèmes de service client devenant le point faible, lisez notre couverture de la violation d'Adidas via un fournisseur tiers.