"Y lo imposible es posible": convertimos un cuadro negro en blanco mediante análisis binario

Por el momento, hay dos enfoques principales para la búsqueda de vulnerabilidades en las aplicaciones: análisis estático y dinámico. Ambos enfoques tienen sus pros y sus contras. El mercado llega a la conclusión de que ambos enfoques deben usarse: resuelven problemas ligeramente diferentes con resultados diferentes. Sin embargo, en algunos casos, el uso del análisis estático es limitado, por ejemplo, cuando no hay código fuente. En este artículo, hablaremos sobre una tecnología bastante rara pero muy útil que le permite combinar las ventajas de los enfoques estáticos y dinámicos: el análisis estático del código ejecutable.


El análisis de software (software) para detectar la presencia de capacidades no declaradas (NDV) y vulnerabilidades es la tecnología principal para garantizar la seguridad de las aplicaciones.
Hablando de tecnologías clásicas y bien establecidas para analizar software en busca de vulnerabilidades y NDV (para el cumplimiento de los requisitos de seguridad de la información), podemos distinguir:

• análisis de código estático (pruebas de seguridad de aplicaciones estáticas);
• análisis de código dinámico (Dynamic Application Security Testing).

Existe IAST (análisis interactivo), sin embargo, es esencialmente dinámico (en el proceso de análisis, un agente adicional observa lo que sucede durante la ejecución de la aplicación). RASP (Runtime Application Self-Defense), que a veces también se menciona en varias herramientas de análisis, es más probable que sea una herramienta de protección.

El análisis dinámico (el método "Black Box") es una verificación del programa durante su ejecución. Las siguientes ventajas se pueden distinguir de este enfoque.

1. Dado que las vulnerabilidades están en el programa ejecutable y el error se detecta utilizando su operación, la generación de falsos positivos es menor que la del análisis estático.
2. No se necesita código fuente para realizar el análisis.

Pero también hay desventajas.

1. Cobertura incompleta del código y, por lo tanto, existen riesgos de vulnerabilidades faltantes. Por ejemplo, el análisis dinámico no puede encontrar vulnerabilidades asociadas con el uso de criptografía débil o marcadores como "bomba temporal".
2. La necesidad de ejecutar la aplicación, que en algunos casos puede ser difícil. El lanzamiento de la aplicación puede requerir una configuración compleja y la configuración de varias integraciones. Además, para que los resultados sean lo más precisos posible, es necesario reproducir el "entorno de combate", pero es difícil darse cuenta de esto sin dañar el software.

El análisis estático (el método de la "Caja blanca") es un tipo de prueba de programa en el que el programa no se ejecuta.

Enumeramos los beneficios.

1. Cobertura completa del código, lo que lleva a la búsqueda de más vulnerabilidades.
2. Sin dependencia del entorno en el que se ejecutará el programa.
3. La capacidad de implementar pruebas en las etapas iniciales de escritura de código para un módulo o programa en ausencia de archivos ejecutables. Esto le permite integrar de manera flexible una solución similar en el SDLC (Ciclo de vida de desarrollo de software ciclo de vida de desarrollo de software) al comienzo del desarrollo.

El único inconveniente del método es la presencia de falsos positivos: la necesidad de evaluar si el analizador indica un error real o si es probable que este falso positivo.

Como podemos ver, ambos métodos de análisis tienen ventajas y desventajas. Sin embargo, ¿es posible de alguna manera utilizar las ventajas de estos métodos y minimizar las desventajas? Sí, si aplica el análisis binario: la búsqueda de vulnerabilidades en archivos ejecutables mediante análisis estático.

Análisis binario o tecnología de análisis de archivos ejecutables

El análisis binario permite el análisis estático sin código fuente, por ejemplo, en el caso de contratistas externos. Además, la cobertura del código será completa, en contraste con la aplicación del método de análisis dinámico. Mediante el análisis binario, puede verificar las bibliotecas de terceros utilizadas en el proceso de desarrollo para las que no hay código fuente. Además, mediante el análisis binario, puede realizar una verificación de control de la versión, comparando los resultados del análisis del código fuente del repositorio y el código ejecutable del servidor de combate.

En el proceso de análisis binario, la imagen binaria se transforma en una representación intermedia (representación interna o modelo de código) para su posterior análisis. Después de eso, los algoritmos de análisis estático se aplican a la representación interna. Como resultado, el modelo actual se complementa con la información necesaria para la detección adicional de vulnerabilidades y NDV. En la siguiente etapa, la aplicación de las reglas para buscar vulnerabilidades y NDV.

Escribimos más sobre el esquema de análisis estático en un artículo anterior . A diferencia del análisis de código fuente, que utiliza elementos de teoría de compilación (análisis léxico, sintáctico) para construir el modelo, el análisis binario utiliza la teoría de traducción inversa para desmontar, descompilar y desofuscar el modelo.

Un poco sobre los términos

Estamos hablando de analizar archivos ejecutables que no tienen información de depuración. Con la información de depuración, la tarea se simplifica enormemente, pero si hay información de depuración, lo más probable es que el código fuente sea irrelevante.

En este artículo, llamamos al análisis de bytecode de Java también análisis binario, aunque esto no es del todo correcto. Hacemos esto para simplificar el texto. Por supuesto, la tarea de analizar el bytecode JVM es más simple que analizar el código binario C / C ++ y Objective-C / Swift. Pero el esquema de análisis general es similar en el caso de bytecode y código binario. Las principales dificultades descritas en el artículo se relacionan específicamente con el análisis del código binario.

La descompilación es el proceso de recuperación del código fuente del código binario. Puede hablar sobre los elementos de la traducción inversa: desmontaje (obtención del código del ensamblador a partir de una imagen binaria), traducción del ensamblador a un código de tres direcciones u otra representación, restauración de las construcciones del nivel del código fuente.

Ofuscación: transformaciones que preservan la funcionalidad del código fuente, pero dificultan la descompilación y la comprensión de la imagen binaria resultante. La desofuscación es la transformación inversa. La ofuscación se puede aplicar tanto a nivel de código fuente como a nivel de código binario.

¿Cómo ver los resultados?

Comencemos un poco desde el final, pero la cuestión de ver los resultados del análisis binario generalmente se hace primero.

Es importante que un especialista analice el código binario para asignar vulnerabilidades y NDV al código fuente. Para hacer esto, en la etapa final, el proceso de desofuscación (desentrañamiento) se inicia si se aplicaron conversiones confusas, y el código binario se descompiló en la fuente. Es decir, las vulnerabilidades se pueden demostrar en el código descompilado.

En el proceso de descompilación, incluso si descompilamos el bytecode de JVM, parte de la información no se restaura correctamente, por lo que el análisis en sí tiene lugar en una representación cercana al código binario. En consecuencia, surge la pregunta: ¿cómo, al encontrar vulnerabilidades en el código binario, localizarlas en la fuente? La solución al problema para el código de bytes JVM se describió en nuestro artículo sobre la búsqueda de vulnerabilidades en el código de bytes Java . La solución para el código binario es similar, es decir, una pregunta técnica.

Repitamos la advertencia importante: estamos hablando del análisis de código binario sin información de depuración. En presencia de información de depuración, la tarea se simplifica enormemente.

La pregunta principal que se nos hace para mostrar los resultados es si el código descompilado es suficiente para comprender y localizar la vulnerabilidad.


A continuación se presentan algunos pensamientos sobre este tema.

1. Si estamos hablando del código de bytes JVM, entonces en general la respuesta es "sí": la calidad de descompilación del código de bytes es excelente. Casi siempre puedes descubrir cuál es la vulnerabilidad.
2. Lo que puede interferir con la localización cualitativa de la vulnerabilidad es una simple ofuscación, como renombrar nombres de clase y funciones. Sin embargo, en la práctica a menudo resulta que es más importante comprender la vulnerabilidad que determinar en qué archivo se encuentra. La localización es necesaria cuando alguien puede corregir la vulnerabilidad, pero en este caso, el desarrollador también comprenderá de dónde proviene la vulnerabilidad del código descompilado.
3. Cuando hablamos del análisis del código binario (por ejemplo, C ++), por supuesto, todo es mucho más complicado. No hay ninguna herramienta que recupere completamente el código aleatorio de C ++. Sin embargo, la peculiaridad de nuestro caso es que no necesitamos compilar el código más tarde: necesitamos calidad suficiente para comprender la vulnerabilidad.
4. Muy a menudo, puede lograr una calidad de descompilación suficiente para comprender la vulnerabilidad encontrada. Para hacer esto, debe resolver muchos problemas complejos, pero puede resolverlos (a continuación, hablaremos brevemente al respecto).
5. Para C / C ++, es aún más difícil localizar la vulnerabilidad: los nombres de los caracteres se pierden de muchas maneras durante el proceso de compilación, no puede restaurarlos.
6. La situación en Objective-C es ligeramente mejor: hay nombres de funciones allí y es más fácil localizar la vulnerabilidad.
7. Los problemas de ofuscación se distinguen. Hay una serie de transformaciones complejas que pueden complicar la descompilación y el mapeo de vulnerabilidades. En la práctica, resulta que un buen descompilador puede manejar la mayoría de las conversiones confusas (recuerde que necesitamos suficiente calidad de código para comprender la vulnerabilidad).

Como conclusión, la mayoría de las veces muestra la vulnerabilidad para que se pueda entender y verificar.

Complejidades y detalles del análisis binario.

Aquí no hablaremos sobre el bytecode: todas las cosas interesantes sobre él ya se han dicho anteriormente. Lo más interesante es el análisis del código binario real. Aquí hablaremos sobre el análisis de C / C ++, Objective-C y Swift como ejemplo.

Surgen dificultades significativas incluso cuando se desmonta. La etapa más importante es la división de la imagen binaria en subprogramas. Luego, seleccione las instrucciones del ensamblador en las subrutinas, una cuestión técnica. Escribimos sobre esto en detalle en un artículo para la revista "Issues of Cybersecurity No. 1 (14) - 2016" , aquí describiremos brevemente.

Como ejemplo, hablaremos de la arquitectura x86. Las instrucciones que contiene no tienen una longitud fija. En las imágenes binarias, no hay una división clara en secciones de código y datos: las tablas de importación, las tablas de funciones virtuales pueden estar en la sección de códigos, las tablas de transición pueden estar en los intervalos entre los bloques de funciones base en la sección de códigos. En consecuencia, debe poder separar el código de los datos y comprender dónde comienzan y dónde terminan las rutinas.

Los más comunes son dos métodos para resolver el problema de determinar las direcciones iniciales de los subprogramas. En el primer método, las direcciones de los subprogramas están determinadas por el prólogo estándar (para la arquitectura x86 es push ebp; mov ebp, esp). En el segundo método, una sección de código se atraviesa recursivamente desde el punto de entrada con reconocimiento de instrucciones de llamada de subrutina. La anulación se realiza reconociendo las instrucciones de ramificación. Las combinaciones de los métodos descritos también se utilizan cuando se inicia un recorrido recursivo desde las direcciones de inicio encontradas por el prólogo.

En la práctica, resulta que tales enfoques dan un porcentaje bastante bajo de código reconocido, ya que no todas las funciones tienen un prólogo estándar, y hay llamadas y transiciones indirectas.

Los algoritmos básicos se pueden mejorar mediante las siguientes heurísticas.

1. En una gran base de prueba de imágenes, encuentre una lista más precisa de los prólogos (nuevos prólogos o variaciones de los estándares).
2. Puede buscar automáticamente tablas de funciones virtuales y, a partir de ellas, seleccionar las direcciones iniciales de los subprogramas.
3. Las direcciones iniciales de subprogramas y algunas otras construcciones se pueden encontrar en base a secciones de código binario asociadas con el mecanismo de manejo de excepciones.
4. Puede verificar las direcciones de inicio buscando estas direcciones en la imagen y reconociendo las instrucciones de llamada.
5. Para buscar límites, puede hacer un recorrido recursivo de la subrutina con el reconocimiento de las instrucciones de la dirección de inicio. Hay una dificultad con las transiciones indirectas y las funciones sin retorno. El análisis de la tabla de importación y el reconocimiento de construcciones de conmutadores pueden ayudar.
   

Otra cosa importante que debe hacerse durante la traducción inversa, para buscar normalmente una vulnerabilidad más adelante, es reconocer las funciones estándar en una imagen binaria. Las funciones estándar pueden estar vinculadas estáticamente a la imagen, o incluso pueden estar en línea. El algoritmo de reconocimiento principal es una búsqueda por firma con variaciones; para la solución, puede ofrecer el algoritmo Aho-Korasik adaptado. Para recopilar firmas, debe analizar previamente las imágenes de la biblioteca recopiladas con diferentes condiciones y seleccionarlas como bytes que no cambian.

Que sigue

En la sección anterior, examinamos la etapa inicial de la traducción inversa de una imagen binaria: el desmontaje. La etapa, de hecho, es inicial, pero determinante. En esta etapa, puede perder parte del código, lo que tendrá un efecto dramático en los resultados del análisis.


Entonces suceden muchas cosas interesantes. Diga brevemente sobre las tareas principales. No hablaremos en detalle: ya sea el conocimiento, sobre el cual no podemos escribir explícitamente aquí, o no hay soluciones técnicas y de ingeniería muy interesantes en los detalles.

1. Convertir el código de ensamblaje en una representación intermedia en la que se puede realizar el análisis. Puede usar varios bytecodes. Para los lenguajes C, LLVM parece ser una buena opción. LLVM es activamente apoyado y desarrollado por la comunidad, la infraestructura, incluso útil para el análisis estático, es actualmente impresionante. En esta etapa, hay una gran cantidad de detalles a los que debe prestar atención. Por ejemplo, debe detectar qué variables se abordan en la pila para no multiplicar entidades en la vista resultante. Debe configurar la visualización óptima de los conjuntos de instrucciones de ensamblador en las instrucciones de bytecode.
2. Restaurar estructuras de alto nivel (por ejemplo, bucles, ramas). Cuanto más exactamente sea posible restaurar las construcciones originales del código del ensamblador, mejor será la calidad del análisis. La restauración de tales construcciones se lleva a cabo utilizando elementos de la teoría de grafos en CFG (control de flujo) y algunas otras representaciones gráficas del programa.
3. Realización de algoritmos de análisis estático. Hay detalles. En general, no es muy importante si obtuvimos la representación interna de la fuente o del binario: todos también necesitamos construir CFG, aplicar algoritmos de análisis de flujo de datos y otros algoritmos típicos de la estática. Existen algunas características al analizar la vista obtenida del binario, pero son más técnicas.

Conclusiones

Hablamos sobre cómo hacer análisis estáticos cuando no hay código fuente. Según la experiencia de comunicación con los clientes, resulta que la tecnología es muy demandada. Sin embargo, la tecnología es rara: el problema del análisis binario no es trivial, su solución requiere algoritmos complejos de alta tecnología de análisis estático y traducción inversa.

Este artículo fue escrito en colaboración con Anton Prokofiev, analista de Solar appScreener