CVE-2022-47966 - RCE dans de nombreux produits ManageEngine

TL;DR : Vingt-quatre produits ManageEngine sont vulnérables à un RCE pré-auth. Parmi les services que Censys a pu identifier, 70 % signalent une version logicielle vulnérable.

Si vous utilisez l'un des nombreux produits ManageEngine et que vous avez activé l'authentification SAML SSO, actuellement ou par le passé, mettez-le à jour immédiatement !

Introduction

Le 10 janvier 2023, des détails sont apparus concernant une vulnérabilité affectant vingt-quatre produits ManageEngine différents et pouvant entraîner une exécution de code à distance (RCE) avant l'authentification si l'authentification SAML a été activée. Ces produits vulnérables utilisent une version du projet open-source "Apache Santuario" périmée depuis dix ans. Cette vulnérabilité a été assignée à CVE-2022-47966.

ManageEngine est une entreprise qui développe une large gamme de produits, allant de la gestion des identités aux systèmes de billetterie et d'assistance informatique. Ces produits sont présents dans presque tous les secteurs d'activité qui utilisent la technologie : Le type de données qu'un pirate peut exfiltrer d'un système compromis peut être utilisé pour se déplacer latéralement au sein d'une organisation.

Nous avons constaté que sur l'ensemble des produits ManageEngine que Censys peut identifier, 67% des hôtes sur Internet utilisent une version du logiciel qui peut être vulnérable à cet exploit. Nous utilisons le mot "peut" parce qu'un administrateur doit activer l'authentification SAML SSO sur le service (ou, dans certains cas, l'a activée dans le passé), et Censys n'a pas de moyen de déterminer si c'est le cas (nous voyons juste la réponse HTTP).

Il s'agit d'un simple exploit enveloppé de complexité, d'histoire et de magie technique. Mais avant d'entrer dans les détails des expositions sur Internet, je voudrais décrire le flux général d'une demande d'authentification SAML SSO afin que nous ayons les bons outils pour comprendre pourquoi cette vulnérabilité se produit et pourquoi elle est si facile à exploiter.

(Flux SAML SSO via SalesForce)

En général, lorsqu'un utilisateur tente de se connecter à une application web qui utilise l'authentification SSO basée sur SAML, le serveur web répond par une requête SAML. Le navigateur de l'utilisateur transmet alors cette demande à un "fournisseur d'identité" (défini par l'application web et résidant généralement sur un autre serveur) ; ce fournisseur d'identité analyse alors cette demande SAML et authentifie le client (généralement en lui demandant un nom d'utilisateur et un mot de passe). Une fois que l'utilisateur s'est authentifié auprès du fournisseur d'identité, ce dernier génère une réponse SAML, qui est renvoyée au navigateur du client. À son tour, le navigateur du client enverra cette réponse SAML à l'application web d'origine. C'est maintenant à l'application web de vérifier que la réponse SAML est valide et légitime et qu'elle provient du fournisseur d'identité.

Ce flux général d'authentification SAML SSO signifie qu'un utilisateur peut modifier et altérer le contenu d'une réponse SAML du fournisseur d'identité avant qu'elle ne soit renvoyée à l'application web. Dans la plupart des cas, l'altération sera facilement identifiée par l'application web puisque la réponse contient une signature cryptographique validant que le contenu est correct(XMLDSIG). Et c'est là que les choses commencent à devenir bizarres.

Pour effectuer cette validation de message, les produits ManageEngine utilisent l'API open-source "Apache Santuario", qui gère la complexité de la spécification XMLDSig et le processus de vérification de la section "Signature" d'une réponse SAML. Dans les anciennes versions de cette API, il existait un bogue qui permettait de traiter et de décoder certains éléments de cette section de signature avant de vérifier la validité de l'ensemble du message "Signature".

L'un des éléments de la section "Signature" qui s'exécutera avant la validation comprend la possibilité d'effectuer des transformations basées sur XSLT (un système Turing-complet pour convertir un type de données en un autre) sur l'entrée. Et comme un utilisateur peut modifier la réponse SAML avant qu'elle ne soit renvoyée à l'application web, un pirate peut réaliser une injection XSLT du côté du serveur. Un client malveillant peut construire une charge utile XSLT afin que le runtime Java puisse être chargé par le serveur et utilisé pour exécuter un processus.

Si vous êtes intéressé par les détails de cette vulnérabilité et les recherches précédentes, nous vous recommandons vivement un article du chercheur original(lien d'archive). Ce lien est un bon point de départ pour plus d'informations sur les vulnérabilités d'injection XSLT.

Une preuve de concept a été publiée sur Github, et l'exploitabilité est très triviale. Rapid7 a signalé que cette vulnérabilité a été utilisée dans la nature et a publié plusieurs indicateurs de compromission sur son blog.

Censys Résultats

Bien que l'avis concerne vingt-quatre produits ManageEngine différents, Censys n'a pu trouver en ligne que des références à neuf de ces produits et n'a pu déterminer la version en cours que pour sept d'entre eux. Cela dit, nous ne couvrirons que les détails des produits que nous avons pu associer à un numéro de version. Vous pouvez trouver tous les produits signalés dans la rechercheCensys avec cette requête.

Avant d'entrer dans le détail des versions, voici la répartition de ces produits par pays, les États-Unis occupant la première place avec plus d'un millier d'hôtes uniques.