Voici la deuxième partie de notre série sur ToolShell, qui fait suite à notre précédent entretien avec Erik Montcalm, Senior VP of Security Services and Technology at SecureOps. ToolShell est une vulnérabilité de SharePoint qui donne aux attaquants un accès permanent aux serveurs compromis.
Dans cette longue série de questions-réponses, Patrick Ethier, un vétéran de la cybersécurité ayant une vaste expérience dans l'orientation de la stratégie et des opérations de sécurité des entreprises, et le directeur de la technologie chez SecureOps, explique comment les attaquants maintiennent la furtivité, les défis de la remédiation, et pourquoi l'adoption du cloud et la gestion appropriée des fournisseurs sont essentielles à une posture de sécurité saine. Patrick identifie également les types d'organisations les plus à risque, en illustrant les défis de la gestion de SharePoint sur site et les conséquences des déploiements hérités et personnalisés. Son commentaire offre à la fois un avertissement sévère et des conseils pratiques aux RSSI pour réduire les risques.
Patrick Ethier : Oui, il s'agit d'une combinaison, ou d'une chaîne, de problèmes de sécurité purs et simples. Cela est dû au fait que SharePoint est une plateforme de collaboration/CMS et que la version OnPrem ne sépare généralement pas l'utilisation par l'utilisateur final de l'utilisation par l'administrateur. Les administrateurs voient les panneaux d'administration, les utilisateurs réguliers voient leur contenu, mais en dessous, c'est généralement configuré comme une grande application monolithique du point de vue des privilèges.
La chaîne est complexe, mais elle fait appel à des techniques courantes. Dans la première partie de la chaîne, ils ont trouvé le moyen de contourner l'authentification en remplaçant simplement un en-tête HTTP standard sur une requête valide. Il s'agit clairement d'une variante d'un bogue que Microsoft a tenté de corriger par le passé. Ils utilisent ensuite une fonction de sérialisation dans le widget ToolPane de SharePoint afin de tromper SharePoint en exécutant du code à distance (RCE). Dans de nombreux cas, cela implique l'installation d'un shell distant ou d'une porte dérobée. À partir de là, le monde est à votre portée. Cette chaîne est ensuite utilisée pour voler des clés du registre afin de falsifier d'autres informations d'identification. Cela permet à l'attaquant de continuer à accéder au système en utilisant des canaux légitimes et de passer inaperçu.
C'est comme si vous quittiez votre maison pendant trois mois et que quelqu'un trouvait un moyen de s'y introduire. Au début, il se déplace discrètement. Puis il se lie d'amitié avec les voisins et, soudain, on a l'impression qu'il a toujours fait partie du quartier. Il peut cloner des clés, installer des portes secrètes et continuer à traîner tout en donnant l'impression d'être à sa place. On passe très rapidement du contournement de l'authentification à la possession de tout l'endroit. Une fois que cela se produit, la seule véritable solution est de raser la maison et de recommencer à zéro. Il n'y a pas de moyen propre de regarder à l'intérieur et de les supprimer complètement.
PE : Une fois que l'on est propriétaire du système, cela devient un problème de sécurité standard. Cela dépend du niveau d'accès des comptes de service, du réseau et d'un tas d'autres facteurs.
Si vos serveurs sont isolés et verrouillés, c'est comme si la maison se trouvait au milieu d'une forêt. Les interactions avec les voisins sont limitées. Ils ne peuvent pas influencer facilement leurs voisins et se heurtent essentiellement à un mur.
Mais si l'accès aux comptes de service n'est pas limité ou si le réseau est désordonné, obsolète ou mal segmenté, les attaquants peuvent se déplacer tranquillement et étendre leur portée. Ils veillent à ne pas faire de bruit, car chaque interaction augmente les chances que vous le remarquiez.
À ce stade, leur furtivité ne consiste pas seulement à se cacher dans la mémoire. Si vous effectuez des niveaux stratégiques de journalisation, des choses commencent à apparaître dans les journaux : comment ils manipulent les informations d'identification, comment ils interagissent avec le système au fil du temps, chargent des fichiers, les téléchargent, etc.
Patrick : ToolShell est juste la marque décrivant cette chaîne particulière d'attaques qui aboutit généralement à l'exécution d'un code à distance et à l'installation d'un shell à distance. Les attaques par shell à distance ont plusieurs variantes. Certaines sont en mémoire, des attaques ponctuelles qui exécutent quelques étapes et sont ensuite effacées de la mémoire. Ces attaques sont rapides et presque invisibles, avec une empreinte limitée. D'autres sont plus actives et chargent des fichiers ou des portes dérobées qui persistent et modifient le système en permanence.
Le CVE de sérialisation dans le panneau d'outils de SharePoint est essentiel. Il permet aux attaquants d'injecter du code de plusieurs manières. Comme mentionné ci-dessus, selon l'approche de l'attaquant, vous ne remarquerez peut-être rien, ou bien il tentera des étapes plus sophistiquées afin d'obtenir un accès persistant complet. La description du CVE semble indiquer une série d'IoC (indicateurs de compromission) pour des noms de fichiers spécifiques à rechercher. C'est une bonne chose pour l'avenir, mais dans une situation de type "zero-day" où vous ne savez pas quels pourraient être les noms de fichiers, une simple configuration HIDS ne permettra pas nécessairement d'atténuer ce problème. C'est pourquoi il est essentiel de disposer d'un EDR robuste qui surveille la mémoire, les nouveaux fichiers et enregistre les activités suspectes.
Patrick : De nos jours, vous pouvez compter sur l'EDR et la journalisation pour assurer une bonne partie du travail de protection contre ces éléments. Ce n'est pas infaillible, mais en utilisant les deux en tandem, vous pouvez surveiller les anomalies dans l'exécution de la mémoire, les fichiers nouveaux ou modifiés, le trafic inhabituel à travers les proxys, les sondes vers d'autres systèmes qui sortent de l'ordinaire, les tailles d'octets inhabituelles dans les sessions, etc.
Même si vous ne pouvez pas tout détecter immédiatement, les journaux vous permettent d'établir une corrélation entre les activités et d'identifier potentiellement les systèmes compromis. L'utilisation d'un WAF (web application firewall) peut également s'avérer très utile. Par exemple, la première étape de la chaîne d'attaque ToolShell exploite les en-têtes referrer qui peuvent facilement être verrouillés et assainis par un WAF. Le WAF peut également supprimer tout autre en-tête qui n'est pas requis par la plateforme.
Dès qu'un avis est publié, vous pouvez rapidement mettre en œuvre des règles d'urgence avec l'EDR et le WAF pour bloquer toute exploitation ultérieure jusqu'à ce qu'un correctif soit disponible. Vous pouvez également rechercher des IoC dans l'EDR, le WAF et les journaux du système, ce qui peut contribuer à fournir un certain niveau d'assurance ou d'indication qu'un système a effectivement été compromis afin d'éviter de détruire la maison au bulldozer comme nous l'avons mentionné précédemment.
Patrick : Non. On réduit le risque, mais on ne l'élimine jamais. La défense en profondeur - EDR, XDR, segmentation, utilisation d'un WAF, surveillance, contrôle des changements, formation - est le meilleur moyen de garder une longueur d'avance. La conformité à elle seule ne vous protège pas, mais elle montre que vous faites un effort conscient et comporte généralement un important volet d'amélioration continue. En fin de compte, c'est une question d'intention et d'effort. Si quelque chose passe, vous serez mieux préparé à réagir.
Patrick : C'est une question délicate. SharePoint permet aux utilisateurs d'ajouter des scripts et des widgets, souvent sans contrôle adéquat des modifications. Au fil du temps, vous pouvez ne pas savoir si quelque chose de malveillant a été ajouté il y a plusieurs mois. La restauration à partir de sauvegardes sans audit peut réintroduire ces scripts. Vous devez distinguer les activités légitimes des utilisateurs des menaces potentielles. Si l'on s'en remet entièrement aux utilisateurs finaux, il devient très difficile de savoir ce qui est sûr.
Patrick : La culture est importante. De nombreuses entreprises adoptent un état d'esprit du type "si ça marche, ne le réparez pas". Elles installent SharePoint sur site et ne l'entretiennent jamais correctement. Les ressources informatiques limitées, l'absence de personnel dédié à la sécurité et le manque de gestion formelle des changements facilitent la persistance. Cela s'applique également aux fournisseurs tiers. S'ils n'appliquent pas de correctifs ou n'effectuent pas d'audit correctement, votre exposition se multiplie.
Patrick : Tous ceux qui utilisent des serveurs OnPrem sont exposés à des risques plus ou moins importants. Mais dans certaines circonstances, il est beaucoup plus probable qu'il soit difficile de se remettre d'une attaque comme celle de ToolShell.
Le premier groupe est celui des entreprises qui utilisent SharePoint sur site et dont les ressources informatiques sont limitées. Elles ne peuvent pas maintenir l'architecture, les correctifs ou la surveillance correctement, ce qui les rend vulnérables. Ce groupe devrait envisager de passer à des services basés sur le cloud ou de réduire l'exposition publique de leurs services SharePoint par tous les moyens possibles.
Le deuxième groupe est celui des organisations qui ont déployé SharePoint sur site en raison d'exigences de conformité, telles que GDPR ou HIPAA. Elles peuvent verrouiller le serveur physiquement, mais s'il est exposé à Internet pour des raisons de commodité, il y a un risque. Dans ce cas, un examen minutieux de l'architecture et des contrôles de sécurité associés doit être effectué à l'aide de ToolShell.
Troisièmement, les entreprises qui utilisent des produits tiers basés sur SharePoint. Si les fournisseurs tiers n'abordent pas formellement les correctifs, la surveillance et la divulgation, vous héritez de ce risque. Il est important de prêter attention aux clauses du contrat de service qui garantissent que le fournisseur suit les meilleures pratiques qui ont été examinées par une norme telle que SOC2 ou ISO27000.
Tous trois devraient réévaluer la valeur d'un déploiement de SharePoint sur site. Les risques et les coûts à long terme d'une migration dans le nuage sont souvent plus sûrs et moins chers, car Microsoft s'occupe de tout. La société assure en permanence la maintenance de l'architecture, l'application des correctifs et la surveillance à grande échelle, ce que ces organisations doivent autrement faire elles-mêmes.
Patrick : Il s'agit principalement d'une question d'approvisionnement et de contrat. Vos appels d'offres et vos contrats devraient exiger des fournisseurs qu'ils maintiennent les mises à jour, qu'ils respectent les cadres de conformité et qu'ils divulguent les vulnérabilités. Posez-leur directement la question : "Que faites-vous à ce sujet ?" S'ils sont conformes à la norme SOC 2 ou à la norme ISO 27000, et s'ils ont des clauses de divulgation, vous pouvez prendre des décisions en connaissance de cause.
Patrick : Concentrez-vous sur la bonne exécution des tâches. Intégrez l'audit, la journalisation et la surveillance dans vos pratiques. Maintenez des contrats clairs et des clauses de divulgation avec les fournisseurs. Envisagez une migration vers le cloud si le support sur site est faible. Ne sous-estimez pas l'architecture. Même de petites erreurs, comme le fait de laisser un serveur exposé, peuvent être exploitées par des attaquants.
Vous ne pourrez pas tout détecter, mais des pratiques structurées vous permettent de réagir efficacement.
ToolShell montre que même des plateformes familières comme SharePoint restent vulnérables. Les attaquants exploitent la furtivité, l'exécution en mémoire et les scripts dormants pour persister. Les organisations dont les ressources informatiques sont limitées, qui ont des besoins de conformité stricts ou qui dépendent de solutions SharePoint tierces sont les plus exposées. La défense en profondeur, l'audit, la migration vers le nuage et une solide gestion du changement sont essentiels. Plus important encore, les entreprises doivent se concentrer sur l'effort et l'intention - les pratiques structurées et la vigilance donnent aux équipes les meilleures chances de gérer les incidents et de s'en remettre.
De plus, cette vulnérabilité n'existe que dans la version sur site de l'application. En migrant vers un déploiement dans le nuage, les entreprises peuvent contourner la vulnérabilité.
Contactez SecureOps dès aujourd'hui pour discuter de la meilleure façon de protéger votre environnement contre ToolShell et d'autres vulnérabilités.