Juste au moment où vous espériez que la semaine se calmerait et vous donnerait des temps d'arrêt SecOps pendant le week-end…
… et arrive un tout nouveau trou zero-day dans Microsoft Exchange !
Plus précisément, deux jours zéro qui peuvent apparemment être enchaînés, le premier bogue étant utilisé à distance pour ouvrir suffisamment de trou pour déclencher le deuxième bogue, qui permet potentiellement l'exécution de code à distance (RCE) sur le serveur Exchange lui-même.
Microsoft a rapidement publié orientation officielle sur ces vulnérabilités, en résumant la situation comme suit :
Microsoft enquête sur deux vulnérabilités zero-day signalées affectant Microsoft Exchange Server 2013, 2016 et 2019. La première vulnérabilité, identifiée comme CVE-2022-41040, est une vulnérabilité Server-Side Request Forgery (SSRF), tandis que la seconde, identifiée comme CVE-2022-41082, permet l'exécution de code à distance (RCE) lorsque PowerShell est accessible à l'attaquant.
À l'heure actuelle, Microsoft a connaissance d'attaques ciblées limitées utilisant les deux vulnérabilités pour pénétrer dans les systèmes des utilisateurs. Dans ces attaques, CVE-2022-41040 peut permettre à un attaquant authentifié de déclencher à distance CVE-2022-41082. Il convient de noter qu'un accès authentifié au serveur Exchange vulnérable est nécessaire pour exploiter avec succès l'une ou l'autre des deux vulnérabilités.
Pour autant que nous puissions voir, il y a deux doublures argentées ici :
- Les bogues ne peuvent pas être déclenchés par n'importe qui. Bien sûr, tout utilisateur distant qui s'est déjà connecté à son compte de messagerie sur Internet et dont l'ordinateur est infecté par un logiciel malveillant pourrait en théorie voir son compte détourné pour lancer une attaque exploitant ces bogues. Mais le simple fait d'avoir votre serveur Exchange accessible sur Internet n'est pas suffisant en soi pour vous exposer à des attaques, car les soi-disant appel non authentifié de ces bogues n'est pas possible.
- Blocage Accès à distance PowerShell peut limiter les attaques. Selon Microsoft, le blocage des ports TCP 5985 et 5986 sur votre serveur Exchange limitera (sinon empêchera) les attaquants de s'enchaîner de la première vulnérabilité à la seconde. Bien que des attaques puissent être possibles sans s'appuyer sur le déclenchement de commandes PowerShell, les rapports d'intrusion semblent jusqu'à présent suggérer que l'exécution de PowerShell était une partie nécessaire de l'attaque.
Souvenirs de ProxyShell
Si cette attaque vous rappelle le Vulnérabilité ProxyShell il y a environ un an, vous n'êtes pas le seul à penser cela.
Selon GTSC, la société vietnamienne de cybersécurité qui a été la première enquêté et signalé ces nouveaux trous, les chercheurs "demandes d'exploitation détectées dans les journaux IIS avec le même format que [la] vulnérabilité ProxyShell".
Notamment, le genre de requête de chasse aux menaces que nous avons recommandée pour l'exploit ProxyShell, la spéléologie en 2021 semble également fonctionner pour détecter les abus de ces nouveaux zero-days :
SELECT grep.* FROM file CROSS JOIN grep ON (grep.path = file.path) WHERE file.path LIKE 'C:inetpublogsLogFilesW3SVC%u_ex210[89]%' AND grep.pattern = 'autodiscover.json'
Microsoft aussi note qui "[la détection que nous] avons créée en réponse à ProxyShell peut être utilisée pour les requêtes car il existe des similitudes dans la fonction avec cette menace."
Bien sûr, nous ne savons pas encore si la nouvelle attaque peut être lancée sans laisser ce signe révélateur spécifique dans vos journaux.
En d'autres termes, si vous trouvez des signes déclencheurs similaires à ceux laissés par les exploits PowerShell, vous avez probablement des preuves d'une attaque, mais l'absence de ces signes n'est pas une preuve d'absence.
Selon GTSC, dans les attaques sur lesquelles ils ont enquêté jusqu'à présent, les cybercriminels ont utilisé leurs pouvoirs RCE non autorisés pour implanter et exécuter une variété de logiciels malveillants de suivi, notamment :
- Webshells implantés pour ouvrir une porte dérobée basée sur le Web pour plus tard. Les Webshells permettent généralement aux attaques de suivi d'intégrer des commandes système arbitraires, avec des arguments de commande arbitraires, dans des requêtes HTTP d'apparence normale. Le webshell alors exécute directement la commande souhaitée avec les privilèges du serveur Web lui-même.
- Logiciel malveillant de dumping d'informations d'identification. Les voleurs d'informations d'identification fouillent généralement sur le disque et dans la mémoire (s'ils disposent de privilèges suffisants) à la recherche de mots de passe en clair, cookies de session et des jetons d'authentification qui pourraient permettre ce qu'on appelle mouvement latéral à d'autres ordinateurs du réseau.
- Logiciel malveillant zombie sous la forme de DLL chargées dans des processus d'apparence légitime. Un échantillon de DLL analysé par les chercheurs du GTSC pourrait être alimenté à distance avec des instructions cryptées pour vider les informations système, exécuter des commandes arbitraires, lancer des modules C # et modifier des fichiers et des dossiers sur le système infecté.
Nous mettrons à jour cet article au fur et à mesure que nous en apprendrons davantage, y compris en signalant lorsque Microsoft publie des correctifs pour combler ces lacunes.
Conseils de chasse aux menaces
Pour obtenir des conseils sur la chasse aux menaces de GTSC, qui a découvert et signalé les bogues, de Microsoft et de Sophos, veuillez consulter :
Que faire?
Les atténuations comprennent :
- Block Accès à distance PowerShell pour réduire le risque de RCE. Comme mentionné ci-dessus, le blocage des ports TCP 5985 et 5986 limitera les attaques sur votre serveur Exchange, selon Microsoft.
- Utiliser un Règle de réécriture d'URL pour bloquer les déclencheurs d'attaque connus. GTSC et Microsoft expliquent comment utiliser les règles de réécriture d'URL du serveur IIS pour détecter et neutraliser les formes courantes de cette attaque.
- Assurez-vous que la détection comportementale des menaces sur les terminaux est activée, même sur les serveurs. Comme mentionné ci-dessus, GTSC rapporte que les attaques observées jusqu'à présent incluent l'implantation de webshells et de DLL de logiciels malveillants pour exécuter des commandes arbitraires, manipuler des fichiers et extraire des informations système. Cela vous donne de nombreux indicateurs potentiels de détection et de réponse pour maîtriser une attaque réussie.
- Envisagez de désauthentifier les utilisateurs de messagerie connectés. Si vous pouvez effectuer une sorte d'évaluation de la sécurité des terminaux sur l'appareil de chaque utilisateur avant de les autoriser à se réauthentifier, vous réduirez (mais pas éliminerez) le risque que des appareils déjà compromis soient cooptés pour lancer des attaques. Vous réduirez également ce que l'on appelle votre surface d'attaque en n'ayant pas d'utilisateurs authentifiés qui n'ont pas besoin d'être connectés ou qui ne se souviennent même pas qu'ils se sont connectés en premier lieu.
- Appliquez les patchs dès qu'ils sont disponibles. Jusqu'à présent, seules des attaques limitées ont été signalées, principalement en Asie du Sud-Est, et GTSC retient délibérément les détails des vulnérabilités jusqu'à ce que des correctifs soient disponibles. Mais rappelez-vous qu'une fois les correctifs publiés, les cybercriminels commenceront immédiatement à travailler à rebours vers des exploits fonctionnels dans l'espoir d'attraper ceux qui tardent à appliquer les mises à jour.
Jusqu'à présent [2022-09-30T13:30Z], il semble que les choses les plus importantes à garder à l'esprit sont : [a] les astuces et techniques que vous avez apprises pour traquer les attaques ProxyShell seront presque certainement utiles ici, si pas les seuls outils dont vous pourriez avoir besoin ; [b] malgré les similitudes (et nonobstant tout ce que vous avez pu voir en ligne), ce permettent de garantir que ProxyShell, pour que vos correctifs ProxyShell ne vous en protègent pas ; et [c] lorsque des correctifs arrivent, supposez qu'ils seront rétro-conçus très rapidement pour devenir des exploits fonctionnels, alors ne tardez pas à les appliquer.
EN SAVOIR PLUS SUR LES WEBSHELLS ET COMMENT LES PRÉVENIR
