[ad_1]
Les acteurs de la menace exploitent activement les serveurs Microsoft Exchange en utilisant la vulnérabilité ProxyShell pour installer des portes dérobées pour un accès ultérieur.
ProxyShell est le nom d’une attaque qui utilise trois vulnérabilités Microsoft Exchange chaînées pour exécuter du code à distance non authentifié.
Les trois vulnérabilités, énumérées ci-dessous, ont été découvertes par Orange Tsai, chercheur principal en sécurité de Devcore, qui les a enchaînées pour prendre le contrôle d’un serveur Microsoft Exchange lors du concours de piratage Pwn2Own 2021 d’avril.
La semaine dernière, Orange Tsai a donné une conférence Black Hat sur les récentes vulnérabilités de Microsoft Exchange qu’il a découvertes en ciblant la surface d’attaque du service d’accès client (CAS) de Microsoft Exchange.
Tsai a révélé que l’exploit ProxyShell utilise la fonction de découverte automatique de Microsoft Exchange pour effectuer une attaque SSRF dans le cadre de la conversation.
Après avoir regardé la conférence, les chercheurs en sécurité PeterJson et Nguyen Jang ont publié des informations techniques plus détaillées sur la reproduction réussie de l’exploit ProxyShell.
Peu de temps après, le chercheur en sécurité Kevin Beaumont a commencé à voir des acteurs malveillants rechercher des serveurs Microsoft Exchange vulnérables à ProxyShell.
ProxyShell activement exploité pour déposer des webshells
Aujourd’hui, Rich Warren, chercheur en vulnérabilité de Beaumont et NCC Group, a révélé que des acteurs malveillants ont exploité leurs pots de miel Microsoft Exchange à l’aide de la vulnérabilité ProxyShell.
Lorsqu’ils exploitent Microsoft Exchange, les attaquants utilisent une URL initiale telle que :
https://Exchange-server/autodiscover/autodiscover.json?@foo.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3F@foo.com
Remarque : L’adresse e-mail répertoriée dans l’URL ne doit pas nécessairement exister et changer entre les attaquants.
L’exploit dépose actuellement un webshell d’une taille de 265 Ko dans le dossier ‘c:inetpubwwwrootaspnet_client’.
La semaine dernière, Jang a expliqué à BleepingComputer que 265 Ko est la taille minimale des fichiers pouvant être créés…
Voir la source de cette publication
[ad_2]