Falla crítica en LXD y MicroCloud permite suplantar clientes de confianza sin clave privada

Una vulnerabilidad crítica en LXD y MicroCloud de Canonical permitía a un atacante iniciar sesión como un cliente de confianza sin contar con la clave privada de ese cliente. Para lograrlo, el atacante necesitaba alcanzar la API HTTPS a través de la red y disponer del certificado público del cliente legítimo. Una vez dentro, podía actuar en nombre de ese cliente y acceder al clúster y a sus máquinas virtuales. Si la cuenta suplantada tenía privilegios elevados, el atacante podía obtener acceso root a la máquina anfitriona, según informó Canonical. La falla, identificada como CVE-2026-112816, tiene una puntuación CVSS máxima de 10.0, y la empresa ya lanzó versiones corregidas de ambos productos.

Cómo funciona la falla

LXD y MicroCloud permiten que clientes remotos accedan a sus API mediante TLS mutuo, un esquema en el que el cliente presenta un certificado para demostrar su identidad. Un cliente se considera de confianza cuando su certificado está en el almacén de confianza del servidor, es decir, la lista de identidades que el servidor aceptará. El fallo residía en la forma en que el servidor verificaba ese certificado: comparaba todos los certificados enviados por el cliente contra el almacén de confianza, pero una conexión TLS solo demuestra que el cliente posee la clave privada del primer certificado de la cadena, el certificado hoja. El resto de la cadena está compuesto por los certificados que el cliente decida adjuntar. Así, un atacante podía tomar el certificado público de un cliente de confianza, que no es secreto, adjuntarlo a la cadena detrás del suyo propio, y el servidor lo aceptaba como ese cliente.

Quiénes están afectados

Aprovechar la falla requiere dos condiciones: acceso de red a la API HTTPS y el certificado público de un cliente en el que el servidor ya confía. Un servidor LXD autónomo no expone esa API por defecto; solo escucha en un socket local a menos que un administrador habilite la API de red con la configuración core.https_address. MicroCloud, que agrupa varias máquinas con LXD en un solo clúster, tiene un punto débil específico: según Canonical, un atacante que pueda capturar el certificado público de un miembro mientras se une al clúster puede luego iniciar sesión como ese miembro. El registro CVE enumera como afectadas las versiones LXD 4.0.14, 5.0.10, 5.21.8 y 6.9, cada una anterior a la versión corregida correspondiente. Canonical indica las siguientes versiones corregidas de snap:

  • LXD 4.0.15
  • LXD 5.0.11
  • LXD 5.21.9
  • LXD 6.10

El error no se originó en Canonical. El proyecto Incus, que comenzó como un fork comunitario de LXD, lo reportó, y Canonical confirmó que también afectaba a LXD. Incus corrigió la misma falla en su versión 7.6.0. Los paquetes de LXD en el archivo de Ubuntu figuran como no afectados o no distribuidos, por lo que las versiones corregidas son los snaps. No hay indicios públicos de que la falla se haya utilizado en un ataque. El registro CVE incluye una evaluación de CISA con fecha 30 de octubre que señala que no se conoce su explotación; no está en la lista de vulnerabilidades explotadas conocidas de CISA y no se ha publicado ningún exploit funcional.

Qué hacer

Actualice LXD y MicroCloud a las versiones corregidas. En una instalación por snap, ejecute sudo snap refresh lxd y sudo snap refresh microcloud. Canonical advirtió que, al momento de su aviso, las versiones puntuales corregidas de LXD aún se estaban distribuyendo desde el canal candidato al estable, por lo que conviene verificar la versión realmente instalada tras la actualización en lugar de asumir que la corrección ya se aplicó. El aviso de Canonical no ofrece una solución temporal para LXD. Dado que el ataque requiere acceso de red a la API, limitar quién puede alcanzarla reduce el riesgo hasta que se actualice. El proyecto Incus, al reportar la misma falla, indicó que no existe una corrección de configuración y que la única medida es restringir el acceso de red al listener. Los usuarios de Incus deben pasar a la versión 7.6.0, que corrigió esta falla junto con otros 17 problemas de seguridad.

Cybersecurity
Cybersecurity
Cybersecurity
Cybersecurity

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *