Autor
Este es mi primer post, y me ha costado mucho encontrar un foro de "hacking" donde haya un poco de calidad, al fin lo conseguí, parece ser que aki hay gente con nivel...
En muchos foros de juankers, en el hilo de exploits, veo que los posts que mas abundan són, como compilo un exploit, que es un exploit y me muero por ser hacker...
No es por nada pero mis inquietudes van mas allá, se acabó la presentación.
Tras estar 5 días en calma y trankilidad en mi casa de campo, solo yo, mi computer y mi piano, empiezo la semana con una inquietud tremenda....
Llevo 4 dias dale que te pego con el metodo de explotación de buffer overflow, "Return into libc".
En teoría no tiene muxa complicación, segun los papers de internet, el que mas me ayudó fue el de phrak y enyesecurity, este último para 64Bits.
Que pasa entonces, cual es el problema..?
Pues que las cosas cambiaron muxo desde entonces, y "ninguno" de los que encontré está actualizado, no chutan.
Eso si me ayudaron a entender la tecnica y a "medio" implementarla en un Poc.
Por si alguien se vuelve medio loco provando técnicas y tal y tal, enumeraré los cambios que hacen que este método actuálmente sea muy dificil de ejecutar.
1-Para sacar los offsets de por ejemplo system, antes con "gdb p system" ya la teníamos, con PLT (dynamic addr) se acabó lo que se daba, a partir de ahora solo podremos saltar a las funciones que importa el binario en cuestión.
2-Mas de lo mismo, si antes se podian encontrar las direcciones de memoria de las variables de entorno vease SHELL=/bin/sh, pues ahora tambien pero con la dirección aleatoria.....getenv("SHELL") ya no chuta.
3-Para qué system("/bin/sh")? si podemos copiar nuestra shellcode con mmap y luego retornar a ella, pues aki el problema se plantea cuando vemos que con los linux de ahora.....el ESP es dinámico tambien, o sea que no hay manera de determinar el FRAME(segun PHRAK) y no podemos saber el offset de nuesto shellcode para copiarlo con mmap.
4-Pues calculemos el offset de ESP------SHELLCODE, tampoco siempre es aleatorio, y por fuerza bruta lo veo inviable.
Mmmm la cosa esta dificil y solo queda recurrir a un CALL ESP o JMP ESP cosa que implica el estudio del binario en cuestion
y no deja de ser un stack overflow.Por lo tanto replanteo mis dudas:
1-Es possible hacer un "return into libc" actualmente y con exito en x86, o hay que ir saltando por el binario hasta conseguir retornar al stack?
2-De que manera se puede localizar el offset de la shellcode una vez en ejecuión?
Estas preguntas son muy genéricas, y que mejor para responderlas...que un ejemplo de codigo vulnerable, para que a la vez sirvan de reto para los mas inquietos..
-----code bof1.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void basura(void) {
system(NULL);
}
void f1(char *argv[])
{
char buf[1024];
strcpy(buf, argv[1]); /* OVERFLOW */
}
int main(int argc, char *argv[])
{
char *p;//="/bin/sh;#";
p=malloc(1024);
f1(argv);
return(0);
}
-----fin_code
gcc -ggdb bof1.c -o bof1
Por supuesto decir que NO vale un retorno al stack, a no ser que se utilicen saltos del propio binario, o saltos de alguna funcion de libc.
Y para los que esten comenzando, el mismo codigo pero con una ayudita para que sea mas facil....
----code bof2.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
void basura(void) {
system(NULL);
}
void f1(char *argv[])
{
char buf[1024];
strcpy(buf, argv[1]); /* OVERFLOW */
}
int main(int argc, char *argv[])
{
char *p;//="/bin/sh;#";
p=malloc(1024);
f1(argv);
__asm__ ( "mov %esp, %eax\n\t"
"call *%eax\n\t");
__asm__("mov (%esp), %ebp\n\t"
" call *%ebp\n\t");
exit(0);
return(0);
}
---fin code
)
Espero vuestra colaboración, y al final del reto presentar las técnicas aplicadas.
Yo por mi parte tengo un tutorial de como explotarlo con ayudas varias y uso de gdb, aunque tengo que decir, que debo completarlo con el que resuelva el reto, o sea que el reto tambien es mio.
Gracias a totus por la colaboración.
En línea
. A ver, el reto es explotar esos codigos en linux, pero en que linux?; x86 con randomize (ASLR) activado?, x86 sin randomize?, x86 con PaX (stack no ejecutable para que nos entendamos)?, x86_64?...
xaxi piruli nos saltamos todas las protecciones, lastima que esto solo funcione localmente.
