Blog: Programme CaRE : les établissements de santé comblent le retard en cybersécurité avec Patrowl
Blog: Vulnérabilités critiques sur Exchange #ProxyNotShell
Auteur: Vlad
Publié le
Jeudi dernier, dans la nuit, comme à chaque fois, une vulnérabilité critique a été annoncée touchant Microsoft Exchange, toutes versions supportées.
Maj du 8/11/2022 : le correctif a été publié dans le bulletin de novembre 🎉
Maj du 12/10/2022 : le correctif est sorti hier ne corrige pas les vulnérabilités décrites ici, il faut continuer d’appliquer les contournement proposés https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2022-exchange-server-security-updates/ba-p/3646263
Maj du 11/10/2022 : le correctif de Microsoft sortira aujourd’hui à 18h GMT.
Jeudi dernier, dans la nuit, comme à chaque fois, une vulnérabilité critique a été annoncée touchant Microsoft Exchange, toutes versions supportées.
La vulnérabilité a été trouvée par une Blue Team vietnamienne (GTSC) qui l’a découverte exploitée dans la nature contre ses clients : https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
Il s’agit d’une chaîne de deux vulnérabilités permettant une prise de contrôle à distance et sans authentification :
- SSRF (CVE-2022-41040), permettant de contourner l’authentification grâce à la fonctionnalité Autodiscover Execution de code PowerShell (CVE-2022-41082), par un appel à PowerShell Remoting depuis le fichier de configuration Autodiscover Exploit
- L’exploit pour la SSRF (CVE-2022-41040) a été publié samedi matin et est massivement utilisé sur Internet mais pour l’instant, sans l’éxecution de code.
Il y a plusieurs moyens de vérifier. Le plus simple me semble être le suivant :
https://MON-SERVER-EXCHANGE.com/autodiscover/autodiscover.json?@outlook.com/&Email=autodiscover/autodiscover.json%3f@MON-DOMAINE-MAIL.com En remplaçant :
MON-SERVER-EXCHANGE.com par le FQDN correspondant à votre serveur Exchange comme mail.monentreprise.com MON-DOMAINE-MAIL.com par votre nom de domaine mail comme monentreprise.com Ensuite, si vous obtenez une erreur 400 avec une erreur JSON, alors vous êtes vulnérable :
Remédiation
Microsoft recommande de mettre en place une réécriture d’URL afin de bloquer les appels à PowerShell Remoting. Tous les détails sont dans leur article, partie « Mitigations » : https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Ils recommandent également de bloquer au niveau des firewalls les ports utilisés pour le PowerShell remoting (TCP 5985 pour l’HTTP et TCP 5986 pour l’HTTPS) mais les risques d’effet de bord me semblent importants donc pour faire simple : si vous n’avez pas d’autres solutions, préférez une panne de certains services à une compromission complète de votre infrastructure mail 😥.
Personnellement, je recommande que vos Exchanges ne sortent pas sur Internet en autre chose que les ports mail standard (25, 465, 587). C’est facilement contournable mais c’est une première barrière, qui bloquera les premiers exploits, ceux totalement automatisés.
Détection
Si vous avez un WAF ou un reverse proxy, vous pouvez detecter (et bloquer) les exploitations de la SSRF contenant l’appel à PowerShell en bloquant lesq requêtes avec cette expression régulière :
.*autodiscover\.json.*PowerShell.*
La recommandation de Microsoft contenant un « @ » est facilement contournable (https://twitter.com/wdormann/status/1576922677675102208). Celle-ci est aussi contournable (sur la casse des lettres par exemple) mais cela permet au moins de bloquer la plupart des attaques automatisées actuelles.
Si vous avez de l’Azure Sentinel, comme l’exploitation de la vulnérabilité d’exécution de PowerShell (CVE-2022-41082) ressemble à du ProxyShell, vous pouvez rechercher avec le filtre suivant :
W3CIISLog
| where csUriStem == « /autodiscover/autodiscover.json »
| where csUriQuery has « PowerShell » | where csMethod == « POST »
https://twitter.com/GossiTheDog/status/1425851771553992709
Vous avez aussi quelques recommandations dans l’article de Microsoft, partie « Detections » : https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Le blog de l’entreprise de cybersécurité vietnamienne propose également des IoC permettant de détecter les exploitations, c’est une première base mais je pense que les heures avançant, des exploits privés chez les cybercriminels vont sortir et l’exploitation pourra être massive, de partout 😩.
Une fois l’Exchange compromis, il y’a plusieurs techniques de persistance utilisées, voici un fil de message avec quelques exemples : https://twitter.com/GossiTheDog/status/1575580072961982464
Bon courage
Blog: Lire les articles privés de plus de 700 000 sites
Blog: D'un warning à une CSRF impactant plus de 3 millions de sites