Visión del Producto
“vRx, es una capa de proxy entre las aplicaciones nativas y los procesos que solicitan su uso.”
“vRx, un nuevo producto en el campo de la seguridad de aplicaciones, tiene como objetivo proteger el software sin tener su código fuente, instalar un parche o involucrar al proveedor de la aplicación.”
Resumen
El proceso de integración del Sistema de vRx tiene tres pasos principales:
Predicción: Se lleva a cabo un proceso de descubrimiento sobre los activos de la organización (Servers y Workstation). Usando la estructura de software del "Motor de Seguridad Basado en Capacidades (Capability Driven Security Engine’)" para construir automáticamente el ecosistema de la organización.
Al mismo tiempo, los binarios de las aplicaciones se les hace ingeniería reversa para asociar partes de código con capacidades como Network, Encryption, Media, etc.,y entender las posibilidades de que áreas del binario pueden ser explotada en el futuro.
Priorización: Los datos recopilados de la fase de predicción combinados con los datos de vulnerabilidades conocidas (CVE) y el contexto de los activos (uso de la aplicación a lo largo del tiempo, configuraciones de red específicas de los activos, privilegios de usuario, etc.) son utilizados para comprender cuáles son los riesgos más críticos que requieren atención inmediata.
Protección: Al comprender los riesgos más críticos de las operaciones de seguridad empresarial y cada estructura de software, el "motor de políticas dinámicas" propaga medidas de seguridad para proteger de:
El abuso de los componentes de la aplicación
La manipulación de ejecutables legítimos
El proceso actual de detección de brechas de seguridad en el cliente (y no en el lado del proveedor) no ha cambiado drásticamente aparte de las soluciones de priorización. Su enfoque principal estaba en el lado de la seguridad operativa, en lugar de proporcionar formas de mitigación inmediatas. Algunas de las soluciones de priorización carecen de los contextos de los activos como criterio de prioridad debido a que su enfoque se basa en el escaneo de red.
Aquí es donde surgen los productos, llamados Application Monitoring & Protection, tal como lo define Gartner: como la próxima generación de seguridad de aplicaciones. Estas soluciones tienen la intención de brindar nuevas medidas de seguridad para proteger el software sin cambios en el código fuente o instalaciones de parches.
¿Qué es un Software?
Antes de comenzar a estudiar como un atacante puede vulnerar un software es necesario comprender la estructura básica del mismo.
Estructura
Una vez que instalas una aplicación, obtienes dos cosas que principalmente están relacionadas con su ejecución: los ejecutables y las librerías.
Los Sistemas Operativos se construyen de la misma manera. Sus librerías generalmente contienen funciones que están siendo utilizadas por múltiples aplicaciones y consumidores.
Librerías
La funcionalidad dentro de cada libreria se externaliza para que el Sistema Operativo redirija las llamadas de sistema (system calls) relevantes.
Para que cualquier librería que se reutilice, es necesario que los desarrolladores las pongan como librerías compartidas y así, se eviten líneas de código idénticas en el mismo proyecto. Estos tipos de archivos suelen ser de tipo DLL u OCX en Windows y SO o A en hosts basados en * NIX.
Ejecutables
El flujo lógico de una aplicación, requiere que tengan un orquestador que haga uso de las funcionalidades ubicadas dentro de las librerías del software para que funcione realmente. Este es el rol de los ejecutables.
El ejecutable puede utilizar dos tipos de librerías: las del Sistema Operativo y las de la Aplicación.
Si se desea crear una funcionalidad que sea específica para los componentes internos de un programa, por ejemplo, el registro o la autenticación para un servicio determinado, probablemente utilizará una interfaz ubicada dentro de una librería del software.
Por otro lado, una capacidad más general, como el uso de una cámara web o un teclado, se encuentra en las librerías del Sistema Operativo.
Interacción
Podemos resumir que un software dado interactúa tanto con el Sistema Operativo subyacente y sus librerías para funcionar de manera adecuada.
Figure #1, Software Interacción
Principales Formas de Ataque
En Vicarius llegamos a la conclusión de que hay tres formas principales de explotar maliciosamente los ejecutables y las librerías de un software.
Abuso del Ejecutable
Abusar de brechas en el código del ejecutable, como problemas en la criptográfica, excesivos registros de datos, credenciales mal protegidas, solo por mencionar algunos ejemplos, le permiten a los atacantes iniciar exploits desde la aplicación. Dichos ataques generalmente tienen la intención de extraer información confidencial (por ejemplo, SQL Injection) o activar funciones ocultas dentro del software (por ejemplo, ataques de desbordamiento de búfer basados en el stack) sin que el vendor o el cliente se den cuenta.
Figure #2, Abuso del Ejecutable
Suplantar el Ejecutable (hacerse pasar por el ejecutable)
Los SOs contienen funciones integradas para "saltar" entre procesos en el entorno de ejecución. Si bien existe un uso adecuado de estas capacidades, los atacantes a menudo las usan para disfrazarse de procesos legítimos. Funcionalidades como "OpenProcess" ubicado en Kernel32.dll es una de las formas de lograrlo. Los frameworks de ataques populares, como mimikatz, metasploit, PowerSploit, etc., utilizan este tipo de capacidades.
Figure #3, Suplantar el Ejecutable
Abusar Directamente de la Librería
El workflow del SO incluye redirecciones de llamadas de sistema (system call redirections) para módulos integrados y de terceros (ej: la función "LoadLibray" en Windows).
Para que ese proceso funcione, cualquier módulo de código tiene que declarar qué funcionalidad contiene (ej: Exportar Tabla) para que el SO sea consciente de las llamadas al sistema que debería recibir. Al igual que cualquier aplicación legítima, un adversario puede iniciar llamadas de sistema (system call) a los módulos que desea explotar. Existen un sinnúmero de ataques que se incluyen en la categoría de Abuso de API, donde aprovechan el acceso sin restricciones a los archivos del módulo.
Figure #4, Abusar Directamente de la Librería
Predicción de Vulnerabilidades
Para dar el primer paso hacia la aplicación de un mecanismo de restricción sobre el acceso a la funcionalidad de los módulos de código compartido, debemos comprender que el mayor desafío es tener la solución más liviana y menos intrusiva posible.
El seguimiento de cualquier llamada de sistema por cualquier ejecutable en el nivel de SO creará una degradación significativa en la experiencia del usuario y puede causar potencialmente una gran cantidad falsos positivos (o fallas del sistema en caso de prevención de acceso sobre la detección).
Nuestra solución busca comprender qué funcionalidades dentro de los módulos de los archivos binarios pueden interesarles a los atacantes en sus explotaciones actuales y/o futuras.
Bajo este premisa, necesitamos hacer una distinción entre dos escenarios:
La aplicación crea una llamada de sistema hacia una de las funciones de las librerías.
La aplicación realiza una llamada de sistema hacia una funcionalidad de las librerías del SO.
Entonces, una forma eficiente en la creación de restricciones a las llamadas de sistema, necesitamos predecir de manera eficiente qué funcionalidades (o áreas del código binario) son actualmente y/o serán explotadas por hackers.
Funcionalidades de Riesgo dentro de la Aplicación
Si utilizamos ingeniería reversa en los archivos binarios de las librerías, podemos asociar que funcionalidades los atacantes utilizan frecuentemente para explotar una vulnerabilidad especifica.
Con vRx, podemos ver cada función dentro de un módulo, como una cadena de sub llamadas.
Nuestra tecnología realiza este proceso de análisis en la Nube (en nuestros servidores), sin generar impacto en la experiencia del usuario.
Figure #5, Análisis estático de la librería de software
Realizamos este análisis creando árboles que se combinan con patrones prefabricados para indicar si una función determinada está asociada con alguna característica especifica, por ejemplo:
Una función llamada PK11_CheckUserPassword ubicada en una librería llamada nss3.dll que es parte de Mozilla Firefox, contiene frases de "Usuario" y "Contraseña" y se puede asociar con las capacidades de "Interacción de usuario" e "Interacción de contraseña". Esas capacidades podrían ser explotadas por hackers para robar las credenciales de usuario del navegador.
Figure #6, Dominios de Ataque y Familas de 0 day visto desde la plataforma de vRx
Uso de Aplicaciones de Librerías Sensibles del SO
Como se describió en la sección anterior, podemos resaltar áreas sensibles en el código binario de las librerías usando análisis de código estático del lado del servidor. La plataforma realiza estos procesos de análisis en librerías del SO y en librerías de terceros.
Si bien una porción de código sensible en un software de terceros puede implicar un exploit en el futuro, la situación con las librerías del SO es mucho más complicada.
Los features del SO que contienen funciones sensibles son features esenciales de las aplicaciones legítimas que se ejecutan en la capa superior de este.
Para comprender el flujo regular de un software determinado, debemos realizar dos pasos:
Asociar el código binario de las librerías relacionadas con el SO con capacidades de riesgo (por ejemplo, Funcionalidades de Riesgo Dentro de la Aplicación).
Por otra parte, realizar un seguimiento aleatorio del ejecutable de una aplicación determinada para ver a qué capacidades de riesgo del SO accede.
Figure #7, Análisis dinámico de software ejecutable
Este proceso de Evaluación Dinámica tiene la intención de dibujar un mapa de las capacidades del sistema operativo que un software ejecutable "toca" y cuál no.
Dos cosas importantes para destacar aquí con respecto a minimizar la sobrecarga de la experiencia del usuario son:
Las funciones "observadas" dentro de las librerías del SO son solo las que se destacaron como riesgosas en el proceso de análisis estático.
Un proceso esta siendo rastreado, solo en máquinas en las que nuestra tecnología encontró que está demasiado activo, con el objetivo de tener una idea general de lo que suele hacer el software.
Manejando las Vulnerabilidades
El propósito de esos dos pasos es darnos una idea de:
¿Qué tan riesgoso es un software dado en función de sus librerías empaquetadas?
¿Cómo puede hacer daño este software en caso de que un adversario lo abuse a través de las funciones legítimas que usa en el SO?
¿Cómo puede ser explotado en el futuro? Y en ese caso, tenemos dos opciones.
Abuso de sus librerías
Forzar al software a hacer algo para lo que no fue diseñado y explotar así alguna función del SO.
Al final de este proceso, vRx indica el nivel de riesgo del software en función de esos parámetros para comprender cual es el nivel de amenaza para la empresa. Este método presenta una forma nueva e innovadora de comprender "¿de dónde vendrá la próxima vulnerabilidad?".
Figure #8
Priorización Basada en Activos
Al trabajar en estrecha colaboración con nuestros clientes, pudimos ver que las organizaciones tienen una enorme cantidad de aplicaciones, servicios de software y dispositivos.
Como consecuencia directa, surgen vulnerabilidades conocidas, vulnerabilidades previstas y configuraciones de red que hacen perder el foco, de cuales son los riesgos más críticos que deben manejar.
Como vRx se ejecuta en cualquiera de los activos de la organización, puede proporcionar una visión general de que softwares / aplicaciones pueden comprometer un activo en particular en función de sus configuraciones específicas y el software que ejecuta.
Map Reduce Engine (Ingeniería de Reducción de Mapeo)
Map-Reduce es una metodología de procesamiento de datos en la que se reciben los datos, los formateas de una manera que es fácil de consultar y luego ejecutas un reducir consulta.
Aquí hay un ejemplo:
Recibes una salida de netstat del endpoint #1:
firefox.exe ESTABLISHED 152.11.24.2
chrome.exe ESTABLISHED 192.168.0.44
Recibes una salida de netstat del endpoint #2:
firefox.exe ESTABLISHED 192.168.0.44
chrome.exe ESTABLISHED 152.11.24.2
Map stage - endpoint #1:
{ endpointId: 1, process: firefox.exe, connectionType: "externally facing", address: "152.11.24.2" }
{ endpointId: 1, process: chrome.exe, connectionType: "internally facing", address: "192.168.0.44" }
Map stage - endpoint #2:
{ endpointId: 2, process: firefox.exe, connectionType: "internally facing", address: "192.168.0.44" }
{ endpointId: 2, process: chrome.exe, connectionType: "externally facing", address: "152.11.24.2" }
Reduce
Get all external-facing endpoint
{ endpoint: [1,2] }
Protección del Software
A día de hoy, las opciones que tienen los equipos de seguridad para proteger los softwares son:
Mantener un registro de los parches de seguridad
Estar en contacto con los proveedores del software
Limitar el software a entornos o configuraciones específicos
Desde Vicarius entendemos que las organizaciones siguen siendo vulnerables incluso si realizan todo lo anterior.
El proceso de mitigación de vulnerabilidades del software consta de varios pasos.
En primer lugar, la comunidad o los investigadores de seguridad deben informar al proveedor del software acerca de una nueva posible vulnerabilidad.
Luego, tras un proceso de validación por parte del vendor, lo aprueba como un issue real.
Entonces, los detalles de la vulnerabilidad ya están disponibles públicamente y pueden servir a los hackers en futuros ataques.
Si el proveedor decide lanzar un parche de seguridad, asignará equipos de desarrollo para solucionarlo. Sin embargo, ese no es siempre el caso, ya que el tema está del lado del proveedor y no siempre cumple con los plazos de entrega de actualizaciones.
Como se publica una gran cantidad de parches de seguridad cada mes, las organizaciones de todo el mundo están luchando por propagar esas actualizaciones en sus redes, dejando sus activos digitales expuestos a amenazas de seguridad constantemente.
La forma que utiliza Vicarius para proteger los softwares es considerar las aplicaciones y los Sistemas Operativos como dos fuentes de "objetivos".
Sabemos que habrá un ataque, pero si podemos mapear las funcionalidades de los módulos que existen en una computadora determinada, el código malicioso quedará inutilizado en la misma.
vRx realiza sus análisis de las siguientes tres formas:
¿Cuáles son los ejecutables de aplicaciones legítimos?
¿Qué capacidades sensibles del Sistema Operativo utiliza el software a lo largo del tiempo?
¿Qué partes del código del software es probable que se exploten?
Figure #9, Mapeo de software de objetivos riesgosos
Controlando las acciones fuera de los límites del Ejecutable
Para hacer frente a los ataques que se originaron a partir de brechas de seguridad dentro del código pre compilado de un ejecutable (por ejemplo, Abuso del Ejecutable), vRx primero traza las capacidades sensibles en el SO y luego describe las capacidades que utiliza cada ejecutable.
Si bien el agente no podrá decir cuál es el tipo de ataque, o qué área de código es responsable de la falla, este, bloqueará el software mientras intenta acceder a capacidades que no forman parte de su mapa original.
Figure #10, Restricción de capacidades del SO a un software legítimo
La restricción de las capacidades sensibles del SO se realiza sobre aplicaciones legítimas, en caso de que alguien haga cosas que normalmente no hace.
Aislamiento ejecutable
Un ejecutable que se adjunta a una aplicación protegida puede acceder a sus capacidades Core y a las características del SO que fueron detectadas durante el proceso de mapeo.
Un escenario común de ataque puede involucrar a un adversario que intenta disfrazarse como uno de los ejecutables legítimos de la aplicación y actuar en su nombre. En este documento también hemos descrito esta técnica (p. Ej., Suplantar el Ejecutable).
Para impedir que los procesos se oculten como un ejecutable legítimo, vRx tiene un mecanismo de aislamiento para verificar la integridad del ejecutable.
Figure #11, Bloqueo del ataque basado en la suplantación
La capacidad de suplantación en el SO se puede utilizar con fines legítimos, como en el debugging. Por esa razón, vRx no bloquea ningún tipo de intento de suplantación y, además, permite que cualquier ejecutable use esa capacidad.
Figure #12, Intento de suplantación de identidad visto en la plataforma vRx de Vicarius
El único caso en el que el agente iniciará un bloqueo es una vez que un ejecutable protegido sea el objetivo del intento de suplantación. De esa manera, nuestro agente garantiza una baja sobrecarga en la experiencia del usuario y bajas tasas de falsos positivos.
Protección de Librerías
Como ya pudimos ver, los softwares vienen con librerías integradas que generalmente contienen capacidades sensibles.
El proceso de identificación de áreas de código peligrosas (p. Ej., Funcionalidades de Riesgo dentro de la Aplicación) es similar a lo que hacen los atacantes durante la fase de ataque de reconocimiento (p. Ej., Abusar directamente de las Librerías).
La principal diferencia entre el proceso de análisis que realiza vRx y lo que hace el atacante es que, para que el atacante explote una funcionalidad, es necesario comprender tanto la entrada como la salida de esa función, pero con vRx no es necesario.
Figure #13, Restricción de abuso de capacidad de software
El agente se coloca una puerta sobre el objetivo deseado del atacante no permitiéndole relacionarse con su entrada o salida.
Figure #14, Intento de abuso del software visto en la plataforma vRx de Vicarius
Para disminuir la actividad en tiempo de ejecución, se realizan verificaciones de integridad basadas en tokens en puntos de carga de bibliotecas específicos y no en cada llamada al sistema de funciones.
Referencias
‘Is poor software development the biggest cyber threat?’, Steve Morgan, Link
‘What do SAST, DAST, IAST, and RASP mean to developers?’, Sherif Koussa, Link
‘Market Guide for Vulnerability Assessment’, Oliver Rochford & Prateek Bhajanka, Link
‘Hype Cycle for Application Security, 2017’, Ayal Tirosh, Link
‘Using third-party vendors? Keep a close eye on them’, Michelle Drolsset, Link
‘What is a DLL?’, Microsoft Official Support, Link
‘Shared Libraries: Understanding Dynamic Loading’, Amir Rachum, Link
‘CWE CATEGORY: Cryptographic Issues’, MITRE Official Website, Link
‘CWE-779: Logging of Excessive Data’, MITRE Official Website, Link
‘CWE-522: Insufficiently Protected Credentials’, MITRE Official Website, Link
‘CAPEC-66: SQL Injection’, MITRE Official Website, Link
‘CWE-121: Stack-based Buffer Overflow’, MITRE Official Website, Link
‘OpenProcess function’, Microsoft Official Support, Link
‘gentilkiwi/mimikatz’, GitHub, Link
‘rapid7/metasploit-framework’, GitHub, Link
‘PowerShellMafia/PowerSploit’, GitHub, Link
‘Peering Inside the PE: A Tour of the Win32 Portable Executable File Format’, Microsoft Official Support, Link
‘CWE CATEGORY: 7PK - API Abuse’, MITRE Official Website, Link
‘LoadLibrary function’, Microsoft Official Support, Link
‘Network Security Services’, MDN web docs moz://a, Link
‘Common Vulnerabilities and Exposures’, MITRE Official Website, Link
‘Understanding How MapReduce is Used in Data Science’, DataScienceGraduatePrograms, Link
‘GNU Bash’, GNU Official Website, Link
‘Adobe Flash Player’, Adobe Official Website, Link
‘Apache Struts’, Apache Software Foundation, Link
‘Apache Tomcat’, Apache Software Foundation, Link
‘Vicarius Blog’, Vicarius LTD, Link