Résumé
[Mise à jour du 09 novembre 2022]
L'éditeur a publié un correctif (cf. section solution).
En date du 29 septembre 2022, Microsoft a indiqué l'existence de deux
vulnérabilités, de type zéro-jour, au sein de Windows Exchange 2013,
2016 et 2019.
Ces vulnérabilités sont les suivantes :
- CVE-2022-41040 : Vulnérabilité de type injection de requêtes forgées
côté serveur (Server Side Request Forgery, SSRF) exploitable par
un attaquant authentifié ;
- CVE-2022-41082 : Vulnérabilité permettant à un attaquant authentifié
d'exécuter du code arbitraire à distance.
Dans le cadre d'une attaque, la CVE-2022-41040 peut permettre à un
attaquant d'exploiter à distance la CVE-2022-41082. Selon l'éditeur, ces
deux vulnérabilités ne sont exploitables que si l'attaquant est déjà
authentifié. Un correctif spécifique est en cours de développement
par Microsoft.
Ces vulnérabilités doivent faire l'objet d'une prise en compte
immédiate, car elles ont été utilisées dans le cadre d'attaques ciblées.
Le CERT-FR n'a pour le moment pas connaissance des conditions ayant
permis aux attaquants d'obtenir un accès authentifié sur les serveurs
ciblés.
Le CERT-FR a connaissance de codes d'exploitation publics pour la
CVE-2022-41040.
Le CERT-FR a connaissance
d'incidents en France impliquant l'exploitation de ces
vulnérabilités.
Contournement provisoire
En attendant la publication des correctifs, le CERT-FR recommande
d'appliquer immédiatement les mesures d'atténuation proposées par
Microsoft [1].
L'éditeur recommande fortement de désactiver l’accès à PowerShell à
distance pour les utilisateurs non administrateurs [3]. Le CERT-FR
recommande l'application de cette contre-mesure car il s'agit de la
protection la plus efficace identifiée à ce jour. Il conviendra
de tester la configuration afin d'identifier les éventuels effets de
bord sur les procédures automatisées basées sur Powershell.
Par ailleurs, et de façon complémentaire, Microsoft a publié un code
PowerShell permettant d'appliquer les mesures d'atténuation pour la
CVE-2022-41040 (réécriture de l'URL) [2]. De plus, une mise à jour de
l'outil EEMS (Exchange Emergency Mitigation Service), ainsi que des
éléments pour l'outil AMSI (AntiMalware Scan Interface) ont été
proposés par Microsoft.
Le code PowerShell de Microsoft permettant d'appliquer la mesure
d'atténuation via le module URL Rewrite a été mis à jour pour
renforcer son efficacité contre des variations de la requête
malveillante initialement observée [2]. Afin d'appliquer cette
modification, il est nécessaire de télécharger puis relancer ce nouveau
code ou modifier directement la règle dans le module URL Rewrite avec
la valeur suivante : ".*autodiscover\.json.*Powershell.*
".
Afin de prévenir tout type de coutournement de la règle
".*autodiscover\.json.*Powershell.*
" par le biais d'encodage, le
CERT-FR rappelle qu'il faut modifier la condition d'entrée de la règle
susmentionnée avec la valeur suivante : {UrlDecode:{REQUEST_URI}}
.
Pour plus d'informations, veuillez-vous référer à l'étape 10 du blog de
Microsoft [1].
Le Microsoft Patch Tuesday du 11 octobre 2022 ne propose aucun
correctif pour ces vulnérabilités. Il est essentiel de maintenir
l'application des contournements mentionnés ci-avant.
Détection
Le billet de blogue de l'éditeur documente quelques éléments d'aide à la
détection de ces vulnérabilités [1].
Le CERT-FR recommande de réaliser une analyse approfondie des journaux
réseau des serveurs IIS (sauvegardés par défaut dans le dossier :
%SystemDrive%\inetpub\logs\LogFiles). Les commandes suivantes
permettent d'identifier une exploitation de la vulnérabilité
CVE-2022-41040 :
- sur un système Windows :
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern '/powershell.*autodiscover.json.*200'
;
- sur un système Linux :
cat <Path_IIS_Logs>/*.log | grep -i -e '/powershell.*autodiscover.json.*200'
.
Si une répartition de charge (load-balancing) est mise en œuvre, ces
commandes doivent être appliquées sur les journaux de chacun des nœuds.
Il est possible d'identifier une exploitation réussie de la
CVE-2022-41040 si, à la suite de la première requête, une seconde
requête HTTP de type POST commençant par le motif : /PowerShell
a
été exécutée par le serveur. Dans ce cas là, une analyse forensique des
serveurs Exchange doit être engagée.
En cas de suspicion de compromission, les bons réflexes en cas
d'intrusion sur votre système d'information sont rappelés
ici.
Solution
[Mise à jour du 09 novembre 2022]
Se référer au bulletin de sécurité de l'éditeur pour
l'obtention des correctifs (cf. section Documentation [4]).