La majorité des serveurs Exchange sont encore vulnérables

Plus de la moitié des serveurs Exchange exposés sont toujours vulnérables à une vulnérabilité grave qui permet aux attaquants authentifiés d’exécuter du code à distance avec des privilèges système, même huit mois après que Microsoft ait publié un correctif.

La vulnérabilité en question (CVE-2020-0688) se trouve dans le panneau de configuration d’Exchange, le serveur de messagerie et de calendrier de Microsoft. La faille, qui provient du fait que le serveur ne parvient pas à créer correctement les clés uniques au moment de l’installation, a été corrigée dans le cadre des mises à jour régulières du mois de février de Microsoft. Les administrateurs ont été avertis en Mars que les serveurs non corrigés étaient exploités dans la nature par une menace persistante avancée sans nom(APT).

Cependant, une nouvelle télémétrie a révélé qu’après avoir observé 433 464 serveurs Exchange connectés à Internet, au moins 61% des serveurs Exchange 2010, 2013, 2016 et 2019 sont toujours vulnérables à la faille de sécurité.

“Il y a deux efforts importants que les administrateurs Exchange et les équipes infosec doivent entreprendre: vérifier le déploiement de la mise à jour et vérifier les signes de compromis”, a déclaré Tom Sellers de Rapid7 dans une analyse.

Traduction: En parlant d’Exchange, nous avons jeté un autre regard sur Exchange CVE-2020-0688 (tout utilisateur -> SYSTEM sur OWA). C’est TOUJOURS non corrigé à 61%. C’est très dangereux et il existe un module Metasploit pour exploiter la faille.

Cette faille d’Exchange est connue depuis un moment

Les chercheurs ont averti dans un avis de Mars que des serveurs non corrigés sont exploités dans la nature par des acteurs APT anonymes. Les attaques ont commencé fin Février et ont visé «de nombreuses organisations touchées», ont déclaré les chercheurs. Ils ont observé que les attaquants exploitaient la faille pour exécuter des commandes système pour effectuer des reconnaissances, déployer des portes dérobées Webshell et exécuter des frameworks en mémoire, après l’exploitation.

Auparavant, en Avril, les chercheurs de Rapid7 avaient découvert que plus de 80% des serveurs étaient vulnérables; sur 433 464 serveurs Exchange connectés à Internet, au moins 357 629 étaient vulnérables à la faille (au 24 mars). Les chercheurs ont utilisé Project Sonar, un outil d’analyse, pour analyser les serveurs Exchange connectés à Internet et détecter ceux qui étaient vulnérables à la faille.

exchange

Sellers recommandé aux administrateurs de vérifier que la mise à jour a été déployée. La méthode la plus fiable pour faire cela est de vérifier le logiciel de gestion des correctifs, les outils de gestion des vulnérabilités ou les hôtes eux-mêmes pour déterminer si la mise à jour appropriée a été installée, a-t-il déclaré.

«La mise à jour pour CVE-2020-0688 doit être installée sur tout serveur avec le panneau de contrôle Exchange (ECP) activé», a-t-il déclaré. «Il s’agit généralement de serveurs dotés du rôle de serveur d’accès au client (CAS), où vos utilisateurs accèdent à Outlook Web App (OWA).»

microsoft exchange

Avec l’activité en cours, les administrateurs doivent également déterminer si quelqu’un a tenté d’exploiter la vulnérabilité dans leur environnement. Le code d’exploitation que Sellers a testé a laissé des artefacts dans le log des événements Windows et les logs IIS (qui contiennent les hits de cache en mode noyau de l’API du serveur HTTP) sur les serveurs corrigés et non corrigés: «Cette entrée de journal inclura également le compte utilisateur compromis comme un très long message d’erreur qui inclut le texte non valide viewstate », dit-il.

Les administrateurs peuvent également consulter leurs journaux IIS pour les requêtes vers un chemin sous /ecp (généralement /ecp/default.aspx), a déclaré Sellers, ceux-ci doivent contenir la chaîne __VIEWSTATE et __VIEWSTATEGENERATOR – et auront une longue chaîne au milieu de la requête qui est une partie de la charge utile de l’exploit.

«Vous verrez le nom d’utilisateur du nom de compte compromis à la fin de l’entrée du log», a-t-il déclaré. “Un examen rapide des entrées de journal juste avant la tentative d’exploitation devrait montrer les requêtes réussies (code HTTP 200) aux pages Web sous /owa, puis sous /ecp.”

S’abonner
Notifier de
guest
0 Commentaires
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x