Una vulnerabilidad de día cero (Zero Day Vulnerability) es aquella vulnerabilidad existente en una aplicación, sistema operativo o dispositivo que no es conocida por el fabricante/desarrollador, pero que sí ha sido identificada por los atacantes, quienes intentan explotarla para sacarle provecho obteniendo una ventana de tiempo a su favor (el tiempo para que sea detectada por el propio fabricante o los investigadores, para que se desarrolle el respectivo parche y para que las organizaciones desplieguen las actualizaciones o parches en los sistemas afectados).
Un ataque de día cero es cuando el atacante que identificó la vulnerabilidad logra explotarla exitosamente, y es aquí donde radica realmente el gran riesgo que representan este tipo de vulnerabilidades, pues las organizaciones no tienen forma de prevenirlo, y probablemente tampoco de detectarlo. Y se vuelve aún más riesgoso cuando se da a conocer la vulnerabilidad y se hace público el exploit, ya que en ese momento se abre la posibilidad de que cualquier ciberactor lo aproveche y, dado que las organizaciones no tienen forma de protegerse, ya que no ha habido tiempo de que el fabricante libere el parche que lo corrija, la probabilidad de ataques exitosos es mayor.
Las vulnerabilidades de día cero son de gran impacto y tan relevantes en materia de ciberseguridad que existe todo un mercado alrededor, tanto legítimo como negro. Para los atacantes representan una forma segura de lograr sus objetivos y por lo tanto una oportunidad muy valiosa, por eso los grupos cibercriminales avanzados dedican grandes recursos a detectarlas y explotarlas; para los desarrolladores de software (vendors) son muy importantes pues ellos quieren proteger a sus usuarios y este tipo de vulnerabilidades pueden representar un riesgo crítico para sus clientes e incluso para ellos mismos, por lo tanto, están dispuestos a pagar a quienes las encuentren (de ahí la existencia de los programas de “Bug Bunty”); y para las organizaciones/clientes representan un riesgo que se puede volver crítico y de gran impacto.
Obviamente el fabricante o desarrollador del software es el responsable de resolver una vulnerabilidad de día cero una vez que se da a conocer, y por supuesto son los responsables también de que el código no tenga vulnerabilidades. A pesar de los grandes avances que ha habido en el desarrollo seguro, sigue habiendo muchas vulnerabilidades; como referencia, la Zero Day Initiative detectó 1,913 vulnerabilidades en 2023, de las cuales aproximadamente 10% (198) fue de día cero, versus 1,706 en 2022 cuando cerca de 6% (99) fue de día cero. Estos números nos indican un crecimiento de ciento por ciento.
Algunos ejemplos recientes de ataques que aprovechan vulnerabilidades de día cero son el caso de MOVEit que impactó a más de 2,100 organizaciones y que expuso la información de más de 62 millones de personas; otro caso fue el de Atlassian Confluence Data Center and Server que si bien se estaba explotando ocasionó pocos casos.
Pero, ¿realmente podemos hacer algo diferente al respecto?
Como menciono arriba, la responsabilidad de arreglar las vulnerabilidades de día cero es de los fabricantes/desarrolladores, de igual forma, es su responsabilidad el desarrollar el código con las mejores prácticas para reducir su existencia. Por otro lado, detectarlas es responsabilidad de los fabricantes/desarrolladores complementados por las diferentes organizaciones de investigadores e investigadores independientes.
Dicho lo anterior, si en su organización desarrollan software para sus clientes, son responsables de atender dichas actividades. Ahora, como organizaciones usuarias del software comercial o libre, lo que podemos hacer es asegurarnos de mantener las prácticas elementales ya conocidas, pero que desafortunadamente en muchas ocasiones se omiten:
- Fortalecer la gestión de vulnerabilidades y particularmente agilizar el proceso de aplicación de parches basándose en la evaluación del riesgo tan pronto se dé a conocer la vulnerabilidad y se disponga del parche.
- Buscar fuentes de información confiables para mantenerse al día sobre las vulnerabilidades de día cero que se dan a conocer, por ejemplo: el catálogo “Known Exploited Vulnerabilities” (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) de CISA (Cybersecurity & Infrastructure Security Agency), las notificaciones de Zero Day Initiative (https://www.zerodayinitiative.com/advisories/published/) o diversos fees comerciales de inteligencia. Si bien al principio puede ser que no haya parches, es común que haya guías y recomendaciones a seguir para reducir el riesgo.
- Considerar tecnologías para priorizar y automatizar la aplicación de parches y para el manejo de parches virtuales.
- Considerar el despliegue de software “anti-exploit” en equipos finales.
- Monitorear los diversos sistemas en búsqueda de anomalías y comportamientos inusuales que puedan ser indicios de la explotación de una vulnerabilidad no conocida.
- Tener un buen inventario de los activos tecnológicos de la organización para que cuando se dé a conocer una vulnerabilidad de día cero, se puedan cuantificar y ubicar de inmediato todos los componentes/dispositivos en riesgo.
Las vulnerabilidades de día cero no son un tema nuevo, sin embargo, en mi opinión, han retomado relevancia en el último año por su incremento y por el impacto que han tenido, y si bien las acciones a tomar son conocidas, es importante ponerlas sobre la mesa y asegurarse de que están correctamente implementadas.
Referencias:
https://www.zerodayinitiative.com/blog/2024/1/4/looking-back-at-the-zdi-activities-from-2023
https://www.enisa.europa.eu/topics/incident-response/glossary/zero-day
https://www.mandiant.com/resources/blog/zero-days-exploited-2022
Deja tu comentario