Por
Adam Shostack (*)
Leading expert in threat modeling
El ransomware funciona revisando los archivos, uno por uno, y reemplazando su contenido con una versión cifrada (a veces también envía copias a otros lugares, pero eso resulta ser lento y, a veces, activa las alarmas). Windows usa una API llamada "CreateFile()" para acceder a los archivos. De forma un tanto confusa, CreateFile no solo crea archivos, sino que también es la forma principal de abrirlos.
Microsoft podría limitar la velocidad de la API CreateFile(). Es decir, podría limitar la frecuencia con la que un programa determinado puede usar la API. Debido a que no se puede cifrar un archivo hasta que logre abrirlo, esto tendría un impacto dramático en el ransomware. Lo ralentizaría y ayudaría a las herramientas defensivas a detectarlo a tiempo para que los humanos reaccionen.
En la superficie, esta solución es muy simple y elegante. En la práctica, habrá complejidades prácticas y preocupaciones y no sabemos cuáles serán todos los posibles efectos.
¿Qué tasa es razonable?
La primera pregunta es, ¿qué tasa es razonable? Si elijo un valor muy bajo, romperá las aplicaciones; si elijo un valor muy alto, el valor de protección disminuir.
Para muchos casos, una apertura por segundo parece estar bien, pero cuando llegamos a cosas como los compiladores, que van a abrir muchos archivos, vemos que es posible que necesitemos un límite general y permitir ráfagas. Cuando llegamos al software de backup, se vuelve aún más complicado. El software de respaldo necesita abrir todos los archivos, o al menos todos los archivos modificados, lo cual, si lo pensamos bien, es muy similar a lo que hace el ransomware. No podemos permitir una excepción para aperturas de solo lectura. El ransomware abrirá un archivo, cifrará el contenido, lo escribirá en un archivo nuevo o lo agregará a una base de datos y eliminará el original.
Entonces, Windows probablemente necesitará múltiples límites de velocidad. Tendrá que haber una forma de eximir a los programas (como compiladores y herramientas de copia de seguridad), y tal vez eso deba emitirse globalmente, lo que significa un proceso para que los creadores de software obtengan un certificado especial.
Es necesario que haya registros y alertas creadas, probadas, internacionalizadas, etc. Será necesario crear y documentar nuevos GPO (una herramienta utilizada para administrar Windows). Tiene que haber una forma local de permitir más llamadas a CreateFile para software desarrollado localmente u oscuro, o cuyos creadores ya no existen. Necesitamos asegurarnos de que el ransomware no pueda abusar de esos mecanismos. En las Mac recientes, se necesita un proceso complejo de reinicios para realizar ciertos cambios en el sistema; ¿quizás se justifica algo similar?
Esto último es complicado: el administrador tiene poder, por diseño, y es difícil limitar ese poder. Incluso el registro de aperturas de archivos facilitaría ver qué software está abriendo muchos archivos nuevos y dificultaría que el ransomware sea sigiloso. Y sí, ya hay demasiadas alarmas.
Siempre que no nos concentremos demasiado en los detalles, los atacantes cambian lentamente. Todavía hacen phishing, a través de más y más canales. Durante 20 años, los robos han pasado de abusar del software que escucha en puertos abiertos a otros problemas. Ese fue el resultado de un cambio radical al activar el Firewall de Windows de forma predeterminada, en respuesta al "verano de gusanos" de 2003.
La ley de Hyrum Wright establece aproximadamente que alguien dependerá de cada comportamiento observable del sistema o API. Y el cambio se vuelve complejo. La simple declaración "Microsoft debería limitar la velocidad de la API CreateFile()" es una lata de gusanos.
Dado el costo excepcional del ransomware hoy en día, creo que vale la pena abrir esa lata de gusanos.
Adam Shostack es un destacado experto en modelado de amenazas. Es miembro del BlackHat Review Board y ayudó a crear el CVE. Ayuda a organizaciones a mejorar su seguridad. Mientras estuvo en Microsoft, incorporó la solución Autorun a Windows Update, fue el diseñador principal de SDL Threat Modeling Tool v3 y creó el juego "Elevation of Privilege". Adam es autor de Threat Modeling: Designing for Security y coautor de The New School of Information Security.
Fuente: Dark Reading