Algunos términos me confunden: la ingeniería inversa me parece bastante similar a la investigación de exploits. Quiero decir que si puedes revertir un programa, probablemente puedas encontrar una vulnerabilidad, pero para esto necesitas ser bueno con C y Assembly.
Mucha gente me dice que un probador de pluma debe dominar python y otro lenguaje de scripting, no C y Assembly. Esto es realmente confuso, entonces mi pregunta es:
¿La explotación de la investigación es parte de la prueba?
Corto:
¿La investigación de exploits es diferente de las pruebas de penetración? Sí.//strong>
¿La explotación de la investigación es parte de la prueba? Por lo general no.
Un buen resumen de lo que es la prueba de penetración está aquí: Definición de Wikipedia de prueba de penetración .
Una gran cantidad de trabajo de pruebas de penetración en realidad solo está ejecutando ataques o explotaciones preexistentes y bien conocidas. (Como, por ejemplo, ejecutar MetaSploit). Este trabajo se basa en algunos modelos de dónde pueden estar los problemas relevantes. Pero en realidad no implica la investigación de exploits o la ingeniería inversa.
Sin embargo, al profundizar en las pruebas de penetración, no es suficiente usar herramientas que están completamente disponibles. En este escenario, la gente:
El análisis del sistema de destino generalmente se encuentra en el nivel de examen de su diseño de alto nivel, componentes (como servidores web, marcos, protocolos de comunicación, etc.). Por supuesto, este análisis puede ir tan profundo como la ingeniería inversa o la revisión del código fuente, pero a menudo los detalles de un nivel más alto son lo suficientemente buenos como para definir suficientemente cómo atacar el sistema.
En esta respuesta anterior se puede encontrar una descripción más detallada de las etapas habituales relevantes para las pruebas de penetración ¿Cuál es la diferencia entre una prueba de penetración? y una evaluación de vulnerabilidad?
La razón por la cual la investigación inversa y la explotación de explotaciones rara vez es una parte importante de la prueba es que se está realizando la prueba para el propietario del sistema. Por lo tanto, al atacante ya se le dan herramientas mucho mejores que las que suelen tener los investigadores de explotaciones: el sistema generalmente se les revela en detalle para permitirles hacer su trabajo de manera eficiente. (En otras palabras, se les permite hacer un cortocircuito en gran parte de la investigación de explotación).
La razón por la que el scripting es importante en las pruebas de penetración es que las pruebas de penetración generalmente involucran grandes cantidades de casos de prueba muy similares. Para hacer esas pequeñas variaciones de manera eficiente, las secuencias de comandos se utilizan normalmente.
Por ejemplo, Metasploit, que es una herramienta común para usar en este campo, se puede crear un script usando python.
Además de python, se usan otros lenguajes de script, como Ruby y perl.
Quiero decir que si puedes revertir un programa, probablemente puedas encontrar una vulnerabilidad, pero para esto necesitas ser bueno con C y Assembly.
En caso de software bien escrito, no estaría de acuerdo. Incluso si tiene acceso al código fuente original del software, normalmente es difícil encontrar vulnerabilidades.
Si solo tiene acceso al binario, es aún más difícil, ya que efectivamente necesita descompilar el software, desapareció gran cantidad de conocimiento y el código ya no está en un formato fácil de leer. El software moderno es lo suficientemente grande como para que sea muy difícil concentrarse en partes importantes del binario y extraer de él vulnerabilidades esenciales.
Sobre la base de la gran respuesta del usuario 4982, también agregaría que la ingeniería inversa y la investigación de explotación son dos actividades un tanto distintas también. El ingeniero inverso busca entender un producto estudiando sus componentes básicos, posiblemente para interactuar con un producto existente, pero a veces solo para clonarlo. Y dependiendo de los motivos, el investigador de exploits puede intentar romper un producto sin la intención de arreglar o cambiar nada.
El investigador de exploits puede utilizar la ingeniería inversa como una de las muchas herramientas para eliminar una vulnerabilidad de un paquete, pero tendrá otras: las herramientas de prueba de fuzz y exploits de inyección vienen inmediatamente a la mente. Y un ingeniero inverso puede estar buscando proteger o fortalecer un producto vulnerable, con la intención de protegerse a sí mismo de sus vulnerabilidades inherentes, por lo que puede usar las mismas herramientas de falsificación y de inyección para encontrar lugares para parchear. Son dos caras diferentes de la misma moneda.
Lea otras preguntas en las etiquetas penetration-test reverse-engineering debugging