Des attaquants exploitent actuellement deux vulnérabilités non corrigées pour compromettre à distance des serveurs Microsoft Exchange sur site. L'éditeur a confirmé les failles à la fin de la semaine dernière et a fourni des solutions d'atténuation le temps de développer un correctif complet. Mais, selon les rapports, l'atténuation proposée peut être facilement contournée. Les vulnérabilités ont été découvertes au début du mois d'août par une entreprise de sécurité vietnamienne appelée GTSC alors qu'elle effectuait une surveillance de la sécurité et une réponse aux incidents pour un client dont les serveurs avaient été attaqués. Dans un premier temps, les chercheurs de GTSC ont pensé qu'il s'agissait d'un exploit de type ProxyShell, au vu des requêtes malveillantes observées dans les logs des serveurs, qui présentaient des similitudes. L’attaque ProxyShell, qui a été corrigée l'année dernière, enchaîne trois vulnérabilités d'Exchange. De fait, l'équipe de réponse à l'incident a rapidement réalisé que les serveurs Exchange compromis où les attaquants avaient obtenu des capacités d'exécution de code à distance étaient entièrement à jour, ce qui signifie qu'il ne pouvait s'agir de ProxyShell. L'ingénierie inverse a confirmé qu'il s'agissait de vulnérabilités inconnues. L'équipe de GTSC a soumis un rapport au programme Zero Day Initiative (ZDI) de Trend Micro, dont les analystes ont confirmé ces vulnérabilités et les ont partagées avec Microsoft.

Deux vulnérabilités exploitées

La nouvelle chaîne d'attaque exploite deux nouvelles failles que Microsoft suit désormais sous les références CVE-2022-41040 et CVE-2022-41082. La première faille concerne un problème de contrefaçon de requête côté serveur (Server-Side Request Rorgery, SSRF) qui permet à un attaquant authentifié de déclencher la seconde vulnérabilité. Celle-ci permet à son tour l'exécution de code à distance via PowerShell. Les failles affectent Microsoft Exchange Server 2013, Exchange Server 2016 et Exchange Server 2019, tandis que Microsoft Exchange Online a déjà mis en place des détections et des mesures d'atténuation. « Il est important de préciser qu'un accès authentifié au serveur Exchange vulnérable est nécessaire pour exploiter avec succès l'une ou l'autre vulnérabilité », a déclaré Microsoft dans son avis. Dans les attaques observées par GTSC chez plusieurs clients, les attaquants ont utilisé l'exploit pour déployer des shells web - des scripts backdoor - se faisant passer pour des fichiers Exchange légitimes comme RedirSuiteServiceProxy.aspx. Ils ont ensuite déployé un logiciel malveillant de dumping des informations d'identification pour voler les identifiants des serveurs compromis. Sur la base du choix des shells web et d'autres artefacts laissés derrière eux, les chercheurs soupçonnent les attaquants d'être chinois. Selon un autre rapport de Cisco Talos, les attaquants ont utilisé Antsword, un shell web open-source populaire en langue chinoise, SharPyShell, un shell web basé sur ASP.NET, et China Chopper. Les attaquants abusent également de certutil, un utilitaire légitime, pour télécharger et déployer des implants.

Les mesures d'atténuation de Microsoft contournables

La solution proposée par le fournisseur consiste à bloquer les modèles d'attaque connus en utilisant le moteur de réécriture d'URL disponible sous « IIS Manager -> Default Web Site -> URL Rewrite -> Actions ». Microsoft a fourni une règle de blocage et écrit un script PowerShell pour automatiser le déploiement. Cependant, un chercheur en sécurité vietnamien, dont l'identifiant Twitter est Janggggg, a fait remarquer lundi que la règle de blocage pouvait être facilement contournée. Ce qu’ont confirmé d'autres chercheurs en sécurité, dont l'ancien analyste du CERT/CC Will Dormann, qui a écrit : « Le '@' dans l'URL « .*autodiscover\.json.*\@.*Powershell.* » recommandée par Microsoft pour bloquer les failles CVE-2022-41040 CVE-2022-41082 semble inutilement précis, et donc insuffisant. Essayez probablement « .*autodiscover\.json.*Powershell.* » à la place ». En plus de cette règle de blocage, Microsoft recommande très fortement aux entreprises de désactiver l'accès à distance à PowerShell pour les utilisateurs non administrateurs, car si les attaquants n’ont pas la possibilité d'accéder à PowerShell à partir d'un compte compromis, cette attaque serait inefficace. Cependant, avec cette solution, les utilisateurs admin sont toujours vulnérables. Reste que, si un utilisateur admin est compromis, les attaquants ont déjà beaucoup de pouvoir. Dans un article séparé, Microsoft explique comment désactiver l'accès à distance à PowerShell pour les utilisateurs et délivre des conseils sur la détection et la chasse aux menaces pour les attaques actuellement en cours. Les rapports de GTSC et de Talos contiennent également des indicateurs de compromission.