23 avril 2021

ProxyLogon, une vulnérabilité unique qui fit trembler les serveurs Exchange

Introduction

Vous avez sûrement entendu parler de cette vulnérabilité dont tout le monde parle ces dernières semaines, je nomme ProxyLogon ! Mais que ce cache-t-il réellement derrière cette faille ?

Pour répondre à cette question, il faut remonter dans le temps de quelques mois. C’est en octobre 2020 que des chercheurs de la société de conseil DEVCORE ont commencé à s’intéresser aux sécurités relatives des serveurs Exchange de Microsoft. Ce n’est que deux mois plus tard, que la première vulnérabilité permettant de contourner l’authentification et de devenir « admin » a été découverte. Référencée sous la CVE-2021-26855, cette vulnérabilité met en lumière la possibilité de forger une requête cotée serveur (SSRF), permettant à un attaquant de lire l’intégralité des e-mails des utilisateurs configurés sur le serveur de messagerie Exchange cible. De cela s’en suit la découverte d’une seconde vulnérabilité (CVE-2021-27065), rendant possible l’exécution de commandes à distance avec les privilèges de compte SYSTEM via une écriture de fichier arbitraire post-authentification. De là, est né ProxyLogon, qui en chaînant ces vulnérabilités, rend possible l’exécution de code arbitraire à distance en préauthentification.

Le diagramme ci-dessous récapitule les étapes menant jusqu’à l’exécution de code via les différents chemins possibles :

Figure 1 : Diagramme récapitulant l’ensemble des chemins possibles menant à l’exécution de code sur les serveurs Exchange via ProxyLogon

La CVE-2021–26857 ne fait pas réellement partie de la chaîne d’attaque ProxyLogon à proprement parlé car elle ne nécessite pas d’exploiter au préalable d’autres vulnérabilités telles que la SSRF. La vulnérabilité CVE-2021–26857 est liée à une désérialisation non sécurisée des données dans le service de messagerie unifiée. L’exploitation de cette vulnérabilité nécessite que le rôle de messagerie unifiée soit installé et configuré sur le serveur Exchange. Comme ce rôle est rarement utilisé, aucune exploitation de cette vulnérabilité n’a été signalée à ce jour.

Figure 2 : Timeline retraçant les étapes de ProxyLogon allant de sa découverte aux premiers POC

La timeline ci-dessus synthétise les différentes étapes de la vulnérabilité ProxyLogon allant de sa découverte jusqu’au premiers POC et mitigation.

CVE-2021-26855, quand le serveur se met à « parler » grâce à la SSRF

ProxyLogon est le nom de la vulnérabilité CVE-2021-26855 (SSRF) qui permet à un attaquant externe de contourner le mécanisme d’authentification MS Exchange et de se faire passer pour n’importe quel utilisateur. En forgeant une requête côté serveur, un attaquant peut envoyer une requête HTTP arbitraire qui sera redirigée vers un autre service interne au nom du compte d’ordinateur du serveur de messagerie. Pour exploiter la SSRF, un attaquant doit générer une requête POST spécialement conçue pour un fichier statique dans un répertoire lisible sans authentification, tel que « /ecp/y.js », où la présence du fichier dans le répertoire n’est pas requise. Le corps de la requête POST sera également redirigé vers le service spécifié via le cookie nommé X-BEResource.

En conséquence directe, un attaquant pourrait forger des demandes de lecture d’e-mails des utilisateurs configurés sur ce serveur de messagerie.

L’exploitation de cette SSRF nécessite au moins deux serveurs MS Exchange dans l’infrastructure attaquée. Afin d’illustrer nos propos, prenons l’exemple suivant : une requête est envoyée à exchange.bssi.local via l’API EWS en utilisant une requête SOAP qui est redirigée via SSRF vers exchange2.bssi.local. Dans notre exemple, nous allons récupérer les 15 derniers e-mails de la boîte aux lettres de thomas@bssi.local.

Figure 3 : Exploitation de la SSRF permettant notamment de lire les e-mails des utilisateurs du serveur Exchange

Cette requête (à gauche) contient une charge utile XML SOAP dirigée vers le point de terminaison API des services Web Exchange (EWS). La demande SOAP ci-dessus contourne l’authentification à l’aide du cookie X-BEResource spécialement conçu pour permettre d’exécuter des demandes EWS inscrites dans la charge utile XML, ici, lire les 15 derniers e-mails de l’utilisateur Thomas.

De cette façon, tous les e-mails d’un utilisateur donné peuvent être téléchargés à partir du serveur sans authentification.

CVE-2021-26858 et CVE-2021-27065 for the win

Ces deux vulnérabilités d’écriture de fichiers arbitraires post-authentification permettent à un utilisateur authentifié d’écrire des fichiers sur n’importe quel chemin d’un serveur Exchange vulnérable. Un attaquant pourrait alors tirer parti de la vulnérabilité SSRF mentionnée précédemment pour obtenir un accès administrateur et exploiter cette vulnérabilité afin d’écrire des « web shells » (interpréteurs de commandes Web) dans des répertoires virtuels (VDirs). Il est bon de rappeler que Microsoft IIS est le serveur Web de Microsoft, une dépendance qui est installée avec Exchange Server et permet de mettre à disposition des services pour Outlook sur le Web (OWA, Outlook Anywhere, ActiveSync ECP, OAB, etc.).

De manière concrète, l’attaque consiste à s’authentifier auprès du panneau de contrôle Exchange (ECP), dans le but d’exploiter les vulnérabilités CVE-2021–26858 / CVE-2021–27065 afin de téléverser un « web shell » sur le serveur. Pour interagir avec l’ECP, une session complète doit être établie avec ce dernier. Le seul prérequis est donc de connaître le SID du compte de l’administrateur du serveur de Exchange afin d’usurper son identité et se faire passer pour l’administrateur lors de la configuration de la session.

Typiquement, le workflow permettant l’exploitation de ces vulnérabilités est le suivant :

  • Obtenir le « LegacyDN » et l’identifiant du compte de messagerie administrateur en envoyant une requête à l’autodiscover via la SSRF
  • Envoyer une requête à l’MAPI afin de récupérer le SID du compte de messagerie administrateur. En effet, l’envoie d’une demande de délégation d’accès au compte de messagerie est également transmise à MAPI en tant qu’utilisateur du compte de la machine et provoque une erreur d’accès qui contient le SID du compte de messagerie administrateur.
  • Après avoir obtenu le SID, il est maintenant possible de s’authentifier sur le serveur en se faisant passer pour l’administrateur en envoyant une requête POST spécialement conçue à « /ecp/proxyLogon.ecp ». Cette usurpation d’identité s’obtient en utilisant un en-tête nommé msExchLogonMailBox avec le SID de l’administrateur. En réponse à cette requête, le serveur Exchange renvoie deux cookies nommés ASP.NET_SessionId et msExchEcpCanary qui nous permettent de nous authentifier auprès de ce dernier.
  • Une fois authentifié, il suffit d’envoyer une requête au Service DDI (/ecp/DDI/DDIService.svc) afin de réinitialiser le dossier virtuel OAB. L’interface web du panneau de contrôle Exchange expose deux paramètres lors de la réinitialisation (l’URL interne et l’URL externe) décrits dans le XAML (en tant que paramètres et écrits dans le fichier vers notre chemin arbitraire) qui peuvent être contrôlés par un utilisateur. Lors de la réinitialisation, il est demandé d’enregistrer la configuration actuelle vers le chemin de notre choix. Nous pouvons donc spécifier le chemin « C:\test.aspx » pour enregistrer notre fichier de configuration afin d’obtenir un accès au fichier aspx qui sera utilisé en tant que « web shell ». L’exécution de code sera rendue possible via l’insertion de la charge utile (cf Figure 4) dans le paramètre d’URL externe. Cette combinaison de facteurs permet donc à un attaquant d’atteindre un chemin arbitraire dans le but d’interagir avec un « web shell » au format aspx.
Figure 4 : Charge utile mettant à disposition un paramètre POST « rce » permettant l’exécution de code arbitraire à distance

Une vidéo de preuve de concept du chercheur ayant découvert ProxyLogon est également disponible et montre comment un attaquant non authentifié est en mesure d’exécuter du code arbitraire à distance sur le serveur Exchange.

Le FBI à la rescousse des serveurs Exchange

C’est le 2 mars 2021 que Microsoft a publiquement révélé la vulnérabilité ProxyLogon au grand public. Cependant, le FBI a pu détecter des intrusions dès janvier 2021 sur les serveurs Exchanges de nombreuses entreprises. A l’origine d’une grande partie des intrusions, le groupe APT (Advanced Persistant Threat) chinois Hafnium qui a exploité cette vulnérabilité dans le but d’exfiltrer des données d’entreprises et organisations, principalement américaines, dans des secteurs variés.

FBI Head of Cybersecurity in San Francisco Warns: Look to Inside Threats –  Homeland Security Today
Figure 5 : Le FBI à la rescousse des serveurs Exchange

Malgré le correctif proposé par Microsoft et appliqué par 92% des 400 000 machines vulnérables, de nombreux serveurs déjà infectés sont toujours à la merci des attaquants. Afin de venir en aide à ces entreprises, le tribunal américain, de part un décret, a accepté de manière exceptionnelle une opération du FBI qui a pour but de nettoyer à distance les serveurs Exchange infectés à l’instar d’un attaquant, mais cette fois-ci bienveillant ! Les entreprises victimes ne se doutaient de rien quant à l’accès de leurs serveurs par le FBI. L’opération consistait plus précisément à se connecter au serveur par la même porte d’entrée (ProxyLogon) que les attaquants puis de supprimer le web shell (fichier web, ici au format aspx, interprété par les serveurs IIS d’Exchange, permettant aux attaquants d’exécuter directement des commandes système sur la machine via ce fichier) installé sur les serveurs.

Cette mesure permettant de stopper les attaquants et de purger les serveurs infectés est une grande première aux États-Unis.

Correction et solutions de contournement

Afin de se prémunir contre ProxyLogon, il est indispensable d’installer le correctif nécessaire KB5000871 même si vous êtes en mode hybride avec Exchange Online / Office 365. Étant donné que la mise en place d’un correctif sur un environnement en production n’est pas aussi simple que ça (planification, correctifs cumulatifs, versions non récentes, etc.), Microsoft à mit à disposition une solution de contournement qui reconfigure les éléments suivants :

  • Implémentation d’une règle de réécriture IIS pour filtrer les requêtes https malveillantes
  • Désactivation de la messagerie unifiée (UM)
  • Désactivation du VDir du panneau de configuration Exchange (ECP)
  • Désactivation du carnet d’adresses en mode hors connexion (OAB) VDir

La reconfiguration peut être effectuée via un script PowerShell mit à disposition par Microsoft sur leur dépôt Github.

Bien évidemment, cette solution de contournement peut causer des effets de bords sur le serveur Exchange et ne garantit en rien une correction totale (l’installation du KB5000871 restant prioritaire).

La porte d’entrée étant la SSRF causée par l’exposition du serveur Exchange sur le port 443/https, il est également recommandé que l’accès Web au serveur Exchange soit limité aux seules adresses IP internes autorisées ou que cela soit placé derrière un VPN qui ne peut être accessible que par les utilisateurs authentifiés.

Volexity a partagé une liste d’indicateurs de compromission (IOC) afin de s’assurer qu’aucune activité malveillante a été effectuée sur le serveur Exchange. De son côté, Microsoft a publié un script permettant d’analyser les fichiers journaux Exchange à la recherche d’indicateurs de compromission. Une manière proactive de se protéger serait de « chasser » et de surveiller tous comportement anormale (création de web shells, réinitialisation du dossier virtuel OAB, etc.).

Ci-dessous, les versions exactes des serveurs Exchange affectés par ProxyLogon :

  • Exchange Server 2019 < 15.02.0792.010
  • Exchange Server 2019 < 15.02.0721.013
  • Exchange Server 2016 < 15.01.2106.013
  • Exchange Server 2013 < 15.00.1497.012

Enfin, il est important de s’assurer qu’aucune donnée n’a été exfiltrée ou que des comptes n’ont été compromis ou ajoutés par des acteurs malveillants. Même lorsqu’aucune trace de compromission n’a été détectée sur le serveur, des acteurs malveillants auraient pu effacer leur trace tout en conservant un accès aux machines.

Conclusion

Nous avons pu voir de par cet article, l’impact qui peut être produit par le « chaînage » de plusieurs vulnérabilités (SSRF, écriture de fichiers arbitraires, etc.) résultant en une exécution de code arbitraire à distance en préauthentification sur les serveurs Exchange.

ProxyLogon est aujourd’hui sous contrôle. En effet, la quasi-totalité des serveurs Exchange exposés sur internet est aujourd’hui protégée contre cette attaque. Une réponse rapide de Microsoft avec la mise en place d’un correctif de sécurité a permis d’endiguer et de stopper la propagation des attaquants. Malgré cette réaction exceptionnelle de la part du géant américain, plusieurs APT ont profité de ProxyLogon. En effet, on ne dénombre pas moins d’une dizaine d’APT dont Hafnium, qui ont exploités des serveurs Exchange. Autrement dit, outre les mesures de préventions, certaines organisations devront aussi « nettoyer » leurs systèmes d’information à la recherche de potentielles traces laissées par des attaquants.

Sources

https://thehackernews.com/2021/03/proxylogon-exchange-poc-exploit.html

https://www.praetorian.com/blog/reproducing-proxylogon-exploit/

https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/

https://proxylogon.com/

https://www.exploit-db.com/exploits/49637

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

23 avril 2021 CERT

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *