Serveurs Exchange et ProxyShell : comment éviter de laisser rentrer n’importe qui dans son SI ?

L’année 2021 est définitivement une année difficile pour les administrateurs Exchange, et Cheng Da Tsai, alias « Orange Tsai », ce chercheur taïwanais caché derrière son smartphone aux allures de Pikachu n’y est pas totalement étranger !

En décembre 2020 déjà, vous aviez peut déjà vu passer son nom sur le bulletin de Microsoft relatif à la CVE-2020-171171, une vulnérabilité permettant de réaliser une exécution de code arbitraire à distance.

En mars, Microsoft publiait en urgence après s’être fait infiltré par le groupe Hafnium, un correctif pour quatre vulnérabilités exploitées lors de l’attaque2. Parmi ces vulnérabilités, on retrouve ProxyLogon3, une chaîne de deux vulnérabilités pouvant permettre à un attaquant d’ouvrir un webshell à partir de l’interface OWA d’Exchange, les CVE-2021-26855 et CVE-2021-27065, reportées par Orange TSAI le 5 janvier et cosignées par l’équipe de recherche de Microsoft et Volexity. L’histoire ne nous dit pas si le camp des chapeaux blancs les avait trouvées avant les chapeaux noirs…

En avril, rebelote, quatre nouvelles vulnérabilités4 avec une même finalité, une exécution de code arbitraire à distance via l’interface OWA, remontées cette fois-ci par la NSA.

En mai, quatre nouvelles vulnérabilités5, dont deux permettant une exécution de code arbitraire à distance. Parmi ces deux vulnérabilités, la CVE-2021-31195, première partie de la chaîne ProxyOracle6, elle encore découverte par Orange TSAI, pouvant permettre de récupérer le mot de passe d’un utilisateur connecté à sa messagerie en l’incitant gentiment à cliquer sur lien le faisant pointer vers le serveur de l’attaquant.

En juin, Microsoft publie deux nouvelles versions cumulative update, la CU 21 pour Exchange 2016 et la CU 10 pour Exchange 2019. Fin de vie donc pour les versions Exchange 2016 CU 19 et Exchange 2019 CU 8.

En juillet, la phase deux de la chaîne ProxyOracle, la CVE-2021-311967, ainsi qu’une autre exécution de code arbitraire à distance et une élévation de privilèges sont également corrigées8. Cataclysme pour les premiers à patcher, les certificats d’origine générés par Exchange et utilisés lors de la phase d’authentification, sont reconnus comme non conformes et l’accès à l’interface OWA est impossible9. Les explications de Microsoft ne viendront qu’après.
À l’approche de Black Hat, Microsoft nous dit, oups, on avait oublié de vous dire, en avril, on a aussi corrigé les CVE-2021-34473 et CVE-2021-34523. Et la CVE-2021-31207 corrigée en mai était elle aussi un peu passée à travers les mailles du filet. Ces trois vulnérabilités, forment là encore une chaîne permettant d’obtenir un shell avec les droits système sur le serveur Exchange vulnérable, baptisée cette fois-ci, ProxyShell10. Aïe, ça pique ! Dans un environnement Microsoft que l’on connaît, cela voudrait dire, un joli tapis rouge pour aller jusqu’à compromettre l’annuaire Active Directory et l’ensemble du SI.

Le 2 août, Kevin BEAUMONT annonce des scans de serveurs Exchange en cours11.

Le 5 août, Cheng Da TSAI présentait12 ces trois chaînes de vulnérabilités et en dévoilait donc un peu plus sur ProxyShell, notamment comment détecter si un serveur est vulnérable. Apparition de POCs pour scanner la vulnérabilité, reproduction de l’attaque13, des scans massifs, et enfin une explication aux scans observés par Kevin BEAUMONT14.

Le 12 août, Kevin BEAUMONT nous dit, c’est fait ! Les attaquants ont réussi à rentrer15.
Autant dire que si vous avez votre interface OWA non patchée d’exposée sur Internet, vous ne devriez pas tarder à avoir des problèmes.
Apparition au même moment des premiers POCs publiques permettant notamment d’obtenir un shell distant Power Shell en exploitant ProxyShell, via l’interface CAS. Il est assez déconcertant de voir avec quelle facilité il est possible d’accéder à l’administration d’un serveur Exchange à distance, via le port 443 et sans authentification.

Les hostilités sont ouvertes !

Lors de sa conférence à Black Hat, Orange Tsai insistait sur cette nouvelle surface d’attaque que représente pour lui la partie CAS (Client Access Services). Elle joue le rôle de « proxy » pour l’ensemble des services. Pour faire simple, la partie CAS (« front end ») permet à l’ensemble des clients de messagerie (navigateurs Web, Outlook, applications mobiles) de se connecter à un point d’entrée Web unique : le port 443 du serveur Exchange. Le service CAS redirige ensuite vers le service attendu sur la partie « back end ».

À noter que parmi les services en backend, on retrouve un PowerShell distant…

Les trois vulnérabilités présentées par Orange Tsai, ProxyLogon, ProxyOracle et ProxyShell, reposent donc toutes en partie sur l’exploitation de vulnérabilités dans la partie CAS, d’où la structuration de leurs noms ProxyXXX. Exploiter une vulnérabilité dans CAS est très intéressant pour un attaquant car cela lui permettra rapidement d’obtenir les privilèges « système » sur le serveur. Du pain béni pour la suite des opérations…
En conclusion, Orange Tsai nous dit que cette surface d’attaque est trop belle pour ne pas s’y intéresser à nouveau et qu’il a déjà remonté en juin à Microsoft une nouvelle vulnérabilité impactant CAS. Autant dire que toutes les personnes qui risquent de trouver de nouvelles vulnérabilités dans la partie CAS, ne les remonteront pas forcément à Microsoft...

D’après le moteur de recherches Shodan, au moins 4 489 serveurs Exchange seraient vulnérables à ProxyShell en France au 21 août.

Sur un petit panel de moins de 100 de serveurs Exchange d’établissements de santé français, plus de 20 % étaient vulnérables à ProxyShell au 15 août.
Les établissements concernés ont été prévenus par le CERT-Santé.

Depuis la publication de la présentation d’Orange Tsai à Black Hat, une activité de scan permanente est observée. Pour ma part, sur la journée du 20 août par exemple, j’ai pu observer plus de 10 scans.

Vous pouvez retrouver cette activité de scan assez facilement dans vos logs (pare-feu, reverse proxy, WAF, SIEM…) , en effectuant une recherche sur cette partie de la requête HTTP :

/autodiscover/autodiscover.json?

Parmi les requêtes complètes observées :

GET /autodiscover/autodiscover.json?@1337.com/owa/?&Email=autodiscover/autodiscover.json%3F@1337.com
GET /autodiscover/autodiscover.json?@abc.com/owa/?&Email=autodiscover/autodiscover.json%3F@abc.com
GET /autodiscover/autodiscover.json?@foo.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3F@foo.com
GET /autodiscover/autodiscover.json?jzuyt@hkang.zzs/mapi/nspi/?&Email=autodiscover/autodiscover.json?jzuyt@hkang.zzs
POST /autodiscover/autodiscover.json?a=Administrator@{domaine du serveur de messagerie}/autodiscover/autodiscover.xml
POST /autodiscover/autodiscover.json?a=biqbi@hgiap.kmw/autodiscover/autodiscover.xml

Les deux premières reviennent fréquemment car inscrites dans les premiers POCs de scan publiques que j’ai pu voir apparaître sur la toile.
La troisième revient également fréquemment car elle est disponible telle qu’elle dans la présentation d’Orange Tsai.

Pour bien comprendre, si une requête HTTP du type :

GET /autodiscover/autodiscover.json?@test.com/owa/?=&Email=autodiscover/autodiscover.json?@test.com

Retourne un code HTTP 302 (Found) en réponse, le serveur Exchange est vulnérable à ProxyShell. Il est donc très simple d’identifier un serveur vulnérable.

Un serveur vulnérable répondra aussi sur l’url ci-dessous :

https://serveur-exchange/autodiscover/autodiscover.json?@test.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3F@test.com

En visualisant la page affichée, vous comprendrez très vite l’étendue des dégâts possibles :

Amis RSSI et admin sys, si vous souhaitez tester le niveau de vulnérabilité de vos serveurs Exchange, je vous propose d’utiliser ChopChop (un outil en Go développé par Michelin), ainsi que mon fichier de configuration dédié à Exchange (exchange-server.yml), disponible ici :

https://github.com/woundride/chopchop_configuration_files

Ce fichier vous permettra de savoir si vos serveurs sont vulnérables à ProxyShell, mais aussi de connaître rapidement le numéro de CU Exchange et si celle-ci est vulnérable ou non :

ChopChop est proposé avec des versions compilées pour de nombreux systèmes, notamment Linux et Windows. Il est donc facilement utilisable. Si vous avez plusieurs serveurs à scanner, dans le cas d’un GHT ou d’un CERT par exemple, il est possible d’utiliser un fichier texte / csv contenant l’ensemble des URL des serveurs à scanner, ainsi que de réaliser un export des résultats au format CSV. Vous pourrez retrouver toutes les informations nécessaires à son utilisation et son téléchargement sur le lien Github proposé précédemment.

Un scan réalisé avec ChopChop et mon fichier de configuration pourront éventuellement être identifiés à l’aide de ces éléments :

GET /autodiscover/autodiscover.json?@test.com/owa/?=&Email=autodiscover/autodiscover.json?@test.com
User-Agent: Go-http-client/1.1
Ja3 Hash : b102b73a090f4079a02e520bc16cc6cf
Ja3 Hash : df669e7ea913f1ac0c0cce9a201a2ec1

La requête HTTP présentée ici peut être réalisée à l’aide d’autres outils, elle ne permet donc pas à elle seule d’identifier avec certitude l’origine du scan. Vérifiez que l’adresse émettrice de la requêtes est bien celle avec laquelle vous avez lancé votre scan.

Il est également possible, pour les serveurs dont les entêtes Exchange ne sont pas masquées, de connaître facilement le numéro de build, et par conséquent l’état de patching d’un serveur à l’aide de Curl :

curl -kv --stderr - https://serveur-exchange/owa/ | grep -e X-OWA-Version -e x-owa-version

Les numéros de builds et les correspondances avec le niveau de patching sont disponibles sur le site de Microsoft16.

Kevin Beaumont propose également un script NMAP permettant de tester la vulnérabilité à ProxyShell d’un serveur17.

La société Emerging Threat (Proof Point) propose depuis le 9 août dans son package communautaire18, des règles de détection de l’exploitation de ProxyShell pour Suricata et Snort.

Seul bémol, le déchiffrement du flux HTTPS est nécessaire.

Pour conclure, si vous n’êtes toujours pas convaincu de l’urgence d’appliquer le correctif de sécurité sur vos serveurs Exchange, sachez que le groupe derrière le rançongiciel LockFile utilise déjà ProxyShell pour s’infiltrer dans les SI de ses victimes, comme nous pouvons le lire dans l’excellent article de Kevin Beaumont sur le sujet19. La méthode est assez simple et efficace, entrée via ProxyShell sur le serveur Exchange vulnérable, utilisation de PetitPotam20 pour faire du relais NTLM (vulnérabilité corrigée dans le patch tuesday d’août) et prendre le contrôle de l’annuaire Active Directory, et pour finir, création de GPO pour le déploiement en masse du rançongiciel. La recette est imparable !

Pour finir, à la lecture des diapos de Cheng Da TSAI, je reste abasourdi par la réponse qu’il a reçu de la part de Microsoft lorsqu’il a remonté la chaîne de vulnérabilités ProxyLogon : pas de bounty pour la découverte de ces vulnérabilités car Exchange On Premise est hors scope (euh… si j’ai bien compris, ProxyLogon a aussi servi à infiltrer Office 365…) . Manque de respect pour le chercheur tout d’abord, qui enlève de grosses épines du pied à l’éditeur et aussi manque de respect pour les clients qui payent chaque année une rente à Microsoft et qui méritent que les chercheurs s’intéressent à l’ensemble des produits supportés !


1 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17117

2 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065

3 https://youtu.be/SvjGMo9aMwE

4 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28480

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28481

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28482

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28483

5 https://msrc.microsoft.com/update-guide/fr-fr/vulnerability/CVE-2021-31198

https://msrc.microsoft.com/update-guide/fr-fr/vulnerability/CVE-2021-31207

https://msrc.microsoft.com/update-guide/fr-fr/vulnerability/CVE-2021-31209

https://msrc.microsoft.com/update-guide/fr-fr/vulnerability/CVE-2021-31195

6 https://youtu.be/VuJvmJZxogc

7 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31196

8 https://portal.msrc.microsoft.com/security-guidance/advisory/CVE-2021-31206

https://portal.msrc.microsoft.com/security-guidance/advisory/CVE-2021-34470

9 https://www.dsih.fr/article/4331/correctif-de-securite-exchange-de-juillet-ce-qu-il-faut-savoir-avant-de-tout-casser.html

10 https://youtu.be/FC6iHw258RI

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34473

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34523

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31207

https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell

11 https://twitter.com/GossiTheDog/status/1422178411385065476

12 https://www.blackhat.com/us-21/briefings/schedule/index.html#proxylogon-is-just-the-tip-of-the-iceberg-a-new-attack-surface-on-microsoft-exchange-server-23442

13 https://peterjson.medium.com/reproducing-the-proxyshell-pwn2own-exploit-49743a4ea9a1

https://y4y.space/2021/08/12/my-steps-of-reproducing-proxyshell/

14 https://twitter.com/GossiTheDog/status/1423603304442081280

15 https://twitter.com/GossiTheDog/status/1425844380376735746

16 https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates

17 https://github.com/GossiTheDog/scanning/blob/main/http-vuln-exchange-proxyshell.nse

18 https://rules.emergingthreats.net/

19 https://doublepulsar.com/multiple-threat-actors-including-a-ransomware-gang-exploiting-exchange-proxyshell-vulnerabilities-c457b1655e9c

20 https://github.com/topotam/PetitPotam

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857

Partager ce document sur les réseaux

?>