Los ataques de día cero van en aumento. Es hora de planificar una estrategia defensiva.

Una versión de este artículo apareció en SC Magazine. Ha sido modificado y distribuido aquí.


Si alguna vez han entrado a robar en tu casa, entenderás esa sensación inicial de hundimiento al notar que algo va mal, seguida de la constatación de que, efectivamente, te han robado y vulnerado. Por lo general, esto deja una incomodidad duradera, por no mencionar el cambio hacia medidas de seguridad que harían palidecer a Fort Knox.

Ahora imagina que tu casa es vulnerada porque los ladrones se han fabricado una llave. Se mueven sigilosamente, entrando y saliendo a su antojo, pero con cuidado de no ser detectados. Entonces, un día, notas demasiado tarde que las joyas que escondiste en el congelador han desaparecido, tu caja fuerte ha sido vaciada y tus pertenencias personales han sido revueltas. Esta es la realidad equivalente a la que se enfrenta una organización si es víctima de un ciberataque de día cero. En 2020, un estudio del Ponemon Institute reveló que el 80% de las brechas de datos exitosas fueron resultado de exploits de día cero y, lamentablemente, la mayoría de las empresas siguen sin estar equipadas para mejorar significativamente esta estadística.

Por definición, los ataques de día cero no dan tiempo a los desarrolladores para encontrar y corregir las vulnerabilidades existentes que podrían ser explotadas, ya que el atacante se les ha adelantado. El daño ya está hecho y, a partir de ahí, comienza una carrera frenética para reparar tanto el software como la reputación de la empresa. Los atacantes siempre llevan la ventaja, por lo que es crucial reducir esa brecha tanto como sea posible.

El regalo navideño que nadie quería, Log4Shell, está haciendo estallar internet actualmente, con más de mil millones de dispositivos supuestamente afectados por esta catastrófica vulnerabilidad de Java. Se perfila como el peor ataque de día cero registrado, y esto no ha hecho más que empezar. A pesar de algunos informes que indican que los exploits comenzaron unos días antes de la divulgación pública, una presentación realizada en la conferencia Black Hat en 2016 sugiere que este ha sido un problema conocido desde hace tiempo. Vaya. Peor aún, es dolorosamente fácil de explotar, y cada aficionado a la informática y ciberdelincuente del planeta está intentando sacar provecho de esta vulnerabilidad.

Entonces, ¿cuál es el mejor camino a seguir para defenderse de una amenaza tan escurridiza y siniestra, por no hablar de las vulnerabilidades que se han pasado por alto en el proceso de desarrollo de software? Vamos a verlo.

Los ataques de día cero contra grandes objetivos son raros (y costosos)

Existe un mercado enorme para los exploits en la web oscura, y los días cero suelen venderse a un precio elevado; un ejemplo en este artículo se cotizaba en 2,5 millones de dólares en el momento de escribir este texto. Al tratarse supuestamente de un exploit para Apple iOS, no sorprende que el precio solicitado por el investigador de seguridad sea astronómico; después de todo, esto podría ser la puerta de entrada para comprometer millones de dispositivos, recopilar miles de millones de registros de datos confidenciales y hacerlo durante el mayor tiempo posible antes de que sea descubierto y parcheado.

Pero, ¿quién tiene tanto dinero? Por lo general, los sindicatos de ciberdelincuencia organizada consiguen el dinero si lo consideran rentable, especialmente para los siempre populares ataques de ransomware. Sin embargo, los gobiernos mundiales y los departamentos de defensa se encuentran entre los clientes de exploits que pueden utilizar para inteligencia de amenazas y, en escenarios más positivos, las propias empresas pueden ser compradoras de sus posibles exploits de día cero para poder mitigar el desastre.

El 2021 batió récords en descubrimientos de exploits de día cero en vivo, y son las grandes organizaciones, los departamentos gubernamentales y las infraestructuras los que corren mayor riesgo de ser analizados en busca de debilidades. No hay forma de estar completamente a salvo de la posibilidad de un ataque de día cero, pero puedes "jugar al juego" ofreciendo un programa de recompensas por errores (bug bounty) generoso y bien estructurado. En lugar de esperar a que alguien ofrezca las llaves de tu castillo de software en un mercado de la web oscura, consigue expertos en seguridad de tu lado y ofréceles recompensas decentes por la divulgación ética y las posibles soluciones.

Y si resulta ser una amenaza de día cero aterradora, es seguro asumir que tendrás que ofrecer algo más que una tarjeta de regalo de Amazon (y valdrá la pena hacerlo).

Tus herramientas podrían ser un lastre para tu personal de seguridad

Las herramientas de seguridad engorrosas han sido un problema durante mucho tiempo, con el CISO promedio gestionando entre 55 y 75 herramientas en su arsenal de seguridad. Además de ser la navaja suiza (metafórica) más confusa del mundo, el 53% de las empresas ni siquiera confía en que estén funcionando de manera efectiva, según un estudio del Ponemon Institute. Otro estudio reveló que solo el 17% de los CISOs consideraba que su conjunto de herramientas de seguridad era "completamente efectivo".

En un campo conocido por el agotamiento, la falta de personal cualificado en seguridad para satisfacer la demanda y la necesidad de agilidad, obligar a los profesionales de la seguridad a trabajar con una sobrecarga de información en forma de datos, informes y monitorización de conjuntos de herramientas masivos es una carga. Este es exactamente el tipo de escenario que puede hacer que pasen por alto una alerta crítica, lo cual bien pudo haber sido el caso al evaluar adecuadamente las debilidades de Log4j.

La seguridad preventiva debe incluir el modelado de amenazas impulsado por los desarrolladores

Las vulnerabilidades a nivel de código suelen ser introducidas por los desarrolladores, quienes necesitan una guía precisa y vías de aprendizaje regulares para desarrollar habilidades de codificación segura. Sin embargo, los desarrolladores de nivel avanzado han tenido la oportunidad de aprender y practicar el modelado de amenazas como parte de su proceso de creación de software.
‍
No debería sorprender que las personas que mejor conocen su software sean los desarrolladores que se han sentado a crearlo. Poseen un conocimiento poderoso sobre cómo interactúan los usuarios con él, dónde se utilizan las funciones y, cuando tienen suficiente conciencia de seguridad, sobre los posibles escenarios donde podría fallar o ser explotado.

Si volvemos al exploit Log4Shell, lamentablemente estamos viendo un escenario donde una vulnerabilidad catastrófica ha escapado a la detección de expertos y conjuntos de herramientas complejos; sin embargo, es posible que no hubiera ocurrido en absoluto si la biblioteca estuviera configurada para desinfectar la entrada del usuario. La decisión de no hacerlo parece haber sido una característica oscura para mayor comodidad, pero hizo que fuera dolorosamente fácil de explotar (piensa en el nivel de inyección SQL, ciertamente nada del otro mundo). Si un grupo de desarrolladores entusiastas y expertos en seguridad hubiera realizado un modelado de amenazas, es muy probable que este escenario se hubiera teorizado y considerado.

Un gran programa de seguridad tiene un componente emocional, con la intervención humana y los matices en el centro de la resolución de problemas creados por humanos. El modelado de amenazas requiere empatía y experiencia para ser efectivo, al igual que la codificación y configuración seguras a nivel arquitectónico del software y las aplicaciones. Esto no es algo en lo que los desarrolladores deban ser lanzados de la noche a la mañana, pero es ideal contar con un camino claro para mejorar sus habilidades hasta un nivel en el que puedan aliviar la presión del equipo de seguridad en esta importante tarea (y es una excelente manera de construir una buena relación entre ambos equipos).

Los días cero conducen a los días n

La siguiente etapa al gestionar una vulnerabilidad de día cero es lanzar parches con la mayor rapidez posible, esperando fervientemente que cada usuario del software afectado los aplique de inmediato, y ciertamente antes de que un atacante tome la delantera. Con Log4Shell, podría eclipsar a Heartbleed por su persistencia y potencia, dado que está integrado en millones de dispositivos y genera dependencias complejas en toda la arquitectura de software.

Siendo realistas, no hay forma de detener por completo este tipo de ataques insidiosos. Sin embargo, si nos comprometemos a utilizar todos los recursos disponibles para crear software seguro y de calidad, y abordamos el desarrollo con la misma mentalidad que se aplicaría a una infraestructura crítica, todos tendremos una oportunidad real de defendernos.