1.  Cracking al PIN de BlueTooth.

  1.1.  Introducción.

  Debido a la reciente publicación de este método, y al interés general que ha suscitado, nos adelantamos a su publicación y lo hacemos en forma de Anexo.

  Aunque no entraremos en profundidad con los algoritmos matemáticos para no hacer el artículo demasiado técnico, si que es imprescindible un perfecto conocimiento de la generación, intercambio y manejo de las claves, explicado con detalle en le capítulo 3.


  1.2.  El ataque básico.

  Para poder realizar esta técnica, el atacante tiene que capturar y almacenar un determinado flujo de datos en el momento del emparejamiento y autenticación de dos dispositivos BlueTooth. Luego todo consiste en aplicar un algoritmo de fuerza bruta para poder saber el PIN utilizado en el emparejamiento.

  Para hacer uso de esta técnica necesitamos previamente implementar los algoritmos de generación de claves, E₁, E₂₁ y E₂₂, que son una modificación del conocido cifrado por bloques SAPHER+.




  Conocidos gracias al sniffer el BD_ADRR y el IN_RAND, generamos un PIN y aplicamos estos datos a nuestra implementación de E₂₂, con lo que conseguimos una K_init. El atacante puede usar la K_init para desXORear LK_RAND_A y LK_RAND_B (mensajes 2 y 3), y aplicarlas al algoritmo E₂₁ para conseguir una hipotética K_AB.

  Ahora podemos aplicar la K_AB y el AU_RAND_a (mensaje 4) al algoritmo E₁ para conseguir el SRES y compararlo con el SRES del mensaje 5.

  Si coinciden es que ya tenemos el PIN correcto y la Clave de Linkado.
Si fuera necesario se pueden usar el valor de los mensajes 6 y 7 para asegurarnos.




  Si recordamos que SRES es de 32 bits, nos encontramos con el impedimento de que solo tenemos 64 bits (SRES_A y SRES_B) para poder comparar nuestra salida de datos. Esto implica que el sistema solo es efectivo si el PIN es de menos de 64 bits (hasta 7 dígitos). Si el PIN es mayor, hay muchas posibilidades de tener varios candidatos, y aunque el sistema encuentre uno, es posible que no sea el correcto.



  1.3.  Implementaciones del Crack.

  Los autores del método han desarrollado varias implementaciones de los algoritmos, desde la versión sin optimizar hasta versiones con tablas precalculadas.

  A fecha de hoy el código fuente no está liberado, aunque podéis encontrar una descripción completa de los algoritmos en el documento original.

  Como vemos en la siguiente tabla, los tiempos de ruptura son totalmente ridículos.




  1.4.  Forzando un nuevo emparejamiento.

  Hasta aquí la idea no es nueva, y como podemos ver, tiene la tremenda dificultad de que hay que estar “presente” en el mismo momento en el que dos dispositivos son emparejados, y esto solo ocurre una vez, porque la Clave de Linkado una vez creada se almacena, y en las siguientes veces el proceso de emparejamiento no se realiza.

  La novedad de todo esto radica en un nuevo ataque, que fuerza al protocolo de conexión a realizar un nuevo emparejamiento, y ahora ya sí que podemos llevar a acabo todo lo descrito anteriormente.

  Asumimos que los dispositivos ya han sido previamente emparejados antes de establecer la nueva comunicación, con lo cual como hemos dicho se saltan el proceso de creación de K_AB y pasan directamente a la Autenticación.

  Hay descritos tres métodos para forzar un nuevo emparejamiento, y su eficacia depende del firmware de los dispositivos.

     1.- Dado que los dispositivos pasan directamente al proceso de autenticación, el dispositivo maestro envía al esclavo un mensaje AU_RAND, y queda a la espera del SRES de retorno. Las especificaciones BlueTooth contemplan la posibilidad de que un dispositivo pierda su Clave de Linkado, y en ese caso, el esclavo manda un mensaje LMP_not_accepted como respuesta.
De esta forma, justo después de que el maestro haya enviado el AU_RAND, el atacante inyecta un mensaje LMP_not_accepted hacia el maestro, forzándole a descartar su Clave de Linkado y a reiniciar un nuevo emparejamiento.





    2.- Al comienzo de la fase de Autenticación, el dispositivo maestro tiene que enviar un mensaje AU_RAND al dispositivo esclavo. Si antes de que haga esto, el atacante envia un mensaje IN_RAND hacia el dispositivo esclavo, este creerá que el maestro ha perdido su Clave de Linkado, y forzará un nuevo emparejamiento.




    3.- Como hemos visto antes, durante la fase de Autenticación, el dispositivo maestro envía un mensaje AU_RAND al esclavo y queda a la espera de un SRES de respuesta. Si después de que el maestro haya enviado el AU_RAND, el atacante le inyecta un SRES aleatorio, forzará el reinicio de la fase de Autenticación. Después de cierto número de intentos, el maestro da como errónea la Autenticación, y forzará un nuevo emparejamiento.




  Si quisiéramos hacer un ataque “on line”, la forma es grabar toda la transferencia entre los dispositivos después del proceso de emparejamiento. Mientras tanto vamos crackeando el PIN (0.06 – 0.3 seg para un PIN de 4 dígitos), descodificados toda la información guardada y seguimos descodificando “on line”.
Dado que BlueTooth transfiere a 1 Megabit/s, con un buffer de 40KB es suficiente para un PIN de 4 dígitos.

  Suponiendo que tengamos el software necesario, aún así no es tan fácil el ataque.

  El re-emparejamiento es un ataque activo, y requiere inyectar datos en un momento determinado, con lo que necesitaremos un dispositivo BlueTooth “preparado” para poder llevar acabo las inyecciones en su momento preciso, ya que normalmente esto no nos será posible.

  Si el dispositivo esclavo verifica la BD_ADDR del maestro, necesitaremos poder spoofear la BD_ADDR, que también requiere un dispositivo BlueTooth “preparado”.

  Y por último, si el ataque tiene éxito, los usuarios tienen que meter de nuevo el PIN, lo que puede levantar sospechas.

Bueno,
No exactamente van de la mano, aunque deberían ir.

Son sistemas de cifrado distintos, en este caso que dices el RSA es cifrado asimétrico y el WEP es simétrico.
Esto quiere decir el RSA tiene un par de claves, y lo que cifras con una solo puedes descifrarlo con la otra, mientras que en WEP cifras con una clave y descifras con la misma.

Ambos tienen ventajas e inconvenientes.

El inconveniente del WEP, y de todos los cifrados simétricos, es que ambas partes tienen que conocer la clave, con lo que la parte que la genera se la tiene que enviar a la otra parte, o tienes que dársela previamente de manera manual.

Y aquí ya puedes inventar mil mecanismos para que nadie te robe la clave ni la capture al mandarla.

En el caso del WEP, las claves se tienen que almacenar previamente en ambos lados. Además, como ambas claves son fijas, tienes que meter mas historias (el IV) para que no puedan hacer análisis de frecuencias y demás.

Aquí evidentemente el problema es que si alguien conoce la clave porque te la roba directamente de donde la tengas almacenada o porque esnifa el tráfico, o porque tiene mucho texto cifrado con la misma clave, etc, se rompió la seguridad. Ya te puede descifrar todo.

Con un sistema PKI es distinto, porque lo que se hace si quieres que alguien te mande algo cifrado, es darle previamente una clave de tu par de claves, la que se conoce como clave pública. El cifra lo que quiera mandarte con esa clave, con lo cual solo se puede descifrar con su otra pareja (recuerda, lo que se cifra con una solo se descifra con la otra), la clave privada.

De esta forma te da igual que alguien capture el tráfico o capture tu clave pública, porque sin tener la privada, no podrá descifrarlo.

El incoveniente de esto es que es muy lento, demasiado.
No podemos cifrar directamente los datos a transferir porque no acabaríamos nunca.

Entonces aquí es cuando van de la mano como tu dices.
Lo que se hace es un cifrado mixto.

El emisor genera una clave para cifrar y descifrar, y en vez de mandarsela al receptor en claro, lo que hace antes de mandarla es cifrar esa clave con la clave pública del receptor.
Así da igual que alguien la capture, porque está cifrada, y solo el receptor puede descifrarla.
Una vez la clave compartida, se cifra todo con ella.

Por ejemplo el SSL usa para cifrar un RC4 por ejemplo y la clave secreta la intercambia cifrada con un RSA o un DH.
Además, como el sistema de intercambio de claves no exige que las claves sean predefinidas como en WEP, las puedes cambiar cada pocos segundos, haciendo imposible su análisis.

Pero vamos, en el caso del WEP y WPA no es así. Aunque lo haya desarrollado la empresa RSA, no tiene nada que ver con el algortimo RSA.

De hecho el protocolo TKIP tampoco implementa cifrado RSA.

3.1. Descripción General

  3.1.1. Modos de seguridad.

    Hay tres modos primarios de seguridad.

    Modo 1. Sin seguridad. Todos los mecanismos de seguridad (autenticación y cifrado) están deshabilitados. Además el dispositivo se situa en modo promiscuo, permitiendo que todos los dispositivos Bluetooth se conecten a él.

    Modo 2. En la capa L2CAP, nivel de servicios. Los procedimientos de seguridad son inicializados después de establecerse un canal entre el nivel LM y el de L2CAP. Un gestor de seguridad controla el acceso a servicios y dispositivos. Variando las políticas de seguridad y los niveles de confianza se pueden gestionar los accesos de aplicaciones con diferentes requerimientos de seguridad que operen en paralelo.
    Su interface es muy simple y no hay ninguna codificación adicional de PIN o claves.

    Modo 3. En el nivel de Link. Todas las rutinas están dentro del chip BlueTooth y nada es transmitido en plano. Los procedimientos de seguridad son iniciados antes de establecer algún canal. Aparte del cifrado tiene autenticación PIN y seguridad MAC. Su metodología consiste en compartir una clave de enlace (clave de linkado) secreta entre un par de dispositivos. Para generar esta clave, se usa un procedimiento de “pairing” cuando los dos dispositivos se comunican por primera vez.


  3.1.2. Emparejamiento de Dispositivos

  Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem).

  La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos.
Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave.

  El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento.

  No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN.


  3.1.3. Inicialización y Generación de la claves.

  La Clave de Linkado es generada durante una fase de inicialización, cuando dos dispositivos empiezan a comunicarse. Según la especificación BlueTooth, la clave es generada durante la fase de inicialización cuando el usuario introduce un PIN idéntico en ambos dispositivos. Después de completarse la inicialización, los dispositivos se autentican de manera automática y transparente y se lleva a cabo el cifrado de la conexión.



  El proceso de Inicialización se desarrolla según los siguientes pasos:

    3.1.3.1 Generación de una clave de inicialización K_init.

    Aplicando el PIN del dispositivo y su longitud, el BD_ADDR (48 bits) y un número aleatorio de 128bits, IN_RAND al algoritmo E22 .

    El resultado es una palabra de 128 bits, referida como K_init.

    Resaltamos que el PIN está disponible en ambos dispositivos BlueTooth, y que IN_RAND es transmitido en plano.

    Respecto a BD_ADDR, si uno de los dispositivos tiene un PIN fijo, se usa la BD_ADDR del dispositivo asociado, y si ambos tienen un PIN variable, se usa el PIN del dispositivo que recibe el IN_RAND (el Slave).
Esto debido a que algunos dispositivos tienen un PIN predefinido que no puede ser modificado, con lo cual este PIN tiene que introducirse en el dispositivo al que queremos emparejarnos. Si ambos tienen un PIN fijo, no pueden emparejarse.





    3.1.3.2 Generación de la clave de linkado K_ab.

    Usando el algoritmo E21, ambos dispositivos crean la clave de linkado.

    Los dispositivos usan la clave de inicialización  para intercambiar dos nuevos números aleatorios de 128 bits, conocidos como LK_RAND_A y LK_RAND_B. Cada dispositivo genera un número aleatorio de 128 bits y lo envía al otro dispositivo previamente XOReado bit a bit con K_init. Dado que ambos dispositivos conocen K_init, cada dispositivo conoce ambas LK_RAND.

    Usando como parámetros de entrada un BD_ADDR y el LK_RAND, el algoritmo E21 obtiene la clave de linkado K_ab.





    3.1.3.3. Autenticación BlueTooth

    El procedimiento de autenticación sigue el conocido esquema “challenge-response”, desafío-respuesta.

    Los pasos son los siguiente:

    • El “demandante” transfiere su dirección de 48 bits (BD_ADDR) al “verificador”.

    • El verificador le transfiere un “desafío” aleatorio de 128 bits (AU_RAND) al demandante.

    • El verificador usa el algoritmo E1 para generar el “response” de autenticación, usando como parámetros la dirección del demandante, BD_ADDR_b, la Clave de Linkado, K_ab, y el desafío. El demandante realiza la misma operación.

    • El demandante le devuelve el “response”, SRES, al verificador.

    • El verificador compara el SRES del demandante con el que el ha calculado.

    • Si los valores de los 32 bits de los SRES son idénticos, el verificador establece la conexión.

 


    En este proceso, se crea además un número de 96 bits llamado ACO (Authenticated Ciphering Offset) en ambos dispositivos, que será usada durante para la creación de la Clave de Cifrado.



    3.1.3.4 Generación de la clave de cifrado.

    Cuando el Link Manager (LM) activa el cifrado, se crea la Clave de Cifrado, K_c, que es modificada cada vez que el dispositivo entra en modo dicho modo.

    La Clave de Cifrado es generada aplicando al algoritmo E3 la Clave de Linkado, un número aleatorio de 128 bits y un Ciphering Offset (COF) basado en el valor de ACO del proceso de autenticación.





    En este punto ya estaríamos en condiciones de transferir datos cifrados.



  3.1.4. Proceso de cifrado en BlueTooth.

  La especificación de BlueTooth, cono hemos permite tres modos de cifrado diferentes.

  • Modo 1. Ninguna parte del tráfico de datos es cifrada.

  • Modo 2. El tráfico general va sin cifrar, pero el tráfico dirigido individualmente se cifra según las claves individuales de la conexión. 

  • Modo 3. Todo el tráfico es cifrado acorde a la Clave de Cifrado.


  La información de usuario es protegida por cifrado de la carga útil (payload), ya que el código de acceso y la cabecera del paquete nunca son cifrados. El cifrado se lleva a cabo con el algoritmo de cifrado E0, que consiste básicamente de tres partes, como se ve en la figura siguiente:




  Una parte que realiza la inicialización (generación de la clave de carga útil). Una segunda parte que es el generador de cadenas de claves, y finalmente una tercera parte en la cual se realiza el cifrado o el descifrado.
Los parámetros de entrada a dicho algoritmo serán la clave de cifrado que se obtiene del algoritmo E3, la BD_ADDR del maestro y el reloj del mismo y un número aleatorio.

  El Generador de Clave de KeyStream combina los bits de entrada de una forma apropiada y los guarda en 4 registros de desplazamiento retroalimentados, conocidos como Linear Feedback Shift Registers (LSFR). Estos registros son de 25, 31, 33 y 39 bits (128 en total). Este método viene derivado del generador de cifrado de Streams de Massey y Rueppel.

  Cuando el cifrado está activo, el maestro envía un número aleatorio (RAND) al esclavo. Antes de la transmisión de cada paquete, el LFSR se inicializa en el Generador de Clave de Carga mediante la combinación de RAND, la identificación del maestro, la clave de cifrado K_c y el número de reloj (o número de Slot). 

  Como el tamaño de la Clave de Cifrado varía desde 8 a 128 bits, tiene que ser "negociado" entre los dispositivos previamente. En cada dispositivo hay un parámetro que define la longitud máxima permitida de la clave. En esta negociación, el maestro manda su sugerencia al esclavo, y este puede aceptarla o enviar otra sugerencia. Así hastaque haya consenso entre los dispositivos, o la uno de ellos aborte la negociación. En cada aplicación, hay definido un tamaño mínimo de clave aceptable, y si estos requerimientos no son cumplidos por ambos dispositivos, la aplicación aborta la negociación, y el cifrado no puede ser usado. Esto es necesario para evitar la situación donde uno de los dispositivos fuerce un cifrado débil algún fin malicioso.

  Finalmente se genera el KeyStream (K_cipher) que es sumada en módulo-2 a los datos que se desean cifrar. El descifrado se realizará exactamente de la misma manera usando la misma clave que se usó para el cifrado.

  Cada paquete de carga útil es cifrado separadamente, lo cual se consigue si tenemos en cuenta que una de las entradas al algoritmo E0 es el reloj del maestro, el cual cambia una unidad cada intervalo de tiempo (625µs), por lo que la clave de carga útil será diferente para cada paquete, excepto para aquellos que ocupen más de un intervalo de tiempo, en cuyo caso el valor del reloj del primer intervalo de tiempo del paquete será el que se utilizará para todo el paquete.







3.2. Debilidades de la seguridad.


  3.2.1. Generales

      • No está demostrada la fuerza del generador pseudoaleatorio del procedimiento “challenge-Response”. Se podrían pruducir números estáticos o repeteciones periódicas que redujeran su efectividad.

      • PINs cortos son permitidos. De hecho se puede elegir la longitud del PIN, que va de entre 1 a 16 bytes. Normalmente los usuarios los prefieren muy cortos.

      • No hay una forma “elegante” de generar y distribuir el PIN. Establecer PINs en una red BlueTooth grande y con muchos usuarios puede ser dificil, y esto lleva normalmente a problemas de seguridad.

      • La longitud de la clave de cifrado es negociable.Es necesario un procedimiento de generación de claves mas fuerte.

      • En el caso del modo 3, la clave maestra es compartida. Es necesario desarrollar un esquema de transmisión de claves mejorado.

      • No existe autenticación de usuarios. Sólo está implementada la autenticación de dispositivos.

      • No hay límite de intentos de autenticación.

      • El algoritmo de cifrado por bloques E0 es muy débil. Más tarde se analiza.

      • La autenticación es un simple “challenge-response” con hashes. Según esta diseñado, el esquema es vulnerable a ataques “Man in the Middle”.

      • Los servicios de seguridad son limitados. Servicios de auditoría, de no repudio, etc, no están implementados.


  3.2.2. Vulnerabilidades del cifrado.

    Dejando aparte de que el cifrado es opcional, veremos que además acaece de varias vulnerabilidades.

    • El algoritmo de cifrado por bloques E0 es débil. Aunque se perfilaba como relativamente seguro hace pocos años. Su sistema de creación del Stream para el cifrado es mucho más complejo, y soluciona los problemas de reutilización de claves como el que tiene el RC4 del wifi (802.11b).

    Sin embargo, como con todos los algoritmos de cifrado, su seguridad va cayendo paulatinamente.

    Aunque E0 permite longitudes de clave que van desde 1 hasta 16 bytes (8-128 bits), Jakobbson y Wetzel presentaron un ataque con complejidad matemática de O(2^100) (esto es el equivalente a reducir la longitud de clave efectiva de 128 a 100 bits).

    Posteriormente Fluhrer y Lucks presentaron otro ataque que requería desde O(2^73) hasta O(2^84), dependiendo de la cantidad de keystream capturado.

    Hasta aquí podríamos decir que las posibilidades de ataque de recuperación de la Clave de Cifrado no eran efectivas, considerando que para conseguir un O(2^73) había que tener unos 14.000 gigas de keystream.

    Pero luego los ataques se fueron perfeccionando, hasta que en 2004, Yi Lu y Serge Vaudenay presentaron un nuevo ataque de correlación, que resuelve en O(2^37) con una cantidad de keystream consecutivo de 64 gigas, mejorándolo en el CryptoAsia 2004 a 2^40 operaciones simples solo con los primeros 24 bits de 2^35 frames.


    • Uso parcial del reloj. Como hemos visto, el reloj del dispositivo maestr es un parámetro de entrada para la generación del Stream de cifrado. Aunque parece que por un fallo de diseño el bit más significativo de su valor es ignorado, permitiendo este hecho entre otras cosas ataques tipo Man in The Middle.


    • Los datos cifrados pueden ser manipulados. Incluso con el cifrado más fuerte, las caracteristicas de los cifrados de Stream permiten que los datos interceptados en un ataque Man in The Middle puedan ser convenientemente manipulados dependiendo de la cantidad de texto cifrado conocida. Así es posible por ejemplo manipular cabeceras IP.



3.3. Vulnerabilidades de la seguridad.

  Son debidas principalmente a prácticas de codificación erróneas en el desarrollo de los servicios RFCOMM, al desconocimiento de los protocolos de seguridad BlueTooth y demás (OBEX), y a la reutilización de servicios antiguos para protocolos diferentes.


  3.3.1. Permisos IrMC

    • IrMC define los permisos de acceso para los objetos comunes
    • Hay objetos visibles aunque el servicio sea “no emparejado”
    • Servicios abiertos intencionadamente.


  3.3.2. Errores de pila

    • Buffers Overflows.
    • Fallos en la implementación de servicios como en el chequeo de la longitud de datos o la integridad de paquetes en OBEX,  o terminaciones NULL.


  3.3.3. Servicios ocultos.

    • Servicios con los más altos privilegios se dejan abiertos pero escondidos.
    • Canales traseros para hacerle la vida más fácil a otros dispositivos.
    • Acceso completo al comando AT, y por lo tanto a todo el dispositivo.


En el siguiente apartado, el 3.4, veremos los comandos necesarios para manipular sin restricciones un móvil BlueTooth, y veremos como hacerlo a través del IrD. Empieza la parte práctica.

Un algoritmo de cifrado es una función que se la aplicas a un texto y lo hace ininteligible. Se trata de que nadie acceda al contenido de ese texto si no tiene la clave de descifrado.

Base64 es una forma de codificación como la puede ser ASCII. Se usa para representar código por ejemplo binario en caracteres imprimibles. A grosso modo, cuando se le aplica a algo es para que puedas imprimirlo y verlo en pantalla sin que te salgan "huecos en blanco".
Se usa en muchas partes, en las firmas de pgp por ejemplo, pero es solo para que te puedas imprimir la firma.
Mira aquí, http://www.elhacker.net/base64.htm, tienes un codificador/descodificador de base64. Si le metes un código en base64 te lo descodifica, pero no te pide ninguna clave.

DES si es un algoritmo de cifrado, depende de una clave, con ella cifras el texto, y solo con ella la descifras.

MD5 es un algoritmo de hash. Un hash es una función que nos comprime un documento en una serie de bytes de longitud fija.
Desde el resultado del hash no podemos llegar al documento original, por lo que no es un algortimo de cifrado.
Un hash es, digamos, el resumen único del documento al que se le ha aplicado la función.

Hombre, un algoritmo de cifrado se trata de que sea reversible.


Que vá, por lo menos restando 18 tienes que adivinar que son 18 y no 19 ni 17. Con base64 no hay que adivinar nada.

No sé si se ve claro ahora la diferencia entre codificación, cifrado y hash, espero que sí. Estos son conceptos que normalmente la gene no tiene muy claros.
Míratelo con detenimiento y si te surge alguna duda, pues para eso estamos, para resolverlas.

Salu2.

Te refieres a que lo pasa a base64?

Eso no vale, pasarlo a b64 no es cifrarlo, es solamamente representarlo de otra forma. Como si lo pasas a hex, a binario, a Ascii, a unicode, etc.

2.  Especificaciones BlueTooth.

  2.1.  Tecnología.

  Bluetooth se puede definir como una propuesta de especificación de radio frecuencia por transmisión de corto alcance de datos, pudiendo transmitir a través de objetos sólidos no metálicos.

  Su alcance nominal es de 10 cm a 10 m “en teoría”, pero puede extenderse a 100 m mediante el incremento de transmisión de energía. Más tarde analizaremos lo del alcance.

  Los ordenadores, teléfonos móviles, aparatos domésticos y equipos de oficina, basados en Bluetooth pueden conectarse entre sí dentro de áreas físicas reducidas, sin necesidad de utilizar cableado, de forma “segura” (también analizaremos esto) y barata y a altas velocidades de transmisión.
También se pretende ofrecer acceso a Internet.

  La tecnología usa la banda ISM (Industrial Scientific Medicine) de los 2.4 GHz que no necesita licencia, está disponible en casi todo el mundo.
Bluetooth es además, un módulo radio de baja potencia, puede integrarse en una amplia variedad de dispositivos. Soporta transmisión de tres canales de voz, vídeo y datos a una velocidad máxima de 1 Mbps, aunque la máxima velocidad real girará alrededor de los 721 Kbps.

  Ya se habla de su uso para todo, seguridad del hogar, dispositivos médicos, etc.


  2.2.  Pila de Protocolos.

  La especificación de Bluetooth pretende que todas las aplicaciones sean capaces de operar entre sí. Para conseguir esta interoperabilidad, las aplicaciones en dispositivos remotos deben ejecutarse sobre una pila de protocolos idénticos.

  Para comunicarse con otros dispositivos Bluetooth, se requiere un hardware específico para Bluetooth, que incluye un módulo de banda base, así como otro módulo de radio y una antena.
Además deberá haber un software encargado de controlar la conexión entre dos dispositivos Bluetooth; este software (Link Manager) por lo general correrá en un microprocesador dedicado. Los Link Managers de diferentes dispositivos Bluetooth se comunicarán mediante el protocolo LMP (Link Manager Protocol).
Además habrá otros módulos de software, que constituirán la pila de protocolos, y garantizarán la interoperabilidad entre aplicaciones alojadas en diferentes dispositivos Bluetooth.

  La pila completa se compone tanto de protocolos específicos de Bluetooth (LM (Link Manager) y L2CAP (Logical Link Control Adaption Protocol), por ejemplo) como de protocolos no específicos de Bluetooth como son OBEX (Objects Exchange Protocol), UDP (User Datagram Protocol), TCP, IP, etc. Debido a que la hora de diseñar la torre de protocolos, el objetivo principal ha sido maximizar el número de protocolos existentes que se puedan reutilizar en las capas más altas para diferentes propósitos.

  A parte de todos estos protocolos, la especificación define el HCI (Host Controller Interface), que se encarga de proporcionar una interfaz de comandos al controlador BaseBand, al gestor de enlace, y nos da acceso al estado del hardware y a los registros de control.


  2.3.  Descripción de los protocolos

    2.3.1.  Link Manager (LM) y Link Manager Protocol (LMP).

      2.3.1.1.  Link manager.

      El Link Manager es el sistema que consigue establecer la conexión entre dispositivos.
Se encarga del establecimiento, la autentificación y la configuración del enlace.

      El Link Manager localiza a otros gestores y se comunica con ellos gracias al protocolo de gestión del enlace LMP.
Para poder realizar su función de proveedor de servicio, el LM utiliza los servicios incluidos en el controlador de enlace (LC, "Link Controller" o BaseBand).

      El Link Manager Protocol básicamente consiste en un número de PDUs (Protocol Data Units) que son enviadas de un dispositivo a otro.

A continuación se enuncian los servicios soportados:

      •Transmisión y recepción de datos.
      •Petición de nombre: El gestor de enlace tiene un eficiente método para inquirir y reportar la ID de un dispositivo con una longitud de máximo 16 caracteres.
      •Petición de las direcciones de enlace.
      •Establecimiento de la conexión.
      •Autentificación.
      •Negociación del modo de enlace y establecimiento, por ejemplo, modo datos o modo voz/datos. Esto puede cambiarse durante la conexión.

      2.3.1.2. Modos.

      Establecimiento de un dispositivo al modo "sniff". En este modo se reduce el ciclo de trabajo de una estación esclava, ya que sólo escucha cada M slots, siendo el valor de M negociado con el gestor de enlace. La estación maestra puede sólo comenzar la transmisión en tiempos/slots específicos, separados estos por intervalos regulares.

      Mantenimiento de un dispositivo de enlace en espera. En modo espera, el apagado del receptor durante períodos de tiempo más largos ahorra energía. Cualquier entidad puede volver a establecer un enlace, con una latencia media de 4 segundos. Esto es definido por el gestor de enlace y manejado por el controlador de enlace.

      Establecimiento de un dispositivo en modo "aparcado": Esto es útil cuando un dispositivo no necesita participar activamente en el canal, pero sí quiere permanecer sincronizado. En este modo dicha entidad "despierta" en intervalos regulares de tiempo para escuchar al canal y así poder re-sincronizarse con el resto de entidades de la piconet


    2.3.2.  Interfaz de la Controladora de la Máquina (HCI).

    La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control.
Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base.
La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas.

    Una de las tareas más importantes de HCI que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo visible (discoverable mode).


    BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos.

    Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como "nombre.de.su.sistema (ubt0)''. El nombre asignado al dispositivo local se puede modificar en cualquier momento.

    El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth.


    2.3.3.  Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP).

    El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje.
L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud.

    L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel.

    Una herramienta de diagnóstico interesante es btsockstat, para FreeBSD.
Realiza un trabajo similar al comando netstat, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior.



    2.3.4.  Protocolo RFCOMM

    El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protocolo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultáneas (canales RFCOMM) entre dos dispositivos Bluetooth.

    Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa).

    RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro.


    2.3.5.  Protocolo de Descubrimiento de Servicios (SDP).

    El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen.

    Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios.

    SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP.

    El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios.

    Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing.

   El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP mediante el servidor Bluetooth SDP denominado sdpd y el cliente de línea de comando denominado sdpcontrol se incluyen en la instalación estándar de FreeBSD.


    Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. OBEX Object Push (OPUSH):



    2.3.6.  Perfiles. (Profiles)
   
    Desde que se inició la especificación de este estándar, una de las principales preocupaciones del SIG fue garantizar la interoperabilidad total entre dispositivos de distintos fabricantes, siempre y cuando éstos compartan el mismo perfil.
Los perfiles especifican cómo utilizar la pila de protocolos de Bluetooth para implementar una solución que trabaje sin problemas con las de otras marcas. En cada uno se establecen opciones y parámetros, además de detallar cómo usar los distintos procedimientos de los diversos estándares que se encuentren implicados.

     Podemos ver la estructura de perfiles de BlueTooth y su dependencia en el siguiente gráfico.


Los perfiles tienen dependencia de otro perfil si reutilizan partes de él. En el gráfico vemos como el perfil Object Push depende del Generic Object Exchange, de Serial Port y de Generic Access.

    Han sido desarrollados más perfiles, y todo indica que se seguirán desarrollando otros nuevos.
En este tutorial comentaremos solo los dos siguientes, pero si alguien quiere profundizar en el tema, tiene más información en: http://www.palowireless.com/infotooth/tutorial/profiles.asp



      2.3.6.1.  Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN).

      El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación:

      • Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados;
      • Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos.

      El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones:
      • Acceso LAN para un único dispositivo Bluetooth;
      • Acceso LAN para múltiples dispositivos Bluetooth;
      • Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie).


      2.3.6.2.   Perfil OBEX Object Push (OPUSH).

      OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM.

      El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número.

      A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono.

Usa el CAPICOM,
A diferencia de los anteriores algoritmos propuestos, con CAPICOM puedes elegir entre los que hay "profesionales", que ya no son juguetitos (RC4, RC5, DES, 3DES, 3DES112, etc.), y las funciones ya vienen implementadas.




Acuédate de instalar capicom.dll.

Si lo mueven con el botón buscar aparece, o eso debería hacer, la verdad es que no lo he probado nunca.

Continuamente hay que borrar muchos post, y aún así se quedan otros muchos que deberían ser borrados y se "escapan". Imaginate que los mods tuvieran que avisar a todo el mundo.

Para que no te borren ningún post solo hay que escribir con un poco de lógica.

Hay muchas preguntas que ya están resueltas mil veces, o que simplemente buscando en google aparacen en miles de sitios.
Hay preguntas que no se pueden dejar, como el típico quiero hackear a mi vecino, etc.

Hay que cuidar un poco los post del foro, es comprensible, a nadie le hace gracia ponerse a leer sobre una temática y encontrarse todos los post preguntando y respondiendo lo mismo.

No he visto el post que te han borrado, pero supongo que tenía su motivación.

Scriptkiddie no es ningún insulto, no te lo tomes a mal.

Si te das una vuelta, verás que un amplio porcentaje del personal no digo solo que no sepa programar scripts, sino que no sabe ni utilizar los que están ya programados.

1.  Introducción a BlueTooth.
  1.1.  Propósitos y alcance.
  1.2.  Definiciones.
  1.3.  Referencias.

2.  Especificaciones BlueTooth.
  2.1.  Tecnología.
  2.2.  Pila de protocolos.
  2.3.  Descripción de los protocolos.
    2.3.1  Link Manager y Link Manager Protocol
      2.3.1.1  Link Manager
      2.3.1.2  Modos.
    2.3.2  Interfaz de la Controladora de Máquina (HCI).
    2.3.3  Protocolo de Adaptación y Control de Enlace (L2CAP).
    2.3.4  Protocolo RFCOMM.
    2.3.5  Protocolo de Descubrimiento de Servicios (SDP)
    2.3.6  Perfiles.
      2.3.6.1  Acceso telefónico y PPP a redes.
      2.3.6.2  OBEX Object Push.

3.  Seguridad en BlueTooth
  3.1.  Descripción general.
    3.1.1.  Modos de Seguridad.
    3.1.2.  Emparejamiento de Dispositivos.
    3.1.3.  Inicialización y Generación de claves.
      3.1.3.1  Generación de la Clave de Inicialización.
      3.1.3.2  Generación de la Clave de Linkado.
      3.1.3.3  Autenticación en BlueTooth.
      3.1.3.4  Generación de Clave de Cifrado.
    3.1.4.  Proceso de cifrado.

  3.2.  Debilidades de la seguridad.
    3.2.1.  Generales.
    3.2.2.  Vulnerabilidades del Cifrado.

  3.3.  Vulnerabilidades.
    3.3.1.  Permisos IrMC.
    3.3.2.  Errores de la pila.
    3.3.3.  Servicios ocultos.

  3.4.  Los Comandos AT.
    3.4.1.  Notación de los comandos AT.
    3.4.2.  El juego de comandos AT específico para telefonía móvil GSM
    3.4.3.  Documentación de los comandos AT más interesantes
    3.4.4.  Documentación técnica

  3.5.  Una aplicación práctica de los comandos AT.
    3.5.1.  IrD-Hacking: obteniendo la agenda de un móvil por Infrarrojos.
 
4.  Ataques a BlueTooth.
  4.1.  Ataques de Localización y Enumeración.
    4.1.1.  Modo visible.
    4.1.2.  Modo no visible.
      4.1.2.1.  Fuerza bruta.
    4.1.3.  Enumeración de servicios.
      4.1.3.1.  HCI con HciTool.
      4.1.3.2.  SDP con SdpTool.

  4.2.  Ataques BlueBug con comandos AT.
    4.2.1.  Escenario 1. Desde Pocket PC.
      4.2.1.1  Hardware.
      4.2.1.2  Software.
      4.2.1.3  Interfaz de la aplicación.
      4.2.1.4  Características técnicas de la plataforma comprometida.
      4.2.1.5  Descripción del Ataque.
        4.2.1.5.1  Estableciendo la comunicación.
        4.2.1.5.2  Abriendo la aplicación.
        4.2.1.5.3  Configurando el ataque.
        4.2.1.5.4  Iniciando el ataque.
        4.2.1.5.5  Recibiendo respuestas.
        4.2.1.5.6  Extrayendo la agenda de contactos.
      4.2.1.6  Sobre el software utilizado.

    4.2.2 Escenario 2. Desde PC.
      4.2.2.1 Requisitos previos.
      4.2.2.2 Obtener los canales de transmisión.
      4.2.2.3 Comandos AT.
      4.2.2.4 Enlazar Rfcomm por canal 1.
      4.2.2.5 Conectar a Rfcomm
      4.2.2.6 Obtener información básica.
      4.2.2.7 Obtener Imei
      4.2.2.8 Iniciar llamada desde el dispositivo víctima.
      4.2.2.9 Otros comandos AT.


  4.3.  Ataques de Denegación de Servicio.
    4.3.1.  DoS  por Mensaje OBEX en Nokia 6310i

  4.4.  Ataques de autenticación.
    4.4.1.  Suplantación por inserción de datos.
    4.4.2.  Blue Snarfing.
    4.4.3.  BlueBug
    4.4.4.  Hacking desde el movil.
      4.4.4.1.  Blooover.
      4.4.4.2.  BlueTooner

  4.5.  Otros.
    4.5.1.  Bluejacking.
    4.5.2.  Ataque por fuerza bruta
    4.5.3.  Ataque de emparejamiento.
    4.5.4.  Escanéo de PSM
    4.5.5.  Ataque de reflacción.
    4.5.6.  Ataque Man in the Middle
    4.5.7.  Crackeo del PIN on-line.
    4.5.8.  Crackeo del PIN off-line.
    4.5.9.  Robo físico de clave de enlace.