Mensajes

Un poquito de documentación por la red, no? He estado buscando y no hay nada publicado al respecto...

Has encontrado publicado por ahi q ese coche es vulnerable al "car whisperer" explicitamente o eso lo has deducido tu?

[¿y para que qué puede servir esto de conocer el tipo de dispositivo?]

Alguien puede estar pensando... ¿y para que qué puede servir esto de conocer el tipo de dispositivo?

Surgen algunas aplicaciones prácticas:

1) Permite obtener información más detallada sobre el dispositivo detectado.
Ya sabemos que pocas veces el nombre del dispositivo Bluetooth permite identificarlo, ya que este puede ser personalizado por el usuario. Asimismo, la dirección MAC nos permite conocer el fabricante del chipset, pero eso no acota las posibilidades; por ejemplo: Dell fabrica PCs de sobremesa, laptops, PDAs, etc.
Gracias al campo Device Class (suponiendo que este no haya sido falseado), podemos conocer de primera mano el dispositivo remoto con el que nos enfrentamos.

2) Permite realizar escaneos de víctimas filtrando los dispositivos que no nos interesan.
Si , por ejemplo, estamos interesados en llevar a cabo un ataque Bluebug, sólo nos sirven teléfonos móviles y el resto de dispositivos son descartables. En base al campo Device Class podemos filtrar los contenidos de hci_inquiry obteniendo únicamente los dispositivos que cumplan tener un dev_class correspondiente a un dispositivo 'Cellular'.
Puede que a priori no importe contar con dispositivos no vulnerables a Bluebug, pero si estamos realizando un ataque masivo en un ambiente con muchos dispositivos Bluetooth a nuestro alrededor se agradece disponer de la información lo menos viciada posible.

3) Engañar aquellos dispositivos que sólo permiten el emparejamiento con aquellos que cumplen un determinado tipo específico (o genérico) de Device Class.
Por ejemplo, algunos Manos libres están diseñados de forma que sólo es posible emparejarse desde un teléfono móvil y rechazan paquetes con origen otros dispositivos con el campo Device Class no admitido por defecto (por ejemplo, un PC).
Sabiendo como funcionan los DIACs (The General- and Device-Specific Inquiry Access Codes), podemos configurar nuestro equipo atacante falseando el campo Device Class y suplantando la identidad de un teléfono móvil. De esta forma, podemos ser capaces de conectarnos a ese dispositivo Manos libres y explotar vulnerabilidades (véase Car Whisperer).

Son sólo algunas ventajas...

[Ejercicio práctico: Identificando un dispositivo a partir de su campo Class of Device/Service]

Ejercicio práctico: Identificando un dispositivo a partir de su campo Class of Device/Service

Disponemos de la siguiente información:


Hemos detectado un dispositivo con la dirección MAC 00:60:57:D0:F9:15 y el campo class 0x500204.

1) Traducimos el campo class a formato binario

0x500204 es 010100000000001000000100 en binario.

2) Descomponemos el string binario en los 3 subcampos en los que se organiza el campo Class of Device/Service

La descomposición la hacemos en formato little indian, con el bit más significativo a la izquierda.
Recordamos la organización de los subcampos:

- 11 últimos bits reservados para las Service Classes.
- 11 siguientes bits reservados para las Device Classes.
       - 6 últimos bits reservados para las Major Device Classes.
       - 5 siguientes bits reservados para las Minor Device Classes.
- 2 primeros bits para el campo Format Type, por defecto a 0.

23 22 21 20 19 18 17 16 15 14 13 | 12 11 10 09 08 07 | 06 05 04 03 02 |  01 00
0   1   0   1   0   0   0   0   0   0   0  |  0   0   0   1   0   0  |  0   0   0   0   1  |   0   0

3) Analizamos la representación de los bits marcados en el string binario para extraer la información sobre servicios y naturaleza del dispositivo.
Nos apoyamos en las tablas relacionales.

- Major Service classes:
23 22 21 20 19 18 17 16 15 14 13
0   1   0   1   0   0   0   0   0   0   0   

El campo tiene marcado los siguientes bits:
- 22, correspondiente a Telephony (Cordless telephony, Modem, Headset service, ...)
- 20, correspondiente a Object Transfer (v-Inbox, v-Folder, ...)

- Major Device classes:
12 11 10 09 08
0   0   0   1   0

La representación de los bits marcados en este campo indica que el dispositivo se trata del siguiente tipo genérico:
  0  0  0  1  0 | Phone (cellular, cordless, payphone, modem, ...)

- Minor Device classes:
07 06 05 04 03
0   0   0   0   1

La representación de los bits marcados indica que el dispositivo se trata del siguiente tipo específico (dentro del tipo genérico 'Phone'):
0  0  0  0  0  1 | Cellular

4) Extraemos conclusiones.

Parece obvio que el dispositivo analizado se trata de un Teléfono móvil. En este caso, se trataba de un modelo Nokia NGage.


Extra) Propongo dos ejercicios adicionales para coger práctica:

1. Dada la class 0x140680, demostrar que el dispositivo analizado se trata de una impresora (grupo Imaging) con los siguientes servicios soportados: Rendering y Object Transfer

2. Dada la class 0x320114, demostrar que el dispositivo analizado se trata de una PDA (grupo Computer) con los siguientes servicios soportados: Networking, Object Transfer y Audio.

[Descargar el artículo en formato pdf:]

Descargar el artículo en formato pdf:
http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/Files/Identificacion.Dispositivos.Bluetooth.pdf

1. Introducción

Cuando realizamos algún escaneo de dispositivos Bluetooth con ayuda de herramientas comerciales o, mismamente, con el asistente  de conexiones Bluetooth de Windows, observamos que los dispositivos detectados son mostrados mediante iconos representativos de su naturaleza, ya sean PCs, PDAs, Teléfonos móviles, Manos libres, etc.

Nos preguntamos, ¿cómo será posible conocer el tipo de dispositivo del que se trata? La respuesta es: a través de los DIACs (The General- and Device-Specific Inquiry Access Codes)

2. Class of Device/Service

Cada dispositivo Bluetooth incorpora en la cabecera de nivel de Banda Base (Baseband 1.1) de sus paquetes un campo Class of Device/Service. Este campo se compone de 3 octetos organizados con el siguiente formato (en little endian):
- 11 últimos bits reservados para las Service Classes.
- 11 siguientes bits reservados para las Device Classes.
       - 6 últimos bits reservados para las Major Device Classes.
       - 5 siguientes bits reservados para las Minor Device Classes.
- 2 primeros bits para el campo Format Type, por defecto a 0.

El siguiente esquema resume lo explicado:


Con el fin de poder obtener información del campo Class of Device/Service, los 3 octetos se traducen a un string binario de 24 bits cuya ordenación de 1s y 0s permite identificar los servicios ofrecidos por el dispositivo, así como la naturaleza del mismo.

3. Service Classes (Clases de servicios)

El campo reservado para las Service Classes permite identificar los servicios soportados por el dispositivo. Este campo se compone de 11 bits, del 13 al 23. Cada servicio Bluetooth está asociado a un bit en concreto, de forma que si un determinado bit del campo está a 1, entonces el dispositivo soporta ese servicio Bluetooth. La correspondencia entre nº de bit y servicio se recoge en la siguiente tabla:

Bit | Major Service Class
13 | Limited Discoverable Mode [Ref #1]
14 | (reserved)
15 | (reserved)
16 | Positioning (Location identification)
17 | Networking (LAN, Ad hoc, ...)
18 | Rendering (Printing, Speaker, ...)
19 | Capturing (Scanner, Microphone, ...)
20 | Object Transfer (v-Inbox, v-Folder, ...)
21 | Audio (Speaker, Microphone, Headset service, ...)
22 | Telephony (Cordless telephony, Modem, Headset service, ...)
23 | Information (WEB-server, WAP-server, ...)

4. Device Classes (Clases de Dispositivos)

El campo reservado para las Device Classes permite identificar la naturaleza del dispositivo. Este campo se compone 2 subcampos: Major Device Classes y Minor Device Classes

4.1 Major Device Classes

El campo reservado para las Major Device Classes permite identificar el tipo genérico de dispositivo. Este campo se compone de 5 bits, del 8 al 12. Cada tipo genérico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos genéricos de dispositivos se recoge en la siguiente tabla:

12 11 10 9 8 | Major Device Class
 0  0  0  0  0 | Miscellaneous
 0  0  0  0  1 | Computer (desktop,notebook, PDA, organizers, .... )
 0  0  0  1  0 | Phone (cellular, cordless, payphone, modem, ...)
 0  0  0  1  1 | LAN /Network Access point
 0  0  1  0  0 | Audio/Video (headset,speaker,stereo, video display, ...)
 0  0  1  0  1 | Peripheral (mouse, joystick, keyboards, ...)
 0  0  1  1  0 | Imaging (printing, scanner, camera, display, ...)
 0  0  1  1  1 | Wearable (complemento que puedes llevar puesto)
 0  1  0  0  0 | Toy (Juguete)
 1  1  1  1  1 | Uncategorized, specific device code not specified
X  X  X  X  X | All other values reserved

4.2 Minor Device Classes

El campo reservado para las Minor Device Classes permite identificar el tipo específico de dispositivo. Este campo se compone de 6 bits, del 7 al 2. Cada tipo específico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos específicos de dispositivos, dentro de cada tipo genérico, se recoge en la siguientes tablas:

Computer Major Class

7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Desktop workstation
0  0  0  0  1  0 | Server-class computer
0  0  0  0  1  1 | Laptop
0  0  0  1  0  0 | Handheld PC/PDA (clam shell)
0  0  0  1  0  1 | Palm sized PC/PDA
0  0  0  1  1  0 | Wearable computer (Watch sized)
X  X  X  X  X  X | All other values reserved

Phone Major Class

7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Cellular
0  0  0  0  1  0 | Cordless
0  0  0  0  1  1 | Smart phone
0  0  0  1  0  0 | Wired modem or voice gateway
0  0  0  1  0  1 | Common ISDN Access
X  X  X  X  X  X | All other values reserved

Audio/Video Major Class

7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Wearable Headset Device
0  0  0  0  1  0 | Hands-free Device
0  0  0  0  1  1 | (Reserved)
0  0  0  1  0  0 | Microphone
0  0  0  1  0  1 | Loudspeaker
0  0  0  1  1  0 | Headphones
0  0  0  1  1  1 | Portable Audio
0  0  1  0  0  0 | Car audio
0  0  1  0  0  1 | Set-top box
0  0  1  0  1  0 | HiFi Audio Device
0  0  1  0  1  1 | VCR
0  0  1  1  0  0 | Video Camera
0  0  1  1  0  1 | Camcorder
0  0  1  1  1  0 | Video Monitor
0  0  1  1  1  1 | Video Display and Loudspeaker
0  1  0  0  0  0 | Video Conferencing
0  1  0  0  0  1 | (Reserved)
0  1  0  0  1  0 | Gaming/Toy
X  X  X  X  X  X | All other values reserved

Peripheral Major Class

7  6 | Minor Device Class
0  0 | Other (Joystick, Gamepad, Remote control, ...)
0  1 | Keyboard
1  0 | Pointing device
1  1 | Combo keyboard/pointing device

Imaging Major Class

7  6  5  4 | Minor Device Class
X  X  X  1 | Display
X  X  1  X | Camera
X  1  X  X | Scanner
1  X  X  X | Printer
X  X  X  X | All other values reserved

Wereable Major Class

7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Wrist Watch
0  0  0  0  1  0 | Pager
0  0  0  0  1  1 | Jacket
0  0  0  1  0  0 | Helmet
0  0  0  1  0  1 | Glasses
X  X  X  X  X  X | All other values reserved

Toy Major Class

7  6  5  4  3  2 | Minor Device Class
0  0  0  0  0  0 | Uncategorized, code for device not assigned
0  0  0  0  0  1 | Robot
0  0  0  0  1  0 | Vehicle
0  0  0  0  1  1 | Doll / Action Figure
0  0  0  1  0  0 | Controller
0  0  0  1  0  1 | Game
X  X  X  X  X  X | All other values reserved

Referencias
https://www.bluetooth.org/foundry/assignnumb/document/baseband
http://trifinite.org/trifinite_stuff_btclass.html

[Programa 2 - Escanear y detectar dispositivos Bluetooth cercanos]

Programa 2 - Escanear y detectar dispositivos Bluetooth cercanos

Código [Seleccionar] Expandir

#include <stdio.h>
#include <stdlib.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

int main ()
{
      inquiry_info *ii = NULL; //Almacena la lista de dispositivos detectados durante el inquiry
      int max_rsp, num_rsp; //Numero de respuestas/dispositivos detectados
      int dev_id; //Identificador del adaptador Bluetooth local
      int socket; //Socket HCI;
      int len, i;

      char MAC_dev[20]; //Direccion MAC del dispositivo detectado
      char nombre_dev[248]; //Nombre del dispositivo detectado

      printf("+ BlueScanner por Gospel [elblogdegospel.blogspot.com]\n");
      printf("+ src: people.csail.mit.edu/albert/bluez-intro/c401.html\n\n");

      //Obtenemos el identificador del adaptador local Bluetooth
      dev_id = hci_get_route(NULL);
      if (dev_id < 0)
      {
            printf("[!] Error. Dispositivo Bluetooth local no disponible.\n");
            exit(1);
      }
                     
      //Abrimos un socket local HCI
      socket = hci_open_dev(dev_id);
      if (socket < 0)
      {
            printf("[!] Error. Fallo al intentar abrir socket HCI.\n");
            exit(1);
      }

      //Inicializamos algunas variables
      len = 8; //El tiempo de inquiry por dispositivo es de 1.28x8=10.24 secs/dispositivo
      max_rsp = 255; //Se pueden detectar a lo sumo 255 dispositivos

      //Creamos la lista de dispositivos detectados con hci_inquiry
      ii = (inquiry_info*)malloc(max_rsp * sizeof(inquiry_info));

      printf("Detectando dispositivos...\n\n");

      //hci_inquiry lleva a cabo un descubrimiento de dispositivos Bluetooth y devuelve una lista de
      //dispositivos detectados en inquiry_info ii para ser almacenados.
      //La bandera IREQ_CACHE_FLUSH permite que la caché sea limpiada antes de buscar nuevos dispositivos.
      //En otro caso, podrian aparecer dispositivos anteriormente detectados pero ahora fuera de rango.
      num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, IREQ_CACHE_FLUSH);
      if(num_rsp < 0)
            printf("[!] Error. Fallo al intentar hci_inquiry.\n");

      //Para cada una de las respuestas obtenidas durante el inquiry obtenemos el nombre del dispositivo
      for(i=0;i<num_rsp;i++)
      {
            ba2str(&(ii+i)->bdaddr, MAC_dev);
            memset(nombre_dev, 0, sizeof(nombre_dev));
            if(hci_read_remote_name(socket, &(ii+i)->bdaddr, sizeof(nombre_dev), nombre_dev, 0) < 0)
                  strcpy(nombre_dev, "[Desconocido]");

            printf("Dispositivo (%d) encontrado:\n\tMAC: %s\n\tNombre: %s\n\n", i+1, MAC_dev, nombre_dev);
      }
     
      free(ii);

      close(socket);

      return(0);

}

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, 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

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

[Programa 1 - Resolver el nombre de un dispostivo Bluetooth a partir de su dirección MAC.]

Programa 1 - Resolver el nombre de un dispostivo Bluetooth a partir de su dirección MAC.

Código [Seleccionar] Expandir

#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[20]; //Direccion MAC del dispositivo
      char nombre_dev[248]; //Nombre del dispositivo
      int id_dev; //Identificador del adaptador Bluetooth local
      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");
     
      strncpy(MAC_dev,argv[1],20);

      printf("Detectando nombre del dispositivo <%s>...\n",MAC_dev);

      //Convertimos la dirección MAC al formato de estructura bdaddr_t
      baswap(&bdaddr, strtoba(MAC_dev));
                     
      //Obtenemos el identificador del adaptador local Bluetooth
      id_dev = hci_get_route(&bdaddr);
      if (id_dev < 0)
      {
            printf("[!] Error. Dispositivo Bluetooth local no disponible.\n");
            exit(1);
      }
                     
      //Abrimos un socket local HCI
      socket = hci_open_dev(id_dev);
      if (socket < 0)
      {
            printf("[!] Error. Fallo al intentar abrir socket HCI.\n");
            exit(1);
      }
           
      //Obtenemos el nombre de la dirección MAC remota
      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 resolver el nombre del dispositivo.\n");
            printf("Dispositivo encontrado:\n\tMAC: %s\n\tNombre: [Desconocido]\n",MAC_dev);
      }
       
      close(socket);

      return(0);
}


[Taller orientado al desarrollo de programas relacionados con la Seguridad en Bluetooth en Linux]

Taller orientado al desarrollo de programas relacionados con la Seguridad en Bluetooth en Linux.

Se necesita tener instalados los siguientes paquetes Bluez (a ser posible, las últimas versiones):
- bluez-utils
- bluez-libs
- bluez-libs-devel