historia de los buffer overflows por juan sacco

Click here to load reader

Post on 18-Dec-2014

491 views

Category:

Technology

2 download

Embed Size (px)

DESCRIPTION

Quiza una de las vulnerabilidades de segurida mas tecnica, aterradora y clasica son los buffer overflows. Esta clase de vulnerabilidad se remonta hasta 1970 y su estatus llega hasta C y Unix. Luego de una decada de existencia, este tipo de vulnerabilidad esta resuelta? En la charla veremos su historia, ejempos y llegaremos hasta el 2013/4.

TRANSCRIPT

  • 1. Historia de los Buffer Overflows Autor: Juan Sacco ( runlvl )
  • 2. Comienzos.. Luego de algunas dcadas en existencia podemos ponerle punto final a los buffer overflows? La respuesta no es clara, los overflows son peligrosos, emocionantes y aterradores. Para responder, tenemos que entender que son.
  • 3. Si viviste debajo de una roca.. void main(void) { char buffer[256]; scanf("%s", buffer); /* Lee por E sin size */ } Ejemplo de buffer overflow de 1996!
  • 4. No es solo Scanf() Existen una lista interminable de funciones en ANSI C y otros lenguajes que llevan a una sobreescritura silenciosa del buffer. Ejemplos: Strcpy, Memcpy, Gets, Sprintf, etc.
  • 5. Contratemos programadores SR. Seguramente un programador experimentado podria evitar un desbordamiento (sick). La verdad es que no, y para ejemplos el mercado actual. La seguridad informtica es tabu, en el ambiente de desarrollo se premia la rapidez, la agilidad y la entrega por sprints.
  • 6. Ejemplo de Mysql 5.5.x Los desarrolladores de la DB Mysql son expertos, los usuarios miles de millones. Pero hace menos de 12 meses apareci un BoF remoto. Y ya estamos pisando el 2014! Mas de 40 aos de overflows demostraron: Es increblemente difcil no escribir overflows!
  • 7. Otro ejemplo y no jodemos mas! int main(int argc, char *argv[]) { char buffer[10]; strcpy(buffer, argv[1]); return 0; }
  • 8. Hey estamos en el 2013.. Claro, seguramente estars pensando: Deben existir algunas medidas de seguridad contra 40 aos de overflows. Por supuesto! Pero para entender como funcionan esas defensas debemos saber como es la estructura de un buffer.
  • 9. Desmitificando un overflow La sobreescritura comienza en el principio del buffer. Se sobreescribe hasta llegar al RA, y controlandolo ejecutamos codigo. Y as obtenemos Root :-)
  • 10. For fun and profit El bsico de la Era Aleph One es inyectar cdigo x86 directo al buffer y modificar el return address para que salte al cdigo inyectado. Tpicamente una System Call para spawnear una shell, es por eso que lo conocemos como shellcode. Ahhhh entonces era por eso? :-)
  • 11. Ejemplo de shellcode void main() { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); }
  • 12. Y como obtengo el cdigo x86? Un atacante debera compilar el cdigo, extraer el assembler y construirlo formateado para que se pueda ingresar dentro de una funcion. El programa vulnerable ya tiene su funcion!
  • 13. Estructura del exploit Voila! Obtuviste root de algunas mquinas! Excepto que ya no estamos en 1996..
  • 14. Historia de las defensas Una de las principales es DEP o Data Execution Prevention. Tambien conocida como W xor X. Nunca van a haber dos regiones de memoria desde donde se pueda a la vez ejecutar y escribir. El proceso va a crashear si el CPU intenta realizar una accin que active DEP.
  • 15. Deep in DEP.. Esta defensa est basada en la premisa de que el atacante inyecta cdigo, osea la shellcode! Por lo tanto nunca, jams debera ser posible tomar control de un programa.. Bueno, no exactamente.. ;-)
  • 16. ROP! Return Oriented Programming Un atacante en vez de inyectar el cdigo que quiere ejecutar, puede simplemente encadenar retornos de jumps y reutilizar el cdigo ya existente. El target ms comn de ROP suele ser: La librera C ( libc ) y el cdigo del programa.
  • 17. Estructura de ROP
  • 18. Deep in ROP Las cosas se ponen ms complicadas cuando empezamos a trabajar con ARM y x86-64, ya que los argumentos se pasan en los registros, pero aun as es posible. TIP: Estamos en assembler as que podemos saltar en el medio de una funcion si queremos!
  • 19. ASLR: Address Space Layout Rand.. Para mitigar ROP apareci ASLR donde se randomiza el stack, heap y libreras dinmicas. Ahora ya no se puede saltar porque todas las direcciones cambian en cada ejecucin. Suena genial no? La solucin definitiva.. ?
  • 20. Un poco de ASLR Bueno existen problemas.. Para empezar la seccin .text no es randomizada. En Linux se puede saltar a cualquier funcin de la lib C utilizada por el programa mediante la PLT ( Procedure Link Table ) PLT es una tabla que mapea justamente.
  • 21. Deep in ASLR Ya no suena tan genial no? Bueno hay mas. Brute force: El page size en x86-32 es de 4kb, los 12 bits de una direccion de memoria. Otros 8 bits son reservados para regiones especiales. Son solo 4096 posibilidades.. No tan ASLR no?
  • 22. Pero hay mas y llego Stack Guard Canarios, en una mina de carbn se usaban para saber si el nivel de monxido de carbono era habitable. Esta defensa usa el mismo principio dejando un valor random o null antes del return address. Si el canario se modific.. laejecucin para.
  • 23. Estructura de buffer con canario
  • 24. Creo que he visto a un lindo gatito.. Para evitar al canario tenemos que salvarlo, no se lo tiremos al gato! Ejemplo:
  • 25. Deep in Stack Guard Con esa estructura se podria modificar SRC y DST durante el overflow. Lo que se debera hacer es restaurar el valor del canario. Apuntar &[dest] al address del canario y luego restaurarlo, por ejemplo: dest[255] = 0
  • 26. Y que se viene? Durante 1990s y 2000s se conectaron a internet por primera vez las PCs y el furor de los overflows exploto! Ya nada era seguro, cualquier desarrollador en manos de un 0day poda ser potencialmente muy peligroso! Y divertirse mucho.. ;)
  • 27. Enserio, cual es el futuro? Los dispositivos embebidos, cameras Go Pro!, routers, autos, heladeras, dispositivo de conexin remota (IPMI). Pero si existen lenguajes como D, Go, Rust, etc? Cual es el problema entonces..
  • 28. La cultura. El desarrollo gil, la velocidad de entrega y el desconocimiento son las principales causas. No existe un paso a paso, se debe capacitar al personal, tomar medidas y analizar. Esto se traduce en costos.. Billetera mata.. ?
  • 29. !!!Gracias!!!

View more