¿Cómo funciona el hecho de obtener una shell remota mediante la explotación de una vulnerabilidad realmente funciona?

Navega tus respuestas
7

Puedo entender qué es un desbordamiento de búfer y que te permite escribir en lugares de la memoria que no deberías poder. También puedo entender el concepto de que puede haber otras vulnerabilidades de software que funcionen de alguna manera diferente que te permita colocar las cosas que deseas en la memoria. También obtuve acceso a algunas de mis antiguas máquinas XP usando metasploit, lo cual fue divertido.

Pero realmente no puedo entender cómo puede obtener acceso al sistema remoto teniendo en cuenta (por ejemplo) la vulnerabilidad de desbordamiento de búfer.

Hay algunos puntos que no están claros para mí:

  1. ¿Es necesario que el programa que tiene la vulnerabilidad se ejecute y escuche un puerto específico en la máquina víctima (como un mini servidor o algo así)? ¿Puede un programa mal escrito ser explotado de forma remota si no escucha un puerto?
  2. Supongo que el programa leerá alguna entrada de ese puerto y luego la escribirá en la memoria en alguna variable y tal vez la procese. Al proporcionar al programa más datos de los que debería leer, y siempre que tenga la vulnerabilidad, escribirá en una ubicación en la memoria (específicamente, exactamente después de la variable) lo que queramos. ¿Cómo no falla esto el programa el 99.9% del tiempo? ¿Qué sucede si exactamente después del lugar en la memoria donde se almacena esta variable hay un puntero a alguna función que no se ejecuta y el programa se bloquea?
  3. Siempre que el programa no se bloquee, ¿cómo podemos ejecutar el código que hemos inyectado en la memoria? ¿Necesitamos colocar el código que queremos en un lugar dentro de la memoria que sabemos que se va a ejecutar? ¿Cómo se puede ejecutar alguna parte aleatoria de la memoria? Casi nunca en mis programas ejecuto alguna variable mía, a menos que quiera ejecutar algún otro programa, lo cual es muy raro y no debería ser lo mismo que ejecutar código directamente desde la memoria (que me recuerda a eval ()).
  4. Siempre que el punto 2 asuma correctamente que la vulnerabilidad generalmente surge cuando el programa vulnerable lee información maliciosa de un puerto y este código se ejecuta, ¿cómo puede el código ejecutado volver a llamarme, el atacante? ¿Envío el código malicioso de mi dirección IP en una variable o algo así?
  5. Los programas generalmente no pueden leer ni escribir en la memoria de otro programa. ¿Esto significa que cuando se cierre el programa vulnerable perderé la conexión con el shell remoto abierto? ¿O genera un subproceso independiente una vez que se ejecuta y realmente estoy conectado a él?

¿Alguien puede darme un ejemplo simple pero realista y completo de cómo funciona todo el sistema, desde el programa escuchando a algún puerto hasta que el atacante obtiene una concha?

    
pregunta hytromo 23.05.2015 - 00:00
fuente

2 respuestas

7

  1. Los programas vulnerables necesitan escuchar los puertos para poder acceder a ellos a través de la red directamente. Sin embargo, podría obtener acceso al sistema a través de otros medios y luego explotar un programa vulnerable que no tiene acceso a la red (por ejemplo, un malware de correo electrónico que provoca una vulnerabilidad en un lector de PDF)

  2. Saber cómo se comporta predeciblemente el programa vulnerable es la clave para encontrar y explotar vulnerabilidades. En resumen, debes saber qué sucederá en la pila antes de enviar el exploit. Por eso, al igual que toda la programación: pruebas, pruebas, pruebas.

  3. Si entiendes BO, entonces sabes que escribes en la pila en un lugar donde el puntero dirigirá la ejecución. Así es como podemos ejecutar nuestro código.

  4. Al igual que en mi número 1, el programa vulnerable no necesita ser un servicio de red que se ejecute en un puerto. Si desea un 'shell inverso', entonces el código del shell debe incluir el código de red requerido para conectarse nuevamente con usted.

  5. Sí, y sí. Si no migra a otro proceso (ya sea incrustado en un proceso en ejecución o un proceso nuevo desencadenado por su código), una vez que finaliza el programa vulnerable, también lo hace su conexión. Entonces, migran.

Mi respuesta es una vista MUY simplista de sus preguntas. Hay mucho que puede hacer para profundizar en lo que he proporcionado, e incluso las técnicas que van a contradecir lo que he dicho, pero estos son los conceptos básicos.

Escenario simplista:

Un servidor FTP vulnerable se está ejecutando en un puerto. Descubres que un determinado comando FTP no está correctamente restringido, por lo que es posible enviar argumentos de comando demasiado grandes y escribir en partes de la pila a la que accede el servidor FTP. Usted diseña un código (incluidas las funciones de red) que puede encajar en el espacio de pila ocupado por el programa FTP. Luego, se conecta al servidor FTP y envía el comando con su código de shell como la carga útil. Cuando el servidor FTP procesa el comando, golpea su código y procesa la carga útil. Su shellcode se ejecuta y crea una conexión de red de nuevo a su máquina.

    
respondido por el schroeder 23.05.2015 - 00:23
fuente
3

El desbordamiento de búfer permite que un atacante sobrescriba las direcciones almacenadas en la pila que utiliza la aplicación cuando regresa de una función. Una vez que el atacante controla esta dirección, puede desviar la ejecución del programa volviendo a una parte diferente de la aplicación o las bibliotecas que utiliza.

En su forma más simple, el atacante puede escribir código de shell en la pila más allá de la sobrescritura de la dirección y establecerá la dirección de retorno en una instrucción jmp esp que apuntará a la pila y ejecutará los datos en la pila como código.

El código de shell puede realizar una conexión de salida o escuchar en un puerto.

El término Explotación remota se aplica a menudo a programas sin demonio, como un navegador o un correo electrónico a alguien, un archivo que explota una vulnerabilidad en el programa de apertura, es decir, un archivo PDF.

    
respondido por el wireghoul 23.05.2015 - 00:25
fuente

Lea otras preguntas en las etiquetas

¿Debería compartirse un certificado de comodín ssl con una organización diferente que alberga un subdominio? ¿El secreto hacia adelante perfecto (PFS) hace que los ataques Man-in-the-Middle (MitM) sean más difíciles?