¿Cómo funciona el desarrollo de exploit para los probadores de penetración?

4

Al realizar el desarrollo de exploits, el proceso siempre se basa en la dirección de memoria de la máquina de la víctima.

Como desarrollador de exploits, deberá configurar un entorno de máquinas atacantes / víctimas y probarlo. Las principales pistas para el desarrollador de exploits en su viaje hacia la obtención de una shell desde la aplicación vulnerable son la dirección de memoria (DLL y ubicaciones de búfer principalmente) que obtiene al adjuntar la aplicación a un depurador (generalmente señalado por los registros de CPU como EIP, ESP, etc).

Esto es bueno si el objetivo final es hacer un código de prueba de concepto para demostrar que esta aplicación es vulnerable. Sin embargo, hasta donde sé, esas direcciones no son permanentes y pueden cambiar de una máquina a otra. Si está realizando una prueba de penetración de caja negra para una empresa, no podrá adjuntar un depurador a su aplicación para obtener las direcciones correctas a las que saltar. Y lo mismo se aplica a las vulnerabilidades públicas de exploit-db porque la mayoría de las vulnerabilidades allí necesitan algunas correcciones con respecto a las direcciones y compensaciones.

Entonces, mi pregunta es: ¿cómo se beneficia un probador de penetración al escribir tales exploits (o descargar uno de exploit-db) como un probador de penetración no como un desarrollador de exploits?

    
pregunta HSN 05.03.2016 - 14:51
fuente

2 respuestas

6

El cambio de direcciones en cada inicio se denomina aleatorización del diseño del espacio de direcciones (ASLR). Junto con Data Execution Prevention (DEP), ASLR es uno de los controles de seguridad más efectivos contra las vulnerabilidades de corrupción de memoria. Lea las excelentes respuestas en Cómo funcionan el DEP y el ASLR . Sin embargo, cuando se crean explotaciones de desbordamiento de búfer que se dirigen a cualquier cosa por encima de Windows XP (prácticamente todo en la actualidad), ASLR se pasa por alto utilizando algunas técnicas. La más común es transferir la ejecución del código a un módulo no habilitado para ASLR que se carga en una dirección fija o prevista. La mayoría de las explotaciones de IE que se dirigen a IE8 e IE9 utilizan uno de los dos módulos (MSVCR71.dll y HXDS.dll), ya que ambos no son ASLR y se cargan en el proceso de IE (ya sea de forma predeterminada o pueden activarse fácilmente) .

La mayoría de las explotaciones de flash utiliza una técnica en la que se sobrescribe la longitud de la matriz vectorial y se leen más datos de los previstos. Cuando el atacante puede leer datos de longitud arbitraria dentro de la memoria de proceso explotada, puede usarse para encontrar direcciones de DLL comunes a partir de las cuales se podrían construir los dispositivos ROP. Puede encontrar más detalles en el excelente artículo de Haifei Lei aquí . Si desea leer algún código que pueda omitir ASLR, eche un vistazo al código de explotación utilizado por Metasploit aquí .

En resumen, ASLR junto con DEP es una excelente mitigación. Sin embargo, existen técnicas para evitarlo en ciertos casos para una explotación confiable.

    
respondido por el void_in 05.03.2016 - 17:08
fuente
3

Está preguntando cómo Shellcode puede anular la aleatorización del diseño del espacio de direcciones, pero esto no queda claro de inmediato en la forma en que redactó su pregunta. El arte de la "Programación orientada al retorno" (ROP) ha evolucionado para enfrentar este desafío. El objetivo de ROP es asegurarse de que la dirección de retorno para cualquier ejecución de código sea para un espacio de direcciones que haya sido preaprobado para su ejecución, ya que se encuentra en el espacio de direcciones utilizado por uno o más módulos (o "gadgets" como se llaman en lenguaje ROP) que ya forma parte del programa original que se ha explotado o en una biblioteca que puede ser legítimamente llamada por el programa explotado. Si el programa inicial y las bibliotecas asociadas se ubican en una ubicación aleatoria, será necesario descubrir la ubicación aleatoria. Aquí, por ejemplo, hay métodos para omitir ALSR:

  • Dirigir módulos no ALSR. Algún software no está compilado para obedecer a ALSR y no lo respetaré. Muchos de los ataques a los complementos de navegador JRE6 se basaron en esto. fuente
  • Buscar la dirección inicial del ejecutable e inferir el resto. Por ejemplo, este hazaña de Adobe Reader encuentra la inicial dirección y utiliza la capacidad de manipular punteros y luego "leer el vtable" para Ubicaciones de memoria y así liberarse de la memoria codificada ubicaciones Es decir, puede confiar en ubicaciones de memoria relativas una vez esto esta hecho.
  

Al realizar el desarrollo de exploits, el proceso siempre se basa en la dirección de memoria de la máquina de la víctima.

Esa declaración inicial es incorrecta. No todos los exploits desarrollados para Metasploit o listados en exploit-db dependen de la capacidad de ejecutar shellcode. Tal vez solo estaba preguntando sobre estos tipos cuando mencionó un depurador, pero por si acaso, considere la siguiente vulnerabilidad de exploitdb:

enlace no hay ubicaciones de memoria involucradas. Metasploit utilizará una función de carga de archivos no autenticada para cargar un archivo JSP al que luego podrá conectarse y emitir comandos al sistema.

    
respondido por el mcgyver5 05.03.2016 - 20:40
fuente

Lea otras preguntas en las etiquetas