it-swarm-es.com

Análisis de código: binario vs fuente

Mientras realiza una evaluación de seguridad de software, si tiene acceso al código fuente de una aplicación compilada (por ejemplo, C++), ¿alguna vez haría algún análisis sobre la versión compilada, ya sea con alguna técnica automatizada o de forma manual? ¿Es el fuzzing la única técnica aplicable en esta situación o hay otras ventajas potenciales de mirar el binario?

14
TobyS

Depende de la situación: tipo de aplicación, modelo de implementación, especialmente su modelo de amenaza, etc.

Por ejemplo, ciertos compiladores pueden cambiar sustancialmente algún código delicado, introduciendo defectos sutiles, como omitir ciertas comprobaciones, que aparecen en el código (que satisfacen la revisión de su código) pero no en el binario (no pasa la prueba de realidad).
También hay ciertos rootkits de nivel de código - usted mencionó C++, pero también hay rootkits de código administrado por ej. .NET y Java - eso evadiría por completo la revisión de su código, pero aparecería en los binarios implementados.
Además, el compilador en sí mismo puede tener ciertos rootkits, que permitirían insertar puertas traseras en su aplicación. (Vea un poco de historia del rootkit original - el compilador insertó una contraseña de puerta trasera en el script de inicio de sesión; también insertó esta puerta trasera en el compilador en sí al volver a compilar desde el código "limpio"). Nuevamente, falta en el código fuente pero está presente en el binario.


Dicho esto, por supuesto, es más difícil y lento invertir la ingeniería inversa del binario, y sería inútil en escenarios ¡la mayoría si ya tiene el código fuente.
Quiero enfatizar este punto: si tiene el código fuente, ¡ni siquiera se moleste con RE hasta que haya limpiado todas las otras vulnerabilidades que ha encontrado a través de la revisión de código, pentesting, fuzzing, modelado de amenazas, etc. E incluso entonces, solo se molesta si es una aplicación altamente sensible o extremadamente visible.
Los casos Edge son lo suficientemente difíciles de encontrar, y lo suficientemente raro como para que tus esfuerzos se puedan gastar mejor en otro lugar.


Por otro lado, tenga en cuenta que hay algunos productos de análisis estático que escanean específicamente los binarios (por ejemplo, Veracode), por lo que si está utilizando uno de ellos, realmente no importa ...

12
AviD

@AviD puntos sólidos, totalmente de acuerdo en los kits de raíz en el componente binarios/compiladores.

Si eres un profesional de la seguridad con conocimientos, dejando de lado los puntos válidos que AviD hace, la mayoría de las vulnerabilidades probablemente estarán en tu código fuente. Tener un sólido conocimiento de la programación de forma segura y cómo se realiza la ingeniería inversa debería brindarle el mejor método para corregir/prevenir la mayoría de los agujeros en su código fuente. Además, si hay un exploit con un compilador/binario, muchas veces no hay nada que usted como desarrollador pueda hacer para evitarlo, excepto usar otro compilador/lenguaje (que generalmente no es una opción viable).

7
mrnap

Hay muchas razones además de las relacionadas con la seguridad para analizar el binario final. Ya sea por medio de un depurador, desensamblador o un generador de perfiles y emulador como Valgrind (que puede verificar varios aspectos de un programa compilado).

La seguridad y la corrección del programa generalmente van de la mano.

Para mí, primero está alineando el código (es decir, usando PCLINT), luego creando binarios, verificándolos con un fuzzer y memcheck (de Valgrind) y eso me dio muy buenos resultados en cuanto a robustez y confiabilidad. Solo PCLINT en este caso tiene acceso al código fuente.

4
0xC0000022L

El análisis de código fuente y binario ofrece puntos de vista un poco diferentes y, por lo tanto, ambos deben aplicarse. Sin embargo, el análisis binario puede ser intimidante para los humanos. No diría que el análisis a nivel de código fuente no puede ser frustrante, pero analizar las lógicas de aplicación a nivel de ensamblado no es la mejor opción. En el análisis binario se trata de lo que sucede de hecho y no puede ser de otra manera. Si en el código fuente puede hacer algunas suposiciones, aquí está el estado definido.

Sin embargo, las pruebas como fuzzing deben ejecutarse contra la aplicación compilada para garantizar la solidez de la aplicación, al menos en algún nivel. La cobertura del código depende de la metodología de fuzzing, de las especificaciones de la aplicación y de algunos otros factores; demasiado para explicar aquí, eso es arte de fuzzing. Incluso Microsoft desarrolla herramientas para fuzzing y las aplica en SDL . Aquí hay un documento de Codenomicon como una idea de un proceso: http://www.codenomicon.com/resources/whitepapers/codenomicon-wp-sdl-20100202.pdf

2
anonymous

Hay un punto al que AviD aludió, pero que probablemente debería enfatizarse, y es que la revisión de código tiende a ser un proceso mucho más efectivo que la revisión binaria. Particularmente con C++, el binario es muy difícil de entender incluso para el profesional de seguridad promedio, y mucho menos para el desarrollador promedio.

Para los idiomas interpretados, este no es el caso. No ofuscado Java y .NET bytecode pueden transformarse nuevamente en algo bastante legible para los humanos.

0
Aaron

Siempre es necesario mirar el binario, ya que muchas de las características de seguridad solo se pueden evaluar cuando se realiza un análisis del binario cumplido. Por ejemplo, el código puede insinuar vulnerabilidades en la lógica de la aplicación, el binario cumplido nos dirá si ciertas características de compilación como ASLR y el ejecutable de la pila están habilitadas o deshabilitadas. Esta información no se puede obtener simplemente mirando el código fuente. Si bien el difuminado es generalmente una técnica útil para las vulnerabilidades de la fuerza bruta, puede llevar mucho tiempo y muchos recursos, solo confiar en él para identificar problemas a veces puede conducir a resultados falsos o perdidos. Por lo tanto, también se requiere una herramienta de ingeniería inversa como radare2 o hopper para analizar el binario.

También he encontrado este recurso que compara el análisis de código fuente binario vs, esto debería ayudar Binray vs source code analysis

Descargo de responsabilidad: trabajo en Appknox

0
Chaitanya Gatreddi