Cómo escribir/modificar exploit RCE sin conocer el SO de la víctima?

Iniciado por Ethicalsk, 2 Noviembre 2016, 04:09 AM

0 Miembros y 1 Visitante están viendo este tema.

Ethicalsk

Muy buenas! No estoy muy experimentado en el asunto, y supongo que algunos de ustedes si. Estuve leyendo y descubrí que para explotar vulnerabilidades en servicios desactualizados es muy importante conocer la version del SO que corre sobre la PC con el servicio vulnerable, ya que si el bug es del tipo stack, heap overflow, o algún otro, es necesario saber datos puntuales del SO, como la direccion de retorno de determinada librería, etc. Muchas veces nmap nos da buena información sobre el SO, pero a veces no puede saber con certeza, o puede dar falsos positivos. En esos casos qué decisión se supone que tome el atacante? Porque si llega a usar un payload equivocado puede llegar a sobreescribir el EIP/RIP, y que apunte a una dirección inexistente o prohibida, generando un segmentation fault, y por ende un DoS en el servicio, dejandolo sin funcionamiento hasta que se vuelva a ejecutar...

La idea que yo más o menos tengo sobre el proceso de explotación sería el siguiente (siempre teniendo en cuenta el punto de vista del atacante):
1) Descubrir las versiones de los servicios y del SO que corre en la víctima.
2) Buscar exploits para los servicios que corren.
3) Si se encuentran exploits para dichos servicios pero no tienen soporte para la versión del SO de la víctima habría que hacer ciertas modificaciones, para eso sería necesario descargar un .iso del mismo sistema operativo que tenga la víctima, correrlo sobre una VM, instalarle la misma version del servicio que la víctima tenga, y luego a través de un debbuger/desensamblador, extraer los datos valiosos sobre direcciones de memoria y esas cosas para reemplazarlas en el exploit que encontramos. En caso que no se encuentren exploits, igualmente necesitamos el .iso y el servicio que corre, y debbuguearlo para ponerlo a prueba y tratar de encontrar un 0 day.
4) Correr el exploit original/modificado/0day para obtener una shell inversa.
5) Si no se obtiene una shell con privilegios, habría que escalarlos.
6) Una vez obtenido los privilegios es hora de borrar logs y dejar backdoors para mantener el acceso.

Pero... Si el atacante no sabe con certeza el SO de la víctima, como puede planificar correctamente un ataque? Esa es mi gran duda...

.:UND3R:.

Lo que se hace generalmente es tratar de saber más menos el sistema operativo, o sea entiendo que estás preguntando por el caso en donde se desconoce, pero esto en la vida real que tan factible es? Por lo menos puedes deducir si usa Windows o Linux y ya tener un rango de posibilidades por así decirlo, de todas formas pues claro se dará la posibilidad de que el exploit falle, en tal caso, se utiliza una especie de fuerza bruta, esta tiene mayor eficacia cuando el servicio cuenta con buenas manejadores de excepciones SEH, lo cual impiden el cierre del proceso.

Un caso puntual es un desbordamiento de pila en donde la cantidad de bytes a sobre-escribir dependen del nombre de usuario, en tal caso tienes un rango (el menor dígito permitido para un nombre de usuario y el máximo). Por otro lado están las direcciones estáticas, afortunadamente hay ROP Gadgets genéricos por así decirlo que son compatibles para varios sistemas operativos, por lo cual esto te podría ayudar. No sé si se entiende mi idea, si no tienes el objetivo exacto puedes usar rangos de posibilidades para así ir descartando vías. Otro ejemplo sería la versión X de un servicio, si vez la documentación que no es compatible con Windows 7 en adelante ya podrías intentar montar un escenario en XP, SP2, SP3 ENG/ESP pero si sabes que es un objetivo que habla en ingles ya sabes que es SP2, SP3 ENG ahora si sabes que hay un ROP genérico para ambos SP ya podrías atacar al objetivo.

En resumen es similar a realizar un exploit, debes ingeniártelas por ti, probar variantes, etc. No necesariamente el fallo se basará en el mismo exploit, es posible que en base a fingerprinting logres obtener el SO.

Por favor indícame si te convence la respuesta, saludos.

Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)

Ethicalsk

Quedé convencidicimo UND3R !!!  ;-) Respuestas como la tuya son las que me ayudan mucho a aprender, a abrirme la cabeza y me sirven como fuente para saber sobre que investigar... Por ejemplo SEH me sonaba de nombre pero nunca investigué muy bien que era... Y ahora que me lo decís me doy cuenta como es que a veces el proceso finaliza y a veces no. De ROP había leído un pdf muy interesante, y la existencia de ROP en si la descubrí gracias a otra respuesta como la tuya. Debería seguir experimentando con las cadenas y seguir leyendo los manuales de ingenieria inversa de Ricardo Narvaja que me recomendaron y deje en stand-by... Y bueno, eso... Te agradezco mucho por la ayuda y por tu tiempo! Saludos!