L’éditeur de logiciels Ivanti exhorte les utilisateurs de son produit de sécurité des points finaux à corriger une vulnérabilité critique qui permet à des attaquants non authentifiés d’exécuter du code malveillant au sein des réseaux concernés.
La vulnérabilité, dans une classe connue sous le nom d’injection SQL, réside dans toutes les versions prises en charge d’Ivanti Endpoint Manager. Également connu sous le nom d’Ivanti EPM, le logiciel fonctionne sur diverses plates-formes, notamment Windows, macOS, Linux, Chrome OS et les appareils Internet des objets tels que les routeurs. Les vulnérabilités d’injection SQL proviennent d’un code défectueux qui interprète les entrées de l’utilisateur comme des commandes de base de données ou, en termes plus techniques, de la concaténation de données avec du code SQL sans citer les données conformément à la syntaxe SQL. CVE-2023-39336, lors du suivi de la vulnérabilité Ivanti, a un indice de gravité de 9,6 sur 10 possibles.
« S’il est exploité, un attaquant ayant accès au réseau interne peut exploiter une injection SQL non spécifiée pour exécuter des requêtes SQL arbitraires et récupérer le résultat sans avoir besoin d’authentification », ont écrit vendredi les responsables d’Ivanti dans un article annonçant la disponibilité du correctif. « Cela peut alors permettre à l’attaquant de contrôler les machines exécutant l’agent EPM. Lorsque le serveur principal est configuré pour utiliser SQL Express, cela peut conduire à un RCE sur le serveur principal.
RCE est l’abréviation de exécution de code à distance ou de la possibilité pour les attaquants hors site d’exécuter le code de leur choix. Actuellement, il n’existe aucune preuve connue que la vulnérabilité soit activement exploitée.
Ivanti a également publié une divulgation réservée uniquement aux utilisateurs enregistrés. Une copie obtenue par Ars indique qu’Ivanti a eu connaissance de la vulnérabilité en octobre. La divulgation privée dans son intégralité est :
On ne sait pas clairement ce que signifie « attaquant ayant accès au réseau interne ». Selon l’explication officielle du Common Vulnerability Scoring System, le code utilisé par Ivanti dans la divulgation, AV:A, est l’abréviation de « Attack Vector: Adjacent ». Le système de notation l’a défini comme suit :
Le composant vulnérable est lié à la pile réseau, mais l’attaque est limitée au niveau protocolaire à une topologie logiquement adjacente. Cela peut signifier qu’une attaque doit être lancée à partir du même réseau physique ou logique partagé (par exemple, sous-réseau IP local)…
Dans un fil de discussion sur Mastodon, plusieurs experts en sécurité ont proposé des interprétations. Une personne qui a demandé à ne pas être identifiée explicitement par son nom, son entreprise ou son poste professionnel a écrit :
Tout le reste sur la vulnérabilité [besides the requirement of access to the network] est grave :
- La complexité de l’attaque est faible
- Privilèges non requis
- Aucune interaction utilisateur nécessaire
- La portée de l’impact ultérieur sur d’autres systèmes est modifiée
- L’impact sur la confidentialité, l’intégrité et la disponibilité est élevé
Reid Wightman, chercheur spécialisé dans la sécurité des systèmes de contrôle industriels chez Dragos, a fourni cette analyse :
Spéculation, mais il semble qu’Ivanti applique mal CVSS et le score devrait éventuellement être de 10,0.
Ils disent AV:A (ce qui signifie « accès au réseau adjacent requis »). Cela signifie généralement que l’une des conditions suivantes est vraie : 1) le protocole réseau vulnérable n’est pas routable (cela signifie généralement qu’il ne s’agit pas d’un protocole IP vulnérable), ou 2) la vulnérabilité est en réalité une personne dans le -attaque du milieu (bien que cela ait généralement aussi AC:H, puisqu’une personne du milieu nécessite un accès existant au réseau pour pouvoir lancer l’attaque) ou 3) (ce que je pense), le fournisseur a tort -appliquer CVSS parce qu’ils pensent que leur service vulnérable ne devrait pas être exposé, c’est-à-dire « les utilisateurs finaux devraient avoir un pare-feu en place ».
L’hypothèse selon laquelle l’attaquant doit être un interne aurait un modificateur CVSS de PR:L ou PR:H (privilèges requis sur le système), ou UI:R (incitant un utilisateur légitime à faire quelque chose qu’il ne devrait pas). L’hypothèse selon laquelle l’attaquant dispose d’un autre accès existant au réseau devrait ajouter AC:H (complexité d’attaque élevée) au score. Les deux réduiraient le score numérique.
J’ai eu de nombreuses disputes avec des fournisseurs qui soutiennent (3), en particulier, « personne ne devrait exposer le service, donc ce n’est pas vraiment AV:N ». Mais CVSS ne tient pas compte d’une « bonne architecture réseau ». Il ne s’intéresse qu’à la configuration par défaut et à la question de savoir si l’attaque peut être lancée à partir d’un réseau distant… il ne prend pas en compte les règles de pare-feu que la plupart des organisations devraient mettre en place, en partie parce que l’on trouve toujours des contre-exemples dans lesquels le service est exposé à Internet. . Vous pouvez presque toujours trouver des contre-exemples sur Shodan et similaires. De nombreux « Ivanti Service Managers » exposés sur Shodan par exemple, cependant, je ne sais pas s’il s’agit du véritable service vulnérable.
Un troisième participant, Ron Bowes de Skull Security, a écrit : « Les fournisseurs, en particulier Ivanti, ont l’habitude de minimiser les problèmes de sécurité. Ils pensent que donner l’impression que la vulnérabilité est moins dangereuse leur donne une meilleure apparence, alors qu’en réalité, cela rend simplement leurs clients moins sûrs. C’est une énorme bête noire. Je ne vais pas juger les fournisseurs pour avoir une vulnérabilité, mais je vais les juger pour leur mauvaise gestion.
Les représentants Ivanti n’ont pas répondu aux questions envoyées par courrier électronique.
Placer les appareils exécutant Ivanti EDM derrière un pare-feu est une bonne pratique et contribuera grandement à atténuer la gravité de CVE-2023-39336, mais cela ne fera probablement rien pour empêcher un attaquant ayant obtenu un accès limité au poste de travail d’un employé d’exploiter la vulnérabilité critique. Il n’est pas clair si la vulnérabilité fera l’objet d’une exploitation active, mais la meilleure solution consiste pour tous les utilisateurs d’Ivanti EDM à installer le correctif dès que possible.