Articulo de referencia

Programación orientada al retorno a ciegas

La programación orientada a retorno ciega ( BROP ) es una técnica de explotación que puede crear una vulnerabilidad incluso si el atacante no posee el binario objetivo. Los ataq...

La programación orientada a retorno ciega ( BROP ) es una técnica de explotación que puede crear una vulnerabilidad incluso si el atacante no posee el binario objetivo. Los ataques BROP demostrados por Bittau et al. han logrado burlar la aleatorización del espacio de direcciones (ASLR) y los canarios de pila en sistemas de 64 bits.

Fondo

Gracias a las mejoras actuales en la seguridad de los sistemas operativos y el hardware, y a funciones de seguridad como el proyecto Linux PaX , la inyección de código es ahora imposible. Los investigadores de seguridad idearon entonces un nuevo ataque, denominado programación orientada a retorno ( ROP) , para eludir la memoria NX (no ejecutable). Este ataque se basa en afectar el flujo del programa controlando la pila, especialmente las direcciones de retorno. Los gadgets son las unidades fundamentales de este ataque. Un gadget es un grupo de secuencias de instrucciones que terminan en una instrucción de retorno, junto con un estado determinado de la pila. Un gadget puede realizar una operación como cargar una palabra de la memoria en un registro, o una operación más compleja como un salto condicional. Con un binario objetivo suficientemente grande, se puede construir una colección Turing-completa de gadgets, más que suficiente para ejecutar un shellcode . Una de las premisas de la ROP es que el atacante posee los binarios objetivo y, por lo tanto, conoce de antemano las direcciones de los gadgets.

Escenarios para BROP

Hay tres nuevos escenarios para los que BROP [ 1 ] puede ser relevante. Son los siguientes:

  1. En el caso de servicios binarios cerrados, para descubrir vulnerabilidades es necesario utilizar técnicas como el fuzzing y las pruebas de penetración.
  2. Una vulnerabilidad conocida en una biblioteca de código abierto puede aprovecharse para llevar a cabo un exploit, incluso si el binario propietario que la utiliza es de código cerrado.
  3. También puede utilizarse para piratear un servidor de código abierto cuyo archivo binario se desconoce.

El ataque parte de la base de que existe un servicio en el servidor que tiene una vulnerabilidad de pila conocida y que, además, dicho servicio debería reiniciarse en caso de fallo.

Fases del ataque

Lectura de pilas

Los punteros de instrucción de retorno suelen estar protegidos por canarios de pila . Un canario de pila provoca que el programa falle si su valor se modifica por un desbordamiento de búfer. En el modelo de ataque BROP, el desbordamiento de búfer se propaga byte a byte. Cada intento de desbordamiento resulta en un fallo del programa o en la continuación de la ejecución. Un fallo del programa implica que el valor de la pila se estimó incorrectamente; por lo tanto, en 256 intentos (el caso promedio es de 128 intentos), es probable que se pueda estimar el valor de la pila. En máquinas de 64 bits, se requerirían 4 lecturas de pila de este tipo para filtrar el canario. Una vez filtrado el canario, el puntero de instrucción de retorno puede ser perturbado de la misma manera. Sin embargo, cabe señalar que, si bien la estimación del canario de pila es exacta, no se puede decir lo mismo de la dirección de la instrucción de retorno. El atacante se conformaría con filtrar cualquier dirección dentro del segmento de texto del espacio de direcciones.

ROP ciego

Esta etapa es el núcleo del ataque. El objetivo en esta fase es iniciar una llamada al sistema `write` , enviando un volcado del binario al atacante. La llamada al sistema `write` tiene tres parámetros: socket, buffer y length. Dado que las convenciones de llamada de x86-64 requieren que los parámetros se pasen a través de registros, se necesitarían instrucciones `pop` apropiadas en `rsi`, `rdi` y `rdx` para configurar los argumentos de la llamada al sistema `write`. Secuencias de instrucciones como `pop rdi`, `ret` y similares serían útiles en este sentido. Una versión ROP simple de la llamada al sistema `write` sería:

  1. pop rdi; ret (socket)
  2. pop rsi; ret (buffer)
  3. pop rdx; ret (length)
  4. pop rax; ret (write syscall number)
  5. syscall

Un problema de esta metodología es que, incluso si se encuentran dispositivos útiles en el espacio de direcciones, después de que devuelvan la dirección en la pila, es muy probable que la pila no sea ejecutable. Para solucionar esto, los proponentes de BROP concibieron los dispositivos de parada. Un dispositivo de parada es cualquier cosa que provoque que el programa se bloquee, como un bucle infinito o una llamada al sistema que lo bloquee (como sleep). Esto funciona provocando que los procesadores afectados por el ataque queden atrapados en un bucle infinito, lo que permite al atacante continuar con el ataque.

Lo descrito anteriormente es la metodología básica del ataque. En realidad, se pueden realizar algunas optimizaciones que ayudan a ejecutarlo de manera eficiente. La principal es el uso de tablas de enlace de procedimientos (PLT) para rastrear la llamada al sistema de escritura en lugar de pasar el número de llamada al sistema a la función syscall. Otras optimizaciones incluyen el uso de strcmp para llenar el registro RDX, ya que las secuencias de instrucciones pop RDX, ret son extremadamente raras.

Construye el exploit

Una vez que se encuentra la escritura en el PLT, el atacante puede volcar el contenido del binario objetivo para encontrar más gadgets. El atacante puede usar técnicas convencionales de búsqueda de gadgets ROP para recopilar suficientes y crear un shellcode. Una vez que tiene el shellcode, puede tomar el control total del sistema explotado con acceso de root.

Prevención

Una suposición fundamental en el ataque BROP es que el servidor se reinicia tras cada fallo y que, al reiniciarse, no vuelve a generar aleatoriamente su espacio de direcciones. Por lo tanto, habilitar la generación aleatoria de direcciones al inicio puede proporcionar una protección casi completa contra BROP. Otra técnica utilizada por NetBSD y Linux es la suspensión del sistema tras el fallo. Esto ralentiza considerablemente el ataque y permite al administrador del sistema investigar cualquier actividad sospechosa. Además, la protección convencional contra los ataques de secuestro de flujo de control de tipo ROP, la Integridad del Flujo de Control, también puede proporcionar una prevención demostrable, aunque con una sobrecarga de rendimiento significativa.

Ataques similares

Otro ataque similar a BROP es JIT (Just-In-Time)-ROP, o JIT-ROP. También se basa en la divulgación de información, lo que permite eludir la aleatorización del espacio de direcciones . Tanto BROP como JIT-ROP intentan localizar gadgets en el binario para iniciar un ataque ROP, cuyo objetivo es explotar algún tipo de fuga de datos. Sin embargo, a diferencia de BROP, JIT-ROP no es un ataque interactivo que se adapte a situaciones de fallo o no fallo, sino que el atacante envía un script que descubre los gadgets y posteriormente crea un ataque para su ejecución. Además, JIT-ROP requiere conocer de antemano dos vulnerabilidades diferentes (una en el montón y otra en la pila), mientras que BROP solo requiere conocer una vulnerabilidad en la pila. [ 2 ]

Referencias

  1. "Programación Orientada a Retorno Ciego (BROP)" . Grupo de Sistemas Informáticos Seguros de Stanford . Consultado el 24 de febrero de 2016 .
  2. Keener, Lawrence (diciembre de 2015). "Evaluación de la generalidad y los límites de los ataques de programación orientada a retorno ciego" (PDF) . Calhoun: Archivo Institucional del NPS : 26. Recuperado el 28 de febrero de 2016 .
  • Hacking Blind , Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazieres, Dan Boneh
  • Programación orientada al retorno , Hovav Shacham et al.
  • http://www.scs.stanford.edu/brop/
  • http://www.scs.stanford.edu/brop/bittau-brop.pdf
  • Título del artículo
Obtenido de " https://en.wikipedia.org/w/index.php?title=Blind_return-oriented_programming&oldid=1335282244 "