CitrixBleed 2: la devastadora vulnerabilidad que lleva más de un mes siendo explotada
La ciberseguridad parece atrapada en un eterno juego del gato y el ratón. Ahora, una nueva vulnerabilidad crítica en dispositivos Citrix (bautizada ya como CitrixBleed 2) lleva semanas siendo explotada activamente, mientras la empresa mantiene un silencio preocupante. Y no, no es la primera vez que esto ocurre con Citrix.
¿Qué es exactamente CitrixBleed 2?
La vulnerabilidad, catalogada como CVE-2025-5777, afecta a los controladores NetScaler Application Delivery Controller y NetScaler Gateway de Citrix, dispositivos que gestionan el equilibrio de carga y el inicio de sesión único en redes corporativas. Esta falla permite a los atacantes sortear la autenticación multifactor, algo que para cualquier responsable de ciberseguridad es una pesadilla hecha realidad.
Lo más preocupante es el parecido con su «hermana mayor», la vulnerabilidad CVE-2023-4966 (o CitrixBleed original) que hace apenas dos años permitió el compromiso de 20.000 dispositivos Citrix y afectó a gigantes como Boeing, el Banco Comercial de China y la firma legal Allen & Overy.
El mecanismo de ataque: cuando la memoria «sangra»
El funcionamiento es bastante similar al CitrixBleed original: los dispositivos vulnerables «filtran» (o «sangran», de ahí el nombre) pequeños fragmentos de memoria cuando reciben solicitudes modificadas a través de internet.
Los atacantes envían repetidamente estas solicitudes maliciosas hasta recopilar suficientes datos para reconstruir credenciales completas. El proceso es metódico y devastadoramente efectivo. La vulnerabilidad tiene una puntuación de gravedad de 9.2 sobre 10, apenas por debajo del 9.8 de su predecesora.
La controvertida gestión de Citrix
Aquí es donde la historia da un giro preocupante. Citrix publicó un parche el 17 de junio y, nueve días después, afirmó no tener «conocimiento de evidencias de explotación». Desde entonces, silencio absoluto.
Sin embargo, los investigadores de seguridad cuentan otra historia. La firma Greynoise encontró evidencias de ataques desde el 1 de julio, y el investigador independiente Kevin Beaumont ha documentado explotación activa desde al menos el 23 de junio, ¡tres días antes de que Citrix afirmara no tener evidencias de ataques!
La falta de transparencia: un regalo para los atacantes
La empresa de seguridad watchTowr publicó un análisis titulado «¿Cuánto más tenemos que sangrar?» criticando duramente a Citrix por retener indicadores que podrían ayudar a los clientes a detectar si estaban bajo ataque. Horizon3.ai se sumó a estas críticas señalando:
«Publicar avisos de seguridad para problemas tan críticos con información tan limitada solo perjudica a los defensores y a los cazadores de amenazas a largo plazo.»
En lugar de proporcionar indicadores públicamente, Citrix ha exigido a los clientes contactar directamente con su equipo de soporte, argumentando que mantener estos detalles en secreto evita alertar a posibles atacantes. Beaumont desmonta este argumento:
«En realidad, la explotación comenzó poco después de la publicación del parche, así que no proporcionar detalles técnicos no ralentizó la explotación: dio a los atacantes ventaja y dejó a los clientes con una falsa sensación de seguridad.»
Cómo funciona el ataque (y cómo detectarlo)
A diferencia de Citrix, los investigadores independientes sí han compartido detalles útiles sobre los ataques. Los exploits están bombardeando el endpoint doAuthentication.do —que gestiona la autenticación para dispositivos Netscaler— con miles de solicitudes de inicio de sesión diarias.
Eventualmente, los dispositivos vulnerables filtran suficientes contenidos de memoria para que los atacantes recuperen los tokens de sesión necesarios para el acceso administrativo.
No basta con parchear
Todos los expertos coinciden: aplicar el parche es solo el primer paso. Los clientes deben utilizar los indicadores proporcionados (por los investigadores, no por Citrix) para identificar signos de que sus dispositivos ya hayan sido comprometidos.
Como apunta Beaumont:
«Si les hubieran dado, por ejemplo, una pista para buscar un gran volumen de solicitudes doAuthentication, podrían haber revisado los registros y las reglas WAF. Esto no sucedió, y ahora probablemente un gran número de organizaciones estarán invocando respuesta a incidentes, en menos de dos años desde CitrixBleed.»
Un patrón preocupante en la industria de ciberseguridad
Lo de Citrix no es un caso aislado. Estamos viendo un patrón donde las empresas de tecnología priorizan su imagen corporativa sobre la seguridad real de sus clientes. Lanzan parches, marcan la casilla de «problema resuelto» y evitan dar detalles que podrían ayudar a detectar compromisos.
Esta actitud genera una falsa sensación de seguridad. Un parche no soluciona una brecha que ya ha sido explotada. Es como cambiar la cerradura después de que el ladrón ya se ha llevado la caja fuerte.
Cuando le preguntaron directamente, Citrix declinó confirmar si conocía la explotación activa. Un representante solo mencionó que «Citrix está comprometido con la transparencia al compartir responsablemente información que pueda ayudar a los clientes».
Las acciones, sin embargo, cuentan otra historia.
Lecciones para responsables de seguridad
Si gestionas infraestructura Citrix, mi consejo es claro:
- Aplica el parche inmediatamente si aún no lo has hecho.
- Revisa los logs buscando grandes volúmenes de solicitudes al endpoint doAuthentication.do.
- Busca solicitudes de autenticación que carezcan de las cabeceras correctas.
- Asume que si tienes dispositivos expuestos y vulnerables, es probable que ya hayan sido comprometidos.
Este incidente no solo subraya la importancia de una respuesta rápida ante vulnerabilidades, sino también la necesidad de transparencia en la industria. Los atacantes no esperan a que estemos listos, y el silencio de los fabricantes solo les da más tiempo para causar daño.
