¿Qué es una vulnerabilidad de día cero?

Vulnerabilidad, exploit y ataque de día cero

Los tres términos suelen usarse como sinónimos, pero describen cosas distintas:

• Vulnerabilidad de día cero: el propio fallo, desconocido para el proveedor o sin corrección.
• Exploit de día cero: el código o la técnica que aprovecha el fallo.
• Ataque de día cero: el exploit utilizado contra objetivos reales.

Cuando el proveedor distribuye una corrección, el fallo deja de ser de día cero y pasa a ser una vulnerabilidad conocida, a menudo llamada n-day. Eso inicia una segunda carrera: los atacantes estudian el parche y buscan sistemas que no lo han aplicado, de modo que una vulnerabilidad conocida sin parchear puede causar tanto daño como la de día cero original.

Vulnerabilidades de día cero en sus dependencias

La mayor parte del código de una aplicación moderna procede de paquetes de código abierto, y la mayoría de ellos son dependencias transitivas: las incorporan otros paquetes, no las elige su equipo. Una vulnerabilidad de día cero en cualquiera de ellos es una vulnerabilidad de día cero en su producto.

Log4Shell (CVE-2021-44228) es el ejemplo más conocido. Divulgada en diciembre de 2021, permitía a un atacante que controlara un mensaje registrado ejecutar código arbitrario a través de Apache Log4j 2, y obtuvo la puntuación CVSS máxima de 10,0. Para la mayoría de los equipos, lo difícil no fue la corrección, sino la pregunta previa: ¿cuáles de nuestras aplicaciones contienen log4j-core y en qué versiones? Log4j solía ser una dependencia de una dependencia, y muchos equipos tardaron días en averiguarlo.

Las vulnerabilidades de día cero en la cadena de suministro no siempre son errores. En marzo de 2024, Andres Freund encontró una puerta trasera en las versiones 5.6.0 y 5.6.1 de xz (CVE-2024-3094) tras notar que los inicios de sesión SSH consumían demasiada CPU. Las versiones maliciosas de paquetes, un tipo habitual de ataque a la cadena de suministro, funcionan igual: los primeros equipos en instalar una versión infectada, como los afectados por el gusano de npm Shai-Hulud, se enfrentan a un ataque que ningún aviso ni escáner conoce todavía.

Cómo responder cuando una vulnerabilidad de día cero afecta a una dependencia

1. Localícela. Enumere cada aplicación, imagen y versión que contenga el componente afectado, también como dependencia transitiva. Esto requiere una SBOM precisa de cada build. Un lockfile omite las dependencias descargadas fuera del gestor de paquetes, como el código que descargan los scripts de instalación o las capas del sistema operativo de una imagen de contenedor.
2. Determine el periodo de exposición. ¿Qué builds distribuyeron la versión vulnerable, y desde cuándo? Eso le indica qué investigar y qué notificar.
3. Conténgala. Aplique la corrección o una solución alternativa cuando exista, e impida que los nuevos builds distribuyan la versión vulnerable en cuanto tenga un CVE. Consulte la remediación de CVE.
4. Compruebe si ha habido explotación. Busque indicios de que el fallo se utilizó contra usted durante el periodo de exposición, y rote los secretos a los que pudo llegar.

¿Estamos afectados? explica en detalle los dos primeros pasos.

¿Es posible defenderse de una vulnerabilidad de día cero que nadie conoce?

No con parches ni con escáneres, porque ambos dependen de que el fallo sea conocido. Lo que funciona antes de la divulgación es limitar lo que un atacante puede hacer con un fallo que encuentre:

• Mínimo privilegio. Dé a cada sistema y a cada job de CI solo el acceso y los secretos que necesita.
• Control del egress. Bloquee las conexiones salientes a hosts que un sistema no necesita, para que un exploit que se ejecute no pueda enviar datos al atacante. En un build de CI, este es uno de los pocos controles que funcionan aunque usted sea la primera víctima de un nuevo paquete malicioso. Consulte políticas de egress para GitHub Actions.
• Defensa en profundidad. Superponga controles para que un solo fallo no lo abra todo.
• Registros que pueda consultar después. Cuando se divulga la vulnerabilidad de día cero, la rapidez de su respuesta depende de saber qué ha compilado y distribuido.

Cómo ayuda CRACI

CRACI ejecuta sus jobs de GitHub Actions en sus propios runners y registra cada build a medida que se produce:

• Las SBOM del build enumeran los paquetes que cada job descargó realmente, incluidas las dependencias ocultas que las herramientas basadas en lockfiles pasan por alto, para que pueda responder «¿dónde está?» a partir de lo que realmente se compiló. Consulte las SBOM del build.
• El historial de builds muestra todos los builds anteriores y su SBOM, y qué builds contenían una dependencia vulnerable, directa o transitiva, para que sepa durante qué periodo estuvo afectado.
• Los controles de política pueden bloquear un build que contenga un CVE concreto, para que un nuevo build no vuelva a distribuir la versión vulnerable.
• Una política de egress con denegación por defecto bloquea las conexiones a hosts que el build no necesita, incluso durante un ataque que nadie haya visto antes.

Vulnerabilidades de día cero: preguntas frecuentes

¿Qué es una vulnerabilidad de día cero?

Un fallo de seguridad que los atacantes conocen, o ya están explotando, antes de que el proveedor o el mantenedor haya publicado una corrección. El nombre cuenta los días que han tenido los defensores para parchearlo: cero.

¿Cuál es la diferencia entre una vulnerabilidad, un exploit y un ataque de día cero?

La vulnerabilidad es el fallo. El exploit es el código o la técnica que lo aprovecha. El ataque es el exploit utilizado contra objetivos reales.

¿Cuándo deja una vulnerabilidad de ser de día cero?

Cuando hay una corrección disponible. A partir de entonces es una vulnerabilidad conocida, a veces llamada n-day, y el riesgo se traslada a los sistemas que aún no han aplicado la corrección.

¿Puede un escáner detectar una vulnerabilidad de día cero?

No mediante una consulta. Los escáneres de vulnerabilidades cotejan los componentes con avisos publicados, y una vulnerabilidad de día cero aún no tiene ninguno. Lo que le aporta un escáner o una SBOM es el inventario en el que buscar en cuanto aparece el aviso.

¿Cómo averiguo si una vulnerabilidad de día cero afecta a mi software?

Busque el componente y las versiones afectados en un inventario preciso de lo que contiene cada build y cada versión, incluidas las dependencias transitivas. Después determine qué versiones lo distribuyeron y desde cuándo, para conocer el periodo de exposición.