Qué es un ataque de día cero

Un ataque de día cero (Zero-Day Attack) aprovecha una vulnerabilidad de software mientras todavía no existe un parche que la corrija. El término día cero alude a que el fabricante no ha tenido tiempo para preparar la corrección, lo que deja fuera de juego la defensa básica: aplicar una actualización.

Conviene separar tres términos relacionados. El defecto en sí, que el fabricante no conoce o que aún no está corregido, es la vulnerabilidad de día cero. El código escrito para aprovecharlo es el exploit de día cero. El acto de usar ese código contra un objetivo es el ataque de día cero. Las noticias los tratan casi como sinónimos, pero mantenerlos distintos hace que cualquier discusión sobre medidas se sostenga mucho mejor.

Las vulnerabilidades de día cero se comercian por varias vías: programas legítimos de recompensas por fallos (bug bounty), intermediarios que las compran y mercados no públicos. Las que funcionan de forma remota sin ninguna acción del usuario alcanzan los precios más altos, y una sola puede llegar al orden de varios millones de dólares. Como pocos actores pueden asumir esas cifras, los días cero aparecen de forma concentrada en operaciones con participación estatal y en amenazas persistentes avanzadas (APT).

Desde la óptica de la gestión de vulnerabilidades, un día cero pertenece a una categoría de amenaza distinta de una vulnerabilidad conocida y exige otro enfoque.

Ciclo de vida de un ataque de día cero

Descubrimiento de la vulnerabilidad: Un atacante, o un investigador de seguridad, encuentra un defecto que el fabricante todavía no conoce.
Desarrollo del exploit: Se escribe el código que activa el defecto de forma fiable. Que funcione depende de la versión y la configuración del objetivo, así que este paso exige tiempo y oficio.
Ejecución del ataque: El exploit se usa contra un objetivo. En ese momento no existe parche y la víctima a menudo solo percibe un comportamiento sin explicación.
Conocimiento y divulgación: El fabricante se entera del defecto, por la detección del ataque o por el aviso de un investigador, y avanza con la preparación y el anuncio de la corrección.
Publicación del parche: El fabricante crea y distribuye la actualización.
Aplicación del parche: Los usuarios la instalan en sus propios entornos. Hasta que ese trabajo termina, los ataques siguen.

Lo que se pasa por alto con facilidad es que el riesgo no baja de forma sostenida a lo largo de estas seis etapas. Cuando el parche es público, hay quien analiza la corrección y construye código de ataque a partir de ella, de modo que el volumen total de ataques sube justo después de la divulgación. En la fase de día cero solo se apunta a un conjunto limitado de organizaciones, mientras que los entornos que quedan rezagados tras la divulgación se exponen a ataques automatizados que no eligen objetivo. En lugar de resumirlo como un ataque imposible de detener por ser un día cero, resulta más útil registrar cuántos días pasaron entre la divulgación y la aplicación del parche.

Casos reales

Log4Shell (2021): Una vulnerabilidad en la biblioteca de registro de Java Log4j (CVE-2021-44228). Se comunicó de forma privada al proyecto el 24 de noviembre de 2021, la versión con la corrección apareció el 6 de diciembre y la divulgación pública llegó el 9 de diciembre. Cloudflare, en cambio, informó de rastros de explotación que se remontaban al 1 de diciembre, ocho días antes de la divulgación. El director de la agencia estadounidense CISA describió el alcance como cientos de millones de dispositivos, y la profundidad de las dependencias de la cadena de suministro fue lo que extendió el daño.
Microsoft Exchange Server (2021): Un ataque que encadenó cuatro vulnerabilidades de día cero (CVE-2021-26855 y otras) para comprometer servidores Exchange gestionados por las propias organizaciones. Microsoft lo atribuyó a un grupo respaldado por un Estado y con base en China (Hafnium). La explotación se observó desde principios de enero de 2021 y el parche se publicó el 2 de marzo. Se informó de unas 30.000 organizaciones afectadas en Estados Unidos, y los entornos lentos en aplicar la corrección siguieron siendo objetivo tras la divulgación.
Stuxnet (2010): Malware que combinó cuatro vulnerabilidades de día cero de Windows para dañar físicamente centrifugadoras de una instalación nuclear en Natanz, Irán. Se estima que alrededor de mil centrifugadoras quedaron fuera de servicio. Los países implicados nunca han reconocido oficialmente su papel, pero el caso se trata como la demostración de que un ataque informático puede llegar hasta la destrucción de equipos.

Los tres empezaron con un conjunto reducido de objetivos y acabaron con un impacto mucho mayor. El desajuste entre lo escasa que es la vía de entrada y lo amplio que resulta el daño final es lo que vuelve incómoda esta amenaza.

Medidas de defensa contra ataques de día cero

Frente a un ataque para el que no existe parche, esperar que un solo producto lo detenga no es realista. La forma práctica de prepararse es la defensa por capas (Defense in Depth): una disposición en la que una intrusión no se convierte en un daño extendido.

WAF y parcheo virtual: Un firewall de aplicaciones web puede bloquear no solo patrones de ataque conocidos, sino también peticiones cuya forma se sale de lo que la aplicación espera. Bloquear únicamente el tráfico en cuestión, lo que se conoce como parcheo virtual, gana tiempo hasta que llega la corrección oficial. No sustituye a esa corrección, porque un cambio en la forma de escribir el ataque puede esquivarlo.
Segmentación de la red: Limita hasta dónde puede propagarse un compromiso. Aislar los sistemas críticos dificulta el movimiento lateral.
Principio de mínimo privilegio: Conceder a usuarios y procesos solo los permisos que necesitan. Aunque se explote una vulnerabilidad, esto estrecha aquello a lo que el atacante puede llegar.
EDR (Endpoint Detection and Response): Vigilar el comportamiento del equipo permite recoger indicios de compromiso, como el arranque de procesos desconocidos o tráfico de red sospechoso. Los ataques que suelen escapar a las defensas basadas en comparar con patrones conocidos también dejan rastro, así que el EDR mueve el eje de la detección desde qué defecto se explotó hacia qué se está haciendo.
Pruebas de penetración: Poner a prueba la propia organización con la mirada de un atacante y encontrar antes que nadie los caminos que llevan a la explotación.
Gestionar la velocidad de aplicación tras la divulgación: Los días cero en sí no se pueden bloquear, pero el tiempo entre la divulgación y la aplicación del parche sí está en nuestras manos. Saber qué software corre en qué dispositivos, y cuánto ha avanzado la aplicación, es la condición para librarse de los ataques masivos que siguen a la divulgación.
Un plan de respuesta a incidentes preparado: Partir de la premisa de que la prevención completa es imposible y fijar por adelantado los procedimientos y las vías de comunicación para la detección, la contención y la recuperación.

Conceptos erróneos comunes

Los ataques de día cero no afectan a las personas comunes: Si existe una vulnerabilidad de día cero en un navegador o sistema operativo, los usuarios comunes también pueden verse afectados. Las vulnerabilidades en bibliotecas ampliamente utilizadas como Log4Shell pueden afectar indirectamente a través de los servicios que se utilizan.
El software antivirus puede prevenir los ataques de día cero: El software antivirus convencional detecta basándose en firmas (patrones de malware conocido), por lo que no puede responder a ataques desconocidos. Se necesitan EDR de nueva generación con capacidades de detección de comportamiento y sandbox.

Ataque de día cero