El motor de detección de Ostorlab

La tecnología de detección de vulnerabilidades de Ostorlab se basa en 3 componentes clave: un motor de análisis estático, un motor de análisis dinámico y de comportamiento, y un motor de análisis de backend.

El motor de análisis estático realiza las siguientes funciones:

• Comprobaciones de configuración: por ejemplo, verificar que la aplicación desactiva el modo de depuración, que cuenta con una configuración adecuada de framework para producción, como una lista blanca segura de Apache Cordova, o que dispone de una política de seguridad de red segura.

• Comprobaciones de dependencias: se centra en identificar las dependencias y sus versiones, ya sea mediante los archivos de versión que algunos frameworks proporcionan amablemente, o inspeccionando el binario en busca de identificadores específicos elaborados a mano por el equipo de Ostorlab. Se buscan vulnerabilidades conocidas en estas dependencias.

• Análisis de taint: una de las funciones avanzadas y únicas que ofrece Ostorlab es un motor de análisis de taint muy eficiente y de nivel de producción. El motor abarca un conjunto de tecnologías, como el bytecode de Android, y es capaz de realizar el análisis en toda la aplicación, buscando vulnerabilidades ocultas tras decenas de llamadas a métodos. Estas vulnerabilidades incluyen el uso de criptografía insegura, como el modo de bloques ECB o el algoritmo DES, la inyección SQL expuesta a través de un esquema de URL o de un content provider, y la ejecución de comandos expuesta a través de un servicio o de un content provider.

El motor de análisis dinámico realiza varias acciones:

• Preparación de la aplicación: reempaqueta la aplicación para el análisis, lo que incluye habilitar el modo de depuración, volver a firmar la aplicación y desactivar las comprobaciones problemáticas que pueden dificultar el análisis.

• Preparación del dispositivo: instala la aplicación en un dispositivo real y configura la aplicación para que espere a un depurador, y esto se aplica tanto a Android como a iOS. Ostorlab utiliza dispositivos reales por motivos de rendimiento y reproducibilidad.

• Análisis del protocolo de depuración: instrumenta la aplicación mediante protocolos de depuración como JDWP o LLDB. Ostorlab mantiene su propia pila para poder interactuar a bajo nivel con la aplicación. La instrumentación consiste en colocar trazas en API estratégicas, conocidas como fuentes (de entradas no confiables) y sumideros (que pueden dar lugar a vulnerabilidades). Ostorlab utiliza protocolos de depuración para el análisis, en lugar del análisis en memoria, tanto por estabilidad como por extensibilidad. Los protocolos de depuración son menos arriesgados que manipular la memoria para interceptar las API mediante hooking, y además son estables entre las distintas versiones del sistema operativo. Los protocolos de depuración tienen una penalización de rendimiento, ya que ralentizan la aplicación, una penalización que sigue siendo aceptable en el contexto de la detección de vulnerabilidades. La extensibilidad proviene de las funciones que ofrecen los depuradores, como comprender la disposición de la memoria de Swift u Objective-C, lo que permite escribir código de instrumentación claro y conciso.

• Trazado y análisis: las trazas se recopilan y se analizan sobre la marcha en busca de patrones vulnerables conocidos, por ejemplo, la llamada a una API criptográfica con un método inseguro o una clave codificada de forma rígida. Este paso también recopila el tráfico mediante hooking directamente en la API de TLS/SSL y la API de Socket. Este enfoque elude el SSL Pinning. El tráfico recopilado se envía después al motor de análisis de backend; vea un ejemplo de informe aquí.

• Monkey Testing: un test monkey empieza a interactuar con la aplicación, ya sea mediante un conjunto de heurísticas para detectar páginas de autenticación o haciendo clic al azar por la aplicación. En el caso de interacciones complejas con la interfaz, se escriben reglas de automatización de la interfaz con BDD para definir la interacción mediante scripts.

El motor de análisis de backend se apoya en el análisis dinámico para recopilar el tráfico y, a continuación, realiza las siguientes acciones:

• Detección pasiva: se basa en analizar los atributos de las solicitudes y las respuestas, como el cuerpo y las cabeceras, en busca de vulnerabilidades, como atributos de cookie ausentes, CORS inseguro, componentes vulnerables según las versiones inferidas, etc.

• Detección activa: Ostorlab, como escáner de seguridad centrado primero en dispositivos móviles, se enfoca en comprender varios protocolos de serialización de uso habitual en las aplicaciones móviles, como GraphQL o Protobuf. Se aplica fuzzing a estos protocolos de serialización en busca de vulnerabilidades como inyección SQL, XXE, inyección de plantillas, etc.

Estas etapas no se ejecutan de forma secuencial, ya que detrás de cada una hay varios microagentes especializados en una tarea específica. Estos agentes se comunican mediante un bus compartido y se basan en una arquitectura orientada a eventos.

Durante cada uno de estos análisis se recopilan artefactos, como capturas de pantalla de la aplicación, registros del dispositivo y código fuente descompilado.

Los tres motores de análisis proporcionan una cobertura integral de la superficie de ataque de la aplicación y compensan las deficiencias inherentes a cada análisis por separado. Por ejemplo, el análisis estático ofrece una excelente cobertura de la superficie de ataque de la aplicación, pero al mismo tiempo puede generar falsos positivos debido a rutas de ejecución complejas o a código muerto. El análisis dinámico produce muchos menos falsos positivos porque observa el comportamiento real, pero no puede garantizar la cobertura completa de la superficie de la aplicación, y el análisis de backend detecta vulnerabilidades inherentes al backend, que en la mayoría de los casos está dedicado a la aplicación móvil.