Zero-Day dans Microsoft Exchange : la mesure d’atténuation déjà contournée !
Suite à la divulgation des deux failles de sécurité zero-day dans Microsoft Exchange, la firme de Redmond a mis en ligne 2 mesures d'atténuation pour que les entreprises puissent se protéger en attendant un correctif de sécurité. Problème, des chercheurs en sécurité sont parvenus à bypasser ces mesures préventives. Faisons le point.
Depuis vendredi 30 septembre 2022, les failles de sécurité CVE-2022-41040 et CVE-2022-41082 font beaucoup parler d'elles, et visiblement, cela n'est pas prêt de s'arrêter avec ce nouveau rebondissement. Pour rappel, c'est l'entreprise GTSC qui est à l'origine de la découverte de ces vulnérabilités signalées à Microsoft par l'intermédiaire de la Zero Day Initiative. Toutes les versions d'Exchange 2013, Exchange 2016 et Exchange 2019 sont affectées, que ce soit les instances on-premise ou en mode hybride connecté à Exchange Online (dans le cas où le serveur Exchange on-premise est exposé sur Internet).
Suite à la publication d'un rapport au sujet de ces failles de sécurité, Microsoft a réagi en confirmant qu'elles étaient utilisées dans quelques attaques. Ensuite, l'entreprise américaine a partagé des solutions temporaires à appliquer pour limiter le risque d'exploitation de ces vulnérabilités.
Premièrement, il convient de bloquer les accès sur les ports 5985 et 5986 associés à la gestion à distance via PowerShell (connexion WinRM). Deuxièmement, il y a une règle à créer dans la configuration de IIS pour bloquer certaines requêtes malveillantes (plus de détails ici). Ceci peut être déployé à l'aide du script officiel EOMTv2.
IIS : une règle insuffisante
Le chercheur en sécurité Jang affirme que cette règle dans IIS est trop limitée et après quelques efforts, il est parvenu à bypasser la règle afin d'exploiter ces vulnérabilités. De son côté, Will Dormann, analyste chez ANALYGENCE, est d'accord avec Jang et il affirme que le "@" dans l'URL fournie par Microsoft "semble inutilement précis, et donc insuffisant.". Pour valider les travaux de Jang, ce sont les chercheurs en sécurité de chez GTSC, à l'origine de la découverte de ces vulnérabilités qui ont validé que la protection n'était pas suffisante.
Pour que la règle soit en mesure de bloquer un plus grand nombre de requêtes malveillantes, elle doit être un peu moins précise. Jang suggère d'utiliser plutôt cette valeur d'URL dans la règle IIS :
.*autodiscover\.json.*Powershell.*
Si vous avez mis en place la règle dans IIS, vous n'avez plus qu'à adapter votre configuration. Microsoft n'a pas confirmé pour le moment qu'il fallait ajuster la règle dans IIS, et un correctif se fait toujours attendre.
La suite au prochain épisode...
