Comment pirater un serveur Exchange non corrigé avec du code PowerShell escroc

Il y a un peu moins de deux mois, des nouvelles de bogues inquiétantes ont éclaté : une paire de vulnérabilités zero-day a été annoncée dans Microsoft Exchange.

Comme nous l'avons conseillé à l'époque, ces vulnérabilités, officiellement désignées CVE-2022-41040 ainsi que CVE-2022-41082:

[étaient] deux jours zéro qui [pouvaient] être enchaînés, le premier bogue étant utilisé à distance pour ouvrir suffisamment de trou pour déclencher le second bogue, ce qui permet potentiellement l'exécution de code à distance (RCE) sur le serveur Exchange lui-même.

La première vulnérabilité rappelait le problème gênant et largement abusé Trou de sécurité ProxyShell depuis août 2021, car il s'appuyait sur un comportement dangereux dans la fonction de découverte automatique d'Exchange, décrit par Microsoft comme un protocole qui est "utilisé par les clients Outlook et EAS [Exchange ActiveSync] pour trouver et se connecter aux boîtes aux lettres dans Exchange".

Heureusement, la mauvaise fonctionnalité de découverte automatique qui pouvait être exploitée dans l'attaque ProxyShell par n'importe quel utilisateur distant, connecté ou non, était patché il y a plus d'un an.

Malheureusement, les correctifs ProxyShell n'ont pas fait assez pour fermer l'exploit aux utilisateurs authentifiés, ce qui a conduit au nouveau CVE-2022-40140 zero-day, qui a rapidement été laconique, quoique trompeur, doublé ProxyNotShell.

Pas aussi dangereux, mais dangereux quand même

De toute évidence, ProxyNotShell était loin d'être aussi dangereux que le ProxyShell d'origine, étant donné qu'il nécessitait ce qu'on appelle un accès authentifié, il n'était donc pas ouvert aux abus par n'importe qui de n'importe où.

Mais il s'est rapidement avéré que sur de nombreux serveurs Exchange, connaître le nom de connexion et le mot de passe de n'importe quel utilisateur suffirait à passer pour authentifié et à monter cette attaque, même si cet utilisateur aurait lui-même besoin d'utiliser l'authentification à deux facteurs (2FA) pour se connecter correctement pour accéder leur e-mail.

En tant qu'expert Sophos Chester Wisniewski le mettre à l'époque:

C'est une "vulnérabilité de mi-authentification", si vous voulez l'appeler ainsi. C'est une bénédiction mitigée. Cela signifie qu'un script Python automatisé ne peut pas simplement analyser l'ensemble d'Internet et potentiellement exploiter tous les serveurs Exchange du monde en quelques minutes ou heures, comme nous l'avons vu se produire avec ProxyLogon et ProxyShell en 2021. […]

Vous avez besoin d'un mot de passe, mais trouver une combinaison d'adresse e-mail et de mot de passe valide sur un serveur Exchange donné n'est probablement pas trop difficile, malheureusement. Et vous n'avez peut-être pas été exploité à ce jour, car pour vous connecter avec succès à Outlook Web Access [OWA] nécessite leur jeton FIDO, ou leur authentificateur, ou tout autre facteur que vous pourriez utiliser.

Mais cette attaque ne nécessite pas ce deuxième facteur. […] Le simple fait d'acquérir une combinaison de nom d'utilisateur et de mot de passe est une barrière assez faible.

Comme vous vous en souvenez probablement, beaucoup d'entre nous supposaient (ou du moins espéraient) que Microsoft se précipiterait pour résoudre les problèmes de ProxyNotShell, étant donné qu'il restait encore deux semaines avant le patch d'octobre mardi.

Mais nous avons été déçus de constater qu'une solution fiable était apparemment plus complexe que prévu, et octobre est venu et est parti avec ProxyNotShell traité uniquement par des solutions de contournement, pas par des correctifs appropriés.

Même le Patch Tuesday de novembre n'a pas fourni directement les correctifs nécessaires, bien que les correctifs est quand même sorti le même jour dans le cadre d'une mise à jour de sécurité spécifique à Exchange pouvant être récupérée et installée séparément :

La preuve de concept dévoilée

Maintenant que la poussière est retombée et que tout le monde a eu le temps de corriger ses serveurs Exchange (ceux qu'ils n'ont pas oubliés, du moins), les chercheurs de Zero Day Initiative (ZDI), à qui ces vulnérabilités ont été initialement divulguées de manière responsable pour être soumises à Microsoft, ont expliqué comment les bogues peuvent être exploités.

La mauvaise nouvelle, selon votre opinion sur les divulgations d'exploits manifestes, est que l'équipe ZDI a maintenant fourni une preuve de concept (PoC) expliquant comment attaquer les serveurs Exchange.

La bonne nouvelle, bien sûr, c'est que :

• Nous pouvons maintenant étudier et comprendre les bogues nous-mêmes. Cela nous aide non seulement à nous assurer que les précautions globales que nous avons prises (pas seulement limitées aux correctifs) sont susceptibles de fournir la protection que nous attendons, mais nous informent également des pratiques de programmation que nous voudrons éviter à l'avenir, donc nous ne ne soyez pas pris au piège en ouvrant des bogues de ce genre dans notre propre code côté serveur.
• Nous n'avons plus d'excuses pour ne pas appliquer les patchs. Si nous avons traîné des pieds sur la mise à jour, l'explication de ZDI sur la raison pour laquelle l'attaque fonctionne indique clairement que le remède est définitivement préférable à la maladie.

Comment ça marche

ZDI explication de cette vulnérabilité en fait une histoire fascinante sur la complexité d'enchaîner toutes les parties dont vous avez besoin pour transformer une vulnérabilité en un exploit viable.

Il vaut également la peine d'être lu pour vous aider à comprendre pourquoi creuser dans un exploit existant peut aider à révéler d'autres façons dont une vulnérabilité pourrait être utilisée à mauvais escient, provoquant potentiellement des correctifs supplémentaires, incitant à modifier la configuration et promouvant de nouvelles pratiques de programmation qui n'auraient peut-être pas été évidentes. le trou d'origine.

L'explication est, par nécessité, compliquée et assez technique, et vous guide à travers une longue série d'étapes pour parvenir à l'exécution de code à distance (RCE) à la fin.

Dans l'espoir de vous aider à suivre plus facilement les détails de haut niveau si vous décidez de lire le rapport ZDI, voici un résumé, espérons-le, pas trop simplifié avec les étapes répertoriées à l'envers…

… ainsi vous saurez à l'avance pourquoi l'histoire prend la direction qu'elle prend :

• ÉTAPE 4. À distance, trompez Exchange pour qu'il instancie un objet .NET de votre choix, avec un paramètre d'initialisation de votre choix.

Dans le codage moderne, un objet instancié est le mot du jargon désignant un morceau de mémoire alloué, automatiquement initialisé avec les données et les ressources dont il aura besoin pendant son utilisation, et lié à un ensemble spécifique de fonctions qui peuvent fonctionner dessus. (Instancier n'est qu'un mot fantaisiste pour engendrent.)

Les objets peuvent être gérés et contrôlés par le système d'exploitation lui-même, pour aider à éviter le genre d'erreurs de mauvaise gestion de la mémoire courantes dans un langage tel que C, où vous devez généralement allouer de la mémoire vous-même, remplir les champs de données pertinents à la main et n'oubliez pas de libérez la mémoire et les ressources que vous utilisez, telles que les sockets réseau ou les fichiers de disque, lorsque vous avez terminé.

Les objets ont généralement une fonction de programmation qui leur est associée appelée constructeur, qui est automatiquement exécuté lorsqu'un nouvel objet est créé afin d'allouer la bonne quantité de mémoire et le bon ensemble de ressources système.

Habituellement, vous devez passer un ou plusieurs paramètres en tant qu'arguments au constructeur, pour indiquer comment vous souhaitez que l'objet soit configuré au démarrage.

En termes simples, si vous instanciez, disons, un TextString objet (nous créons ces noms, mais vous voyez l'idée) en utilisant un paramètre qui est lui-même une chaîne de texte telle que example.com:8888...

… vous vous retrouverez probablement avec une mémoire tampon allouée pour contenir votre texte, initialisée de sorte qu'elle contienne la même valeur que vous avez transmise, à savoir le texte brut example.com:8888.

Dans ce contexte, la chaîne de texte transmise en tant que données au constructeur d'objet ne pose pas immédiatement de menace de cybersécurité évidente lorsque vous déclenchez le constructeur à distance, autre qu'un éventuel déni de service (DoS) en demandant à plusieurs reprises des chaînes de plus en plus grandes pour essayer d'épuiser la mémoire.

Mais si vous deviez instancier, disons, un ConnectedTCPClient objet utilisant le même paramètre de chaîne de texte que example.com:8888, vous pourriez vous retrouver avec une mémoire tampon prête à contenir des données temporaires, ainsi qu'un socket réseau alloué par le système d'exploitation qui est prêt à échanger des données avec le serveur example.com via le port TCP 8888.

Vous pouvez y voir le risque d'exécution de code à distance, même si vous n'envoyez jamais de données au socket ouvert, étant donné que vous avez trompé le serveur en l'appelant à un emplacement que vous contrôlez.

Vous pourriez même trouver un objet appelé, disons, RunCmdAndReadOutput, où la chaîne de texte que vous envoyez en tant que paramètre est, littéralement, une commande que vous voulez exécuter automatiquement dès que l'objet est créé, afin que vous puissiez collecter sa sortie plus tard.

Même si vous ne parvenez jamais à récupérer la sortie de la commande, la simple instanciation d'un tel objet vous permettrait néanmoins de choisir une commande à exécuter, vous donnant ainsi une exécution générique de code à distance et présentant un risque limité uniquement par les droits d'accès du processus serveur lui-même .

Bien sûr, l'attaque n'est aussi simple qu'une fois que vous avez atteint la dernière étape, ce que vous n'êtes pas censé pouvoir faire, car Exchange a une liste blanche stricte qui vous empêche de choisir un ancien objet à instancier.

En théorie, seuls des objets sûrs ou à faible risque peuvent être créés à distance via PowerShell, de sorte que l'instanciation de notre imaginaire TextString ci-dessus, ou un SimpleIntegerValue, pourrait être considéré comme acceptable, alors qu'un ConnectedTCPClient ou RunCmdAndReadOutput ne le serait certainement pas.

Mais les chercheurs du ZDI remarquent qu'avant de déclencher la dernière étape, ils pouvaient faire ceci :

• ÉTAPE 3. Faites croire à Exchange à distance qu'un objet à faible risque qui a réussi le test de sécurité est, en fait, un autre objet de votre choix.

Même ainsi, vous pouvez vous attendre à ce qu'Exchange empêche la création à distance même d'objets à faible risque, afin de minimiser encore plus la menace.

Mais les chercheurs ont découvert qu'ils pouvaient :

• ÉTAPE 2. Inciter Exchange à distance à utiliser son Accès à distance PowerShell fonctionnalité pour créer un objet basé sur des paramètres d'initialisation contrôlés de l'extérieur.

Et cela a été possible grâce au trou de type ProxyShell qui n'était qu'à moitié corrigé :

• ÉTAPE 1. Incitez Exchange à distance à accepter et à traiter une demande Web avec du code en emballant un username:password champ dans la demande également.

Même si l'utilisateur nommé dans la demande n'était pas réellement connecté et devait passer par une sorte de processus 2FA pour accéder à sa propre boîte aux lettres, un attaquant qui connaissait son username:password La combinaison aurait suffisamment d'informations d'authentification pour inciter Exchange à accepter une connexion Web qui pourrait être utilisée pour lancer la chaîne d'attaque décrite dans les étapes 2 à 4 ci-dessus.

En gros, tout valide username:password combinaison ferait l'affaire, étant donné que « l'authentification » était simplement nécessaire pour empêcher Exchange de rejeter la demande HTTP à l'avance.

Que faire?

Notez que cette attaque ne fonctionne que :

• Si vous avez des serveurs Exchange sur site. Microsoft prétend avoir verrouillé rapidement ses propres services cloud, donc Exchange Online n'est pas affecté. Assurez-vous savoir où se trouvent vos serveurs Exchange. Même si vous utilisez maintenant Exchange Online, vous pouvez toujours avoir des serveurs sur site en cours d'exécution, peut-être laissés par erreur par votre processus de migration.
• Si vos serveurs ne sont pas patchés. Assurez-vous que vous avez appliqué la mise à jour du logiciel Exchange du 2022-11-08 à fermer les vulnérabilités que l'exploit exige.
• Si vos serveurs acceptent toujours l'authentification de base, également appelée authentification héritée. Assurez-vous que vous avez bloqué tous les aspects de l'authentification héritée afin que vos serveurs n'acceptent pas username:password en-têtes mentionnés ci-dessus, et n'acceptera pas les demandes de protocole de découverte automatique risquées en premier lieu. Cette arrête les attaquants inciter un serveur à accepter ses astuces d'instanciation d'objets piégés, même si ce serveur n'est pas corrigé.

Vous pouvez garder une trace de nos conseils officiels de prévention, de remédiation et de réponse, et les clients Sophos peuvent suivre les noms de détection des menaces utilisés par nos produits, via le fil Twitter Sophos X-Ops (@SophosXOps).

De nouvelles informations ont été publiées concernant CVE-2022-41040 et CVE-2022-41082 : https://t.co/pHUVBjUeDI 1/3

– Sophos X-Ops (@SophosXOps) 21 novembre 2022

---

EN SAVOIR PLUS SUR L'AUTHENTIFICATION EXCHANGE ET OAUTH2

Avec Paul Ducklin et Chester Wisniewski
Musique d'intro et d'outro par Edith Mud.

---