La découverte de l’outil de sécurité Shellter compromis soulève un débat sur la divulgation

Les CISO dont le personnel utilise le logiciel commercial d’évasion antivirus d’élite pour détecter les vulnérabilités doivent immédiatement mettre à jour vers la dernière version après la récente découverte que les acteurs de la menace utilisent une version volée pour distribuer des logiciels malveillants.

Ce n’est pas parce que l’abus des outils de sécurité est une nouvelle – ce n’est pas le cas. Les acteurs de la menace tirent parti des versions volées ou copiées de l’outil de simulation d’adversaire de grève de Cobalt depuis des années pour aider à leurs attaques. Mais pour les CISO, cet incident soulève une autre question: à quelle vitesse les chercheurs en sécurité devraient-ils informer un fournisseur qu’un produit a été compromis avant d’annoncer publiquement la vulnérabilité?

Dans ce cas, le 2 juillet, Elastic Security Lab, une partie de la plate-forme de recherche élastique, qui fait également une solution de sécurité de terminaison, a blogué qu’il avait trouvé plusieurs campagnes d’infostealer en utilisant ce qui semblait être une version compromise de Shellter Elite 11.0 pour contourner ses défenses.

Cette version de l’application a été publiée le 16 avril. Elastic dit que, à la fin du mois, ses chercheurs ont identifié plusieurs campagnes déploient divers voleurs d’informations protégés par Shellter Elite.

Dans une réponse le 4 juillet, le projet Shellter a remercié Elastic d’avoir fourni des échantillons manipulés qui ont aidé le vendeur à confirmer l’identité du client impliqué, qui aurait divulgué leur copie du logiciel qui a par la suite profité par les acteurs de la menace. Shellter dit qu’il a un «processus de vérification rigoureux» pour déterminer qui est autorisé à acheter ses produits de sécurité, mais «une entreprise qui avait récemment acheté des licences Shellter Elite avait divulgué leur copie du logiciel» à des étrangers.

Mais Shellter a également explosé élastique pour ne pas l’avertir rapidement. « Les laboratoires de sécurité élastiques ont choisi d’agir d’une manière que nous considérons à la fois imprudents et non professionnels », a plaint la société dans son blog. «Ils étaient au courant de la question pendant plusieurs mois mais n’ont pas réussi à nous en informer. Au lieu de collaborer pour atténuer la menace, ils ont choisi de refuser les informations afin de publier un exposé surprise – prioritant la publicité sur la sécurité publique.

« En raison de ce manque de communication, il a fait de la chance que le client impliqué n’ait pas eu accès à notre prochaine version. Si nous n’avions pas reporté le lancement pour des raisons personnelles non liées, ils auraient reçu une nouvelle version avec des capacités d’évasion d’exécution améliorées – même contre les propres mécanismes de détection d’Elastic. »

Shellter Elite a un certain nombre de capacités, notamment la gestion des étapes d’évasion d’exécution nécessaires aux équipes rouges pour charger leurs balises de commandement et de contrôle qui tenteraient de cacher les attaques de test des équipes bleues. Ces capacités, qui seraient utiles pour menacer les acteurs, incluent la capacité d’échapper à l’analyse statique et dynamique.

Invité à expliquer l’écart des dates, Elastic a déclaré que les métadonnées de création de fichiers des échantillons de logiciels malveillants ont été obtenues en juin.

Le blog et la recherche ont été «menés conformément à notre engagement envers la transparence, la divulgation responsable et un état d’esprit de défenseur d’abord», indique le communiqué.

«Nous publions nos résultats directement et de manière transparente pour informer les défenseurs le plus rapidement possible, tout comme la norme de l’industrie et une partie du travail pour nos clients et nos utilisateurs», ajoute la déclaration. «Notre priorité est d’informer la communauté de la sécurité rapidement et avec précision sur nos recherches. Nous pensons que l’intérêt public est mieux servi en divultant la recherche le plus rapidement possible, une fois qu’une analyse approfondie a été conclue, pour aider les défenseurs à répondre aux menaces émergentes, y compris les techniques utilisées pour contourner les contrôles de sécurité.»

Interrogé pour commenter s’il avait entendu parler d’Elastic, un porte-parole de Shellter a déclaré qu’il avait décrit sa position dans son blog.

Cependant, un expert dit que ce n’est pas un cas de divulgation de vulnérabilité éthique. Au lieu de cela, dit Robert Beggs, responsable de la société de réponse aux incidents canadiens Digital Defence et un utilisateur de produits Shellter, c’est un affrontement de perspectives très différentes pour assurer la sécurité des réseaux: offensif (Shellter) contre défensif (élastique).

« Pourquoi Elastic ne voudrait-il pas publier qu’il a la capacité de détecter un outil comme celui de Shellter? Pouvoir le faire va au-delà de la bonne publicité, il démontre la valeur réelle de l’élastique contre un outil conçu pour le cacher. »

« Shellter pourrait ne pas l’aimer », a-t-il dit, « mais Elastic a fait une bonne analyse de l’événement » dans son blog.

Il n’y a pas d’éthique entre deux vendeurs diamétralement opposés, a-t-il soutenu. « Imaginez si une entreprise a constaté que son produit était utilisé pour contourner Microsoft Defender, un outil défensif commun », a-t-il déclaré. «Y a-t-il une obligation éthique d’avertir immédiatement Microsoft? Ou, est-ce la responsabilité de Microsoft de surveiller l’environnement, d’identifier les échecs de son propre outil, de rétro-ingénieur pourquoi la défaillance a eu lieu, puis de modifier le défenseur pour compenser la nouvelle attaque? Clairement, Microsoft a toujours assumé la responsabilité de chercher à la recherche de son propre outil, et de la rendre efficace à son travail.

« De la même manière, Elastic n’est pas responsable d’aller à Shellter pour dire à Shellter comment leur outil est utilisé ou comment ils peuvent le détecter », a-t-il écrit.

« Shellter n’a pas fait valoir ses arguments », a soutenu Beggs. «Il n’y a pas de« violation éthique ». Elastic a fait un excellent travail pour trouver« l’ennemi »et devrait profiter de la récompense de la signaler au monde. Shellter a essayé de prendre la route morale élevée, s’excusant à ses clients pour« l’inconvénient que cela a pu provoquer ». Quel inconvénient? Quelqu’un d’autre a mal utilisé un produit qui n’a affecté aucun autre client.

« Shellter a créé une tempête dans une théière, invoquant un concept de » divulgation responsable « qui n’existe vraiment pas entre les vendeurs de produits offensifs et défensifs. Et considérant que c’est une violation de l’éthique inexistante est une interprétation extrême et médiocre des événements », a déclaré Beggs.

Il n’y a pas de règles difficiles pour la divulgation de la vulnérabilité. Cependant, un certain nombre d’organisations ont des lignes directrices.

Par exemple, l’Open Web Application Security Project (OWASP) dispose de lignes directrices pour les chercheurs et les fournisseurs ou les organisations. Une recommandation clé: les chercheurs peuvent décider de divulguer publiquement un trou, mais cela doit être fait en réponse à une organisation ignorant les vulnérabilités signalées pour exercer une pression sur eux pour développer et publier un correctif.

OWASP préfère qu’une vulnérabilité soit signalée en privé aux développeurs. L’organisation ou le développeur individuel peut ensuite choisir de publier les détails des vulnérabilités, mais, souligne OWASP, cela se fait à la discrétion du développeur ou de l’organisation, pas du chercheur.

Les chercheurs en sécurité, dit Owasp, devrait

• assurer que tout test est légal et autorisé;
• respecter l’intimité des autres;
• faire des efforts raisonnables pour contacter l’équipe de sécurité de l’organisation;
• Fournir suffisamment de détails pour permettre la vérification et la reproduction des vulnérabilités;
• Ne demandez pas le paiement ou les récompenses pour signaler des vulnérabilités en dehors d’un programme de primes de bogues établi.

Les organisations doivent

• Fournir une méthode claire pour les chercheurs pour signaler en toute sécurité les vulnérabilités;
• établir clairement la portée et les termes de tout programme de prime de bogue;
• répondre aux rapports dans un calendrier raisonnable;
• communiquer ouvertement avec les chercheurs;
• ne menace pas une action en justice contre les chercheurs;
• demander cves le cas échéant;
• publier des avis de sécurité clairs et des changelogs;
• Offrez des récompenses et du crédit pour les découvertes.