Une faille LXD notée CVSS 10.0 permet d'usurper un client de confiance sans clé privée dans LXD et MicroCloud de Canonical.

Canonical est confronté à une faille LXD de gravité maximale. Elle touche aussi MicroCloud et obtient un score CVSS de 10.0. Un attaquant peut s’y authentifier comme un client de confiance, sans posséder la clé privée correspondante. Autrement dit, la barrière censée prouver l’identité du client ne joue plus son rôle.

Faille LXD : ce que l’on sait de la vulnérabilité

LXD est le gestionnaire de conteneurs et de machines virtuelles développé par Canonical. MicroCloud, de son côté, sert à déployer rapidement de petits clusters qui s’appuient sur LXD. Les deux produits exposent une API accessible en HTTPS.

Cette API repose sur l’authentification par certificat. Chaque client de confiance est enregistré avec son certificat public. En principe, il doit ensuite prouver qu’il détient la clé privée associée. C’est précisément cette preuve que la vulnérabilité permet de contourner.

Le score de 10.0 est le plus élevé de l’échelle CVSS. Il traduit une exploitation à distance, sans interaction de l’utilisateur et avec un impact très fort. Il faut toutefois rappeler une condition essentielle : l’attaquant doit connaître le certificat public d’un client déjà approuvé.

À ce stade, les informations disponibles ne précisent ni l’identifiant CVE ni les versions corrigées. Les administrateurs doivent donc consulter directement les avis de sécurité de Canonical.

Un scénario d’attaque qui reste à portée de réseau

Deux prérequis sont nécessaires pour exploiter cette faille. D’abord, l’attaquant doit pouvoir joindre l’API HTTPS de LXD ou de MicroCloud. Ensuite, il doit disposer du certificat public d’un client de confiance.

Le second prérequis paraît contraignant, mais il l’est moins qu’il n’y paraît. Un certificat public n’est pas un secret. Il circule souvent dans des fichiers de configuration, des dépôts, des sauvegardes ou des outils d’automatisation. Il peut aussi être observé lors d’une connexion TLS légitime.

Une fois ces éléments réunis, l’attaquant se présente comme le client approuvé. Le serveur le traite alors comme tel. Aucune clé privée n’est nécessaire, et c’est ce qui rend le défaut aussi grave.

Par ailleurs, la condition d’accès réseau dépend de la configuration. Une API ouverte sur Internet ou sur un réseau mal segmenté augmente fortement le risque. En revanche, une API limitée à un réseau d’administration réduit nettement la surface d’attaque.

Quels risques pour les clusters et les machines virtuelles ?

Une fois connecté, l’attaquant agit avec les droits du client usurpé. Il accède alors au cluster et aux machines virtuelles qu’il héberge. Les conséquences dépendent donc du niveau de privilège associé à ce certificat.

Si le compte usurpé dispose de droits étendus, le danger est considérable. Un tel accès peut permettre de consulter, modifier ou supprimer des instances. Il peut aussi servir à manipuler la configuration du cluster. Les données hébergées dans les machines virtuelles deviennent ainsi exposées.

Dans un environnement de production, le scénario est particulièrement sensible. Un cluster MicroCloud regroupe souvent plusieurs services critiques. Par conséquent, la compromission d’un seul client de confiance peut avoir un effet démultiplié.

Par ailleurs, l’usurpation complique la détection. Les journaux montrent une connexion issue d’un certificat connu. Sans corrélation avec les adresses IP source, l’activité peut passer pour légitime.

Comment limiter l’exposition face à la faille LXD ?

La priorité consiste à appliquer les correctifs publiés par Canonical dès qu’ils sont disponibles. En attendant, plusieurs mesures réduisent le risque. Elles relèvent de l’hygiène habituelle pour toute API d’administration.

• Restreindre l’accès réseau : limitez l’API HTTPS à des réseaux d’administration, avec un pare-feu strict et des listes d’adresses autorisées.
• Éviter toute exposition publique : n’ouvrez pas l’API sur Internet sans nécessité absolue.
• Auditer les certificats approuvés : vérifiez la liste des clients de confiance et retirez ceux qui ne servent plus.
• Appliquer le moindre privilège : réduisez les droits des clients, notamment ceux utilisés par des automatisations.
• Surveiller les journaux : recherchez des connexions inhabituelles, même associées à un certificat connu.

Enfin, envisagez de renouveler les certificats clients si vous suspectez une exposition. Cette précaution n’est pas un correctif, mais elle limite la fenêtre d’opportunité.

Ce qu’il faut retenir

• La vulnérabilité touche LXD et MicroCloud de Canonical et atteint un score CVSS de 10.0.
• Un attaquant peut se faire passer pour un client de confiance sans sa clé privée.
• Il doit atteindre l’API HTTPS et connaître le certificat public du client visé.
• L’impact porte sur le cluster et les machines virtuelles, selon les droits du compte usurpé.
• Surveillez les avis de Canonical, installez les mises à jour et fermez l’accès réseau superflu.

Source : CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key