Des failles peuvent en cacher d’autres

Deux failles dans SharePoint sont activement exploitées par des pirates à travers le monde. Bien qu’elles aient été corrigées une première fois, les solutions ont été contournées dans de nouvelles exploitations. Microsoft vient de publier en urgence de nouveaux patchs, mais les dégâts semblent déjà nombreux.

En mai, lors de l’évènement Pwn2Own à Berlin, des chercheurs de la société Viettel avaient montré comment ils pouvaient prendre le contrôle d’un serveur SharePoint sur site grâce à l’enchainement de deux failles. Ces exploitations, estampillées CVE-2025-49706 et CVE-2025-49704, ont été corrigées dans le patch Tuesday du mardi 8 juillet. Il valait mieux : l’attaque, nommée ToolShell, pouvait mener à une exécution de code arbitraire à distance.

Or, durant tout le week-end, des attaques ont eu lieu un peu partout pour viser les mêmes failles. Le problème n’était pas cette fois le manque d’installation des correctifs, mais un contournement des méthodes mises en place par Microsoft.

Deux failles sauvages apparaissent

Dès la nuit du 18 au 19, plusieurs dizaines de serveurs SharePoint sur site ont été attaqués avec la même méthode que pour ToolShell. Mais si la méthode est la même, les failles ne le sont pas. Deux nouvelles vulnérabilités ont été utilisées pour parvenir au résultat, CVE-2025-53770 et CVE-2025-53771. La première affiche un score CVSS très élevé de 9,8 sur 10, qui en fait une faille critique. La seconde a une note de 6,3. Des failles connues et corrigées ont donc été transformées en une nouvelle menace 0-day.

La situation est vite devenue grave, au point que Microsoft a publié il y a quelques heures deux nouveaux correctifs en urgence. Dans sa note technique sur le sujet, l’entreprise indique que les solutions apportées sont plus robustes que celles diffusées il y a deux semaines.

Il est donc recommandé d’installer ces correctifs aussi rapidement que possible, une centaine de serveurs au moins ayant déjà été piratés. Exploitées, les nouvelles failles conduisent à l’exécution de code arbitraire à distance et permettent aux pirates de prendre le contrôle des serveurs, avec tout ce que cela suppose de danger pour les données hébergées.

Il faut noter en outre que ces correctifs ne concernent pour l’instant que deux éditions de SharePoint : Server 2019 et Subscription Edition. La version 2016 n’a pas encore de solution, mais Microsoft promet la publication rapide d’un correctif dédié.

Aux États-Unis, la CISA (Cybersecurity and Infrastructure Security Agency) a ajouté la faille critique CVE-2025-53770 à son catalogue des vulnérabilités connues activement exploitées (KEV). En théorie, cet ajout donne 24 heures aux administrations américaines pour appliquer les correctifs.

Manipulations supplémentaires

Les pirates cherchent avant tout à récupérer les clés cryptographiques du serveur SharePoint. Connues sous le nom de MachineKeys, elles incluent la ValidationKey et la DecryptionKey, qui représentent le fondement de la confiance pour les mécanismes de gestion d’état, dont les jetons __VIEWSTATE. La chaine ToolShell permet la récupération de ces informations depuis la mémoire ou de la configuration. Munis de ces informations, les pirates peuvent alors créer leurs propres charges __VIEWSTATE valides, signées par l’outil ysoserial qui autorise la génération de leurs propres jetons.

Après installation des mises à jour, Microsoft conseille vivement de procéder à une rotation des clés pour les machines SharePoint. L’opération est manuelle et peut être effectuée via deux méthodes.

La première consiste à utiliser PowerShell et à lancer la commande « cmdlet Update-SPMachineKey ». C’est de loin la plus simple.

La seconde passe par Central Admin et réclame un plus grand nombre d’étapes. Il faut ainsi se rendre dans Central Admin, puis se rendre dans Monitoring -> Review job definition. Là, il faut chercher « Machine Key Rotation Job » et cliquer sur « Run Now ». après quoi, il faudra redémarrer IIS (Internet Information Services) sur l’ensemble des serveurs SharePoint.

Microsoft recommande également de vérifier les journaux (logs) et systèmes de fichiers pour chercher des traces d’une infection existante. Il faut notamment chercher la présence du fichier spinstall0.aspx présent dans C:\Progra~1\Common~1\Micros~1\Webser~1\16\Template\Layouts. Autre trace de contamination, la présence dans les journaux d’IIS d’une requête POST vers _layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx et d’un référent HTTP de _layouts/SignOut.aspx.

Microsoft donne d’ailleurs une requête Defender pour automatiser le processus :

eviceFileEvents

| where FolderPath has "MICROS~1\\WEBSER~1\\\TEMPLATE\\LAYOUTS"

| where FileName =~ "spinstall0.aspx"

or FileName has "spinstall0"

| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, FolderPath, ReportId, ActionType, SHA256

| order by Timestamp desc

Quatre jours auront suffi

Que s’est-il passé exactement ? Lors de la publication des correctifs initiaux par Microsoft le 8 juillet, la communauté des chercheurs estime a priori que le problème est réglé. Les détails des failles n’avaient pas été divulgués par Viettel et le chercheur à l’origine de la découverte, Khoa Dinh, annonçait lui aussi que le problème était réglé le 10 juillet, donnant d’ailleurs le nom ToolShell à la chaine d’attaque. Il encourageait vivement l’installation des correctifs car l’exploitation pouvait se faire par une seule requête.

Le 14 juillet cependant, une autre société de sécurité s’en mêle : Code White. Située en Allemagne, elle annonce sur X avoir reproduit le problème, confirmant qu’une seule requête était nécessaire. Code White ne donne pas la requête, mais publie une capture dans laquelle apparaissent certains détails. De quoi mettre des pirates sur la piste. De plus, le 18 juillet, le chercheur Soroush Dalili publie d’autres informations, indiquant s’être servi de Gemini pour retrouver le contournement initial de Khoa Dinh et se réjouissant de l’utilisation de l’IA dans ce domaine.

On ne sait quelles informations précises ont été utilisées, mais les premières attaques ont été enregistrées à peine quelque heures plus tard. Ce lancement très rapide et l’absence apparente de traits communs entre les victimes laissent penser qu’il ne s’agit pas d’une attaque coordonnée par un acteur étatique, mais davantage d’une attaque opportuniste par divers groupes et individus. Elle serait donc le résultat de la diffusion de l’exploitation.

Auteur : Vincent Hermann

Aller à la source