Autor: Vinh T. Nguyen - Jefe de equipo
Introducción
Una vulnerabilidad en un sistema informático es un punto débil que un atacante puede aprovechar para utilizar dicho sistema de forma no autorizada [1]. Software , en particular, es un reto de ciberseguridad al que las organizaciones deben hacer frente de forma habitual, debido a la naturaleza cambiante y a la complejidad del software.
Los métodos más habituales que utilizan las organizaciones para evaluar el riesgo de vulnerabilidades en sus redes informáticas pueden agruparse en dos categorías principales: los basados en la red y los basados en el host [2]. Los métodos basados en la red exploran la red sin iniciar sesión en cada host, con el fin de detectar servicios, dispositivos y datos en tránsito vulnerables. Los métodos basados en el host inician sesión en cada host y recopilan una lista de software, componentes y configuraciones vulnerables. Cada categoría gestiona el riesgo de forma diferente, pero ninguna de ellas puede detectar vulnerabilidades a menos que el software vulnerable ya esté instalado en un host.
En la práctica, las evaluaciones suelen programarse de manera que no afecten al funcionamiento habitual. Esto deja un margen de tiempo entre el momento en que se implementa el software vulnerable y el inicio de la evaluación, que los atacantes pueden aprovechar para comprometer un host y, por ende, una red.
Esta situación requiere un método de análisis capaz de cerrar esa ventana de oportunidad y reducir el riesgo general de vulnerabilidad.file-based vulnerability assessment OPSWAT lo consigue asociando archivos binarios (como instaladores, ejecutables, bibliotecas dinámicas, etc.) con las vulnerabilidades detectadas. Este método permite detectar componentes de software vulnerables antes de su implementación, de modo que los analistas de seguridad y los administradores de sistemas puedan tomar rápidamente las medidas adecuadas y, así, cerrar esa ventana de oportunidad.
En las siguientes secciones, explicamos la tecnología y sus casos de uso con más detalle y ofrecemos ejemplos de ataques conocidos relacionados con dichos casos. A continuación, mostramos una demostración de explotación y ofrecemos nuestras conclusiones sobre la tecnología y su potencial.
¿Por qué se necesita otro método de detección?
Limitaciones de los métodos tradicionales
Los métodos tradicionales de detección de vulnerabilidades de software operan a un nivel abstracto. Cuando el escaneo basado en red analiza una red informática y el escaneo basado en host recopila datos de un equipo, suelen determinar qué comprobaciones realizar en función del entorno del sistema, con el fin de garantizar un alto rendimiento (tiempo de escaneo, ancho de banda de la red, uso de memoria, etc.) y filtrar los resultados irrelevantes. A veces, los métodos de evaluación dependen tanto de la información del entorno del sistema que no realizan las comprobaciones adecuadas, debido a las peculiaridades del mismo entorno en el que se basan.
Por ejemplo, si un servicio de red vulnerable se desactiva antes de una evaluación (ya sea de forma accidental o intencionada), el análisis no detectará ninguna vulnerabilidad en dicho servicio. Asimismo, eliminar la clave del Registro de Windows que contiene la ruta de instalación de una aplicación puede dejar la propia aplicación y sus vulnerabilidades intactas y sin detectar por los análisis basados en el host. En ambos casos, los métodos de análisis son menos eficaces, ya que se basan en la huella del producto instalado.
Un producto instalado es un conjunto de archivos (como ejecutables, bibliotecas, bases de datos, etc.) empaquetados juntos y combinados con una lógica de implementación. La lógica de implementación suele seguir una convención para escribir la huella del producto en una ubicación (por ejemplo, el Registro en el sistema operativo Windows o el puerto 3306 para MySQL). Esta huella no define el producto en sí y puede modificarse en cualquier momento durante el ciclo de vida del producto. Por lo tanto, basarse en la huella (como hacen tanto el escaneo basado en red como el basado en host) para detectar el producto y su vulnerabilidad conlleva el riesgo de una detección errónea.
Presentación del escaneo basado en archivos
File-based vulnerability assessment diferencia de los métodos de evaluación tradicionales. Como su nombre indica, se lleva a cabo archivo por archivo y hace caso omiso de todas las abstracciones de alto nivel del producto. Al analizar cada vulnerabilidad notificada y asignarla a los instaladores del producto y a los archivos de los componentes principales (patente EE. UU. 9749349 B1), file-based vulnerability assessment detectar si un archivo binario está asociado a una vulnerabilidad, revelando así las vulnerabilidades incluso cuando el producto no se está ejecutando o se ha modificado su huella.
Si bien la diferencia entre el análisis basado en archivos y el basado en la red es clara, la diferencia entre el análisis basado en archivos y el basado en el host no lo es tanto. Se podría argumentar que el análisis basado en el host no se basa únicamente en la huella del producto, sino que también comprueba la versión de los archivos de los componentes principales del producto. Por lo tanto, la lógica de análisis puede modificarse para que solo realice esa comprobación de la versión de los archivos, lo que convierte al análisis basado en archivos en un subconjunto del análisis basado en el host.
No es así, ya que:
- El escaneo basado en el host suele estar programado para utilizar tanto el entorno del sistema como la huella del producto a fin de filtrar las comprobaciones que se deben realizar
- Al centrarse en la búsqueda y el análisis de los archivos que provocan vulnerabilidades, el análisis basado en archivos permite detectar algunas vulnerabilidades que son difíciles de detectar con el método basado en el host y resulta adecuado para un mayor número de casos de uso
El análisis basado en archivos permite detectar instaladores, paquetes de firmware, archivos de bibliotecas, archivos de componentes de productos, etc., que entran o salen de las redes a través de puertas de enlace o que se transfieren desde y hacia los terminales (por correo electrónico, memorias USB, etc.). Esto permite a los administradores de sistemas y a los usuarios comprobar si un producto presenta vulnerabilidades antes de utilizarlo y garantizar la protección cuando el host no es compatible con los métodos de análisis basados en el host o en la red que utiliza actualmente la organización.
File-based vulnerability assessment también puede utilizarse para detectar posibles vulnerabilidades en los equipos existentes. Dado que los métodos de análisis tradicionales suelen realizar comprobaciones de vulnerabilidades basándose en informes generales y vagos procedentes de fuentes de divulgación pública, el análisis en sí mismo suele limitarse a un nivel general (la presencia del producto) y no entra en detalles ni sobre la vulnerabilidad ni sobre el producto en cuestión.
Sin embargo, dado que los productos suelen reutilizar componentes de otros (las bibliotecas dinámicas y los servicios compartidos son algunos ejemplos), actualizar un producto vulnerable o incluso desinstalarlo no siempre garantiza que los archivos que causan la vulnerabilidad hayan desaparecido. Es posible que sigan estando en algún lugar del sistema de archivos y proporcionen una plataforma para que los atacantes vuelvan a conectar esos componentes y causen estragos. Estos archivos suelen tener toda la integridad que se puede pedir. Tienen un propósito claro, son ampliamente conocidos, proceden de fuentes de confianza, cuentan con firmas válidas y siguen existiendo en algunos de los paquetes de software más recientes. File-based vulnerability assessment permite a los administradores de sistemas escanear las máquinas y encontrar archivos vulnerables ocultos antes de que los atacantes tengan la oportunidad de utilizarlos.
Retos tecnológicos
No obstante, operar a nivel de archivo tiene sus limitaciones. Puede marcar un archivo como vulnerable cuando, para que se active la vulnerabilidad, es necesario cargar varios archivos a la vez (falso positivo). Esto se debe, en parte, a la falta de contexto (al analizar un solo archivo) y a la vaguedad de los informes de divulgación. También puede marcar como limpio un archivo que es realmente vulnerable (falso negativo), debido a que la base de datos de archivos está incompleta y, de nuevo, a la vaguedad de los informes.
En OPSWAT, somos conscientes de ello y mejoramos constantemente nuestra file-based vulnerability assessment , con el fin de que detecte un mayor número de vulnerabilidades y, al mismo tiempo, reduzca las tasas de falsos positivos y falsos negativos. Hemos integrado esta tecnología en muchos de los productos de nuestra MetaDefender (como MetaDefender Core, MetaDefender Cloud, Drive, Kiosk, ICAP Server, etc.), para ayudar a las organizaciones a garantizar una defensa en profundidad de sus redes críticas [3].
Vulnerabilidades conocidas
Para los administradores de sistemas ya es bastante complicado hacer un seguimiento de los informes de divulgación de todo el software que utiliza la organización, por no hablar de conocer y supervisar todos los componentes que contiene dicho software. Esto hace que el software que utiliza componentes antiguos con vulnerabilidades pueda pasar desapercibido y colarse en las organizaciones. Esto puede convertir a los componentes vulnerables en un gran problema.
Un ejemplo es CVE-2019-12280 [4], la vulnerabilidad relacionada con la ruta de búsqueda de bibliotecas no controlada de Dell SupportAssist. Permite a un usuario con privilegios reducidos ejecutar código arbitrario con privilegios de sistema y obtener el control total de un equipo. La vulnerabilidad se originó en un componente proporcionado por PC-Doctor para diagnosticar equipos. Ambos proveedores han publicado parches para solucionar el problema.
Otro ejemplo es CVE-2012-6706 [5], una vulnerabilidad crítica de corrupción de memoria que podría dar lugar a la ejecución de código arbitrario y comprometer un equipo al abrir un archivo especialmente diseñado. En un principio se informó de que afectaba a los productos antivirus de Sophos, pero posteriormente se descubrió que procedía de un componente llamado UnRAR, encargado de la extracción de archivos [6].
A menudo, este tipo de vulnerabilidades no pueden notificarse en su totalidad, ya que hay demasiados productos que utilizan los componentes afectados. Por lo tanto, aunque los administradores de sistemas conozcan todos los productos en uso y los supervisen de cerca en las fuentes habituales de divulgación, sigue habiendo muchas vías por las que un atacante puede colarse.
Demostración
Analicemos más detenidamente un caso en el que un componente vulnerable provoca problemas en un host. Utilizaremos una versión antigua de Total Commander [7] que contiene un archivo UnRAR.DLL [8] afectado por la vulnerabilidad CVE-2012-6706 [5]. Tenga en cuenta que este CVE no menciona a Total Commander. Los usuarios avanzados con privilegios de administración suelen utilizar este software, por lo que explotar con éxito la vulnerabilidad podría ayudar a un atacante a utilizar un host para tomar el control de la red de una organización.
Especificaciones de la demostración:
- Sistema operativo: Windows 10 1909 (64 bits).
- Software: Total Commander v8.01 x86 con la biblioteca UnRAR v4.20.1.488.
- Los datos simulados han sido creados por el grupo de investigación en seguridad de Google en Exploit-DB [9].
La corrupción de memoria se produce cuando Total Commander utiliza UnRAR.DLL para extraer un archivo especialmente manipulado. A continuación, el atacante puede ejecutar código arbitrario en el equipo con los privilegios del usuario de Total Commander. Los atacantes más sofisticados pueden colocar en todo el equipo más archivos que, aunque parezcan legítimos, son vulnerables, con el fin de lanzar nuevos ataques.
Las versiones recientes de Total Commander no presentan esta vulnerabilidad, ya que utilizan una versión más reciente de UnRAR.DLL. Por lo tanto, como siempre, los usuarios deben mantener su software actualizado, incluso si no se ha publicado ningún informe al respecto, y especialmente si llevan mucho tiempo sin actualizarlo (esta versión de Total Commander se lanzó en 2012).
Conclusión
Software permiten a los atacantes acceder a los recursos de una organización o tomar el control de ellos. Dos métodos habituales para detectar vulnerabilidades son el análisis basado en la red y el análisis basado en el host. Por lo general, operan a un alto nivel de abstracción y pueden pasar por alto información importante debido a los cambios en el entorno de un ordenador.
file-based vulnerability assessment OPSWATopera a nivel de archivo para alertar a los administradores de sistemas sobre instaladores y componentes de software vulnerables que entran y salen de la organización, lo que reduce el riesgo de seguridad tanto antes de la implementación como durante el uso. La tecnología se ha integrado en MetaDefender como Core, Cloud API, Drive, Kiosk, etc., para cubrir una amplia gama de casos de uso.
La detección de vulnerabilidades archivo por archivo difiere de los métodos tradicionales y ofrece nuevas posibilidades, nuevos casos de uso y también nuevos retos. En OPSWAT, mejoramos constantemente nuestra tecnología para superar esos retos y ayudar a proteger las redes críticas de las organizaciones frente a las amenazas de ciberseguridad, que están en constante evolución.
Referencias
[1] «Vulnerabilidad (informática)», [en línea].
[2] «Escáner de vulnerabilidades», [en línea].
[3] MetaDefender plataforma avanzada de prevención de amenazas», [en línea].
[4] «CVE-2019-12280 - MetaDefender», [en línea].
[5] «CVE-2012-6706 - MetaDefender», [en línea].
[7] «Total Commander - página de inicio», [en línea].
[8] «Programa de compresión WinRAR - RARLAB», [en línea].
[9] «unrar 5.40 - 'VMSF_DELTA': filtro que permite la escritura arbitraria en memoria», [en línea].
