Al realizar una evaluación de seguridad del software, si tiene acceso al código fuente de una aplicación compilada (por ejemplo, C ++), ¿realizaría algún análisis sobre la versión compilada, ya sea con alguna técnica automatizada o manualmente? ¿Fuzzing es la única técnica aplicable en esta situación o existen otras ventajas potenciales al mirar el binario?
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 un código delicado, introduciendo fallas sutiles, como eludir ciertas comprobaciones, que aparecen en el código (que satisfacen la revisión del código) pero no en el binario (que no supera la prueba de realidad). < br>
También hay ciertos rootkits a nivel de código - mencionaste C ++, pero también hay rootkits de código administrado para, por ejemplo. .NET y Java: eso evadiría completamente la revisión del código, pero se mostraría en los binarios implementados.
Además, el compilador en sí puede tener ciertos rootkits, que permitirían insertar puertas traseras en su aplicación. (Vea un poco del historial 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 mismo cuando se recompila desde el código "limpio"). Nuevamente, falta el código fuente pero está presente en el binario.
Dicho esto, es, por supuesto, más difícil y lento invertir la ingeniería del binario, y sería inútil en la mayoría de los escenarios 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 eliminado todas las otras vulnerabilidades que encontró a través de revisión de código, análisis de intervalos, confusión, modelado de amenazas, etc. E incluso así, solo molesta si es una aplicación altamente sensible o extremadamente visible.
Los casos de vanguardia son lo suficientemente difíciles de encontrar, y lo suficientemente raros, que sus esfuerzos pueden gastarse mejor en otros lugares.
Por otra parte, tenga en cuenta que hay algunos productos de análisis estático que analizan específicamente los binarios (por ejemplo, Veracode), por lo que si está usando uno de esos, no importa ...
@AviD puntos sólidos, totalmente de acuerdo con los kits de raíz en el componente binarios / compiladores.
Si usted es un profesional de los conocimientos de la información, dejando de lado los puntos válidos que hace AviD, lo más probable es que las vulnerabilidades estén en su 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 reparar / prevenir la mayoría de los orificios 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 / idioma (lo que generalmente no es una opción viable).
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 un emulador como Valgrind (que puede verificar varios aspectos de un programa compilado).
La seguridad y la corrección del programa suelen ir de la mano.
Para mí, primero es alinear el código (es decir, usar PCLINT), luego crear binarios, verificarlos 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.
El análisis de código fuente y binario ofrece puntos de vista un poco diferentes y, por lo tanto, ambos deberían 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 ensamblaje 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, las características específicas de la aplicación y 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: enlace
Hay un punto al que AviD aludió pero que probablemente se debe enfatizar, y es que la revisión del código tiende a ser un proceso mucho más eficaz en tiempo y esfuerzo que la revisión binaria. Particularmente con C ++, el binario es muy difícil, incluso para el profesional de seguridad promedio, y mucho menos para el desarrollador promedio.
Para lenguajes interpretados esto no es tanto el caso. El código de bytes de Java y .NET no oculto se puede transformar de nuevo en algo legible para los humanos.
Lea otras preguntas en las etiquetas source-code appsec binary-code code-review