Après la publication par Microsoft de recommandations pour atténuer les deux failles d’exécution de code à distance découvertes la semaine dernière par la société vietnamienne de sécurité GTSC, il semble que les mesures proposées par Microsoft n’aient pas été aussi efficaces que l’entreprise l’espérait.
Au cours du week-end, le chercheur vietnamien en sécurité Jang a averti : « Le schéma d’URL fourni dans l’article de blog du MSRC pour détecter ou empêcher l’Exchange 0day peut facilement être contourné », suggérant que le schéma suivant pourrait fonctionner à la place : .*autodiscover\.json.*Powershell.*.
Will Dormann, analyste principal des vulnérabilités au sein du cabinet de conseil en gestion Analygence, a abondé dans ce sens, soulignant : « Le caractère “@” dans les mesures de blocage d’URL recommandées par Microsoft (“.*autodiscover\.json.*\@.*Powershell.*”) pour CVE-2022-41040 et CVE-2022-41082 semble inutilement précis et donc insuffisant. » Dormann a reconnu que le schéma alternatif de Jang devrait fonctionner.
Mise à jour des recommandations de Microsoft
Peu après, GTSC a mis à jour son article de blog sur les vulnérabilités, en écrivant : « Après avoir reçu des informations de Jang (@testanull), nous avons constaté que l’expression régulière utilisée dans la règle Rewrite pouvait être contournée », validant ainsi la correction proposée par Jang et renvoyant vers une vidéo montrant le problème.
Hier, Microsoft a mis à jour ses propres recommandations pour suivre les conseils de Jang, mais sans lui en attribuer le mérite. « Des mises à jour importantes ont été apportées à la section Mesures d’atténuation afin d’améliorer la règle de réécriture d’URL », a écrit l’entreprise. Microsoft a également demandé aux clients d’Exchange Server de désactiver l’accès à PowerShell à distance pour les utilisateurs non administrateurs.
Le chercheur en sécurité Kevin Beaumont, qui a baptisé les failles « ProxyNotShell » en raison de leurs similitudes avec les vulnérabilités ProxyShell, a observé : « Ils ont “amélioré” la règle, mais en utilisant celle de @testanull. »
Claire Tills, ingénieure principale en recherche chez Tenable, a déclaré que la principale différence entre ProxyNotShell et ProxyShell réside dans le fait que les nouvelles failles exigent une authentification, contrairement à ProxyShell. « ProxyShell était et reste l’une des chaînes d’attaque les plus exploitées apparues en 2021 », a-t-elle souligné.
Les déploiements Exchange hybrides et sur site sont concernés
Dans un article de blog, Beaumont a écrit : « Si vous avez appliqué cette mesure manuellement, vous devez *modifier* manuellement la chaîne de mesure ci-dessus. Si vous avez exécuté EOMTv2, vous devez *retélécharger* le script et l’exécuter à nouveau. Le site web d’EOMTv2 n’indique pas que le script a changé — vérifiez donc que vos administrateurs disposent bien du bon script. »
Beaumont a par ailleurs noté que, si Microsoft affirmait dans ses recommandations que les clients d’Exchange Online n’avaient rien à faire, les clients d’Exchange Online disposant de déploiements hybrides comprenant à la fois des environnements sur site et en ligne devaient bel et bien agir.
L’agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a inscrit les deux failles sur sa liste des vulnérabilités connues comme étant exploitées.
Découvrez les meilleurs outils de gestion des correctifs et gestion des vulnérabilités
Des escrocs investissent GitHubLes escrocs ont rapidement profité de la forte visibilité des nouvelles failles en tentant de les « vendre » sur GitHub contre des bitcoins. En réaction, le chercheur en sécurité de Huntress John Hammond a signalé
plusieurs de ces escrocs à GitHub.Ces escroqueries semblent constituer une tendance croissante. Le chercheur en sécurité Koley a noté : « C’est très courant avec les grandes failles zero-day depuis environ un an. GitHub n’a rien fait pour aider. » Un autre chercheur, Rusty, a ajouté