Estado del arte y técnicas de hacking bluetooth y

Document Sample
Estado del arte y técnicas de hacking bluetooth y Powered By Docstoc
					                                Seguridad en
                                  bluetooth
                    dab@digitalsec.net




NCN V, 18/10/2005
                    Agenda
   Introducción.
   Identificación de dispositivos.
   Vulnerabilidades.
   Otras consideraciones.
   Conclusiones.
                    Introducción
   Historia.

       Toma el nombre del Rey danés Harald Blaatand
        (940-981).
           Conocido como diente azul (bluetooth).

           Famoso por el dialogo y la conversión al
            cristianismo de los vikingos.

       El emblema viene de sus iniciales.
                  Introducción
   Bluetooth Special Interest Group (SIG).

       Diseñado con la intención de sustituir cables en
        pequeños dispositivos.

       Fundado en 1998 por una organización formada por
        empresas como Ericsson, Nokia, IBM, Toshiba,
        Microsoft e Intel.
                      Introducción




                                                          Hedy Lamarr (1913-2000)
   Cambios de 1.2 a EDR (Enhanced Data Rate)
    o 2.0.

       Mayor alcance: hasta 100m.

       Velocidad: 721Kb/sec a 2Mbit/sec.

       Saltos de frecuencia (evita interferencias).

       Reducción de velocidad en el establecimiento de
        enlace.
                Introducción
   Diferencias entre bluetooth y wireless:
     Bluetooth: diseñado para sustituir cables en
      pequeños dispositivos móviles.
     802.11b: diseñado para sustituir cables en
      LAN.

     Bluetooth: no necesita poco ancho de banda.
     802.11b: requiere amplio ancho de banda.


   Similitudes entre bluetooth y wireless:
       Ambas emiten en 2.4Ghz.
                Introducción
   Piconet:
     Un “maestro” por piconet.
     El maestro define parámetros de conexión.

     Máximo de 7 clientes esclavos.
                   Introducción
   Scatternet:
       Un maestro no puede serlo en dos piconet.
       Dos esclavos en una misma piconet.
       Soporte opcional.
                  Introducción
   Modos de seguridad:

       Modo 1: Permite conexiones desde cualquier
        dispositivo.
       Modo 2: requiere una seguridad sencilla por
        servicio: L2CAP.
       Modo 3: utiliza procedimientos de seguridad antes
        de establecer el canal de la comunicación:
            Uso de autenticación mediante PIN.
            filtro por dirección de origen (BD_ADDR).
            Cifrado mediante SAFER+.
                   Introducción
   Pila Bluetooth:
       Bluetooth radio: convierte datos a señal de radio y
        viceversa.
       Baseband: parámetros de bajo nivel de conexión
        (cifrar y descifrar paquetes, corrección de errores).
       Link Manager: gestión de conexiones, comprueba
        su estado o las elimina si han terminado.
       L2CAP: quienes y donde están conectados. Capa
        Intermediaria entre la API y protocolos más bajos.
       RFCOMM: Emula puertos serie.
       TCS: gestiona las conexiones de audio.
       SDP: sistema por el cual se gestionan los servicios
        de los dispositivos.
       OBEX: protocolo de intercambio de datos.
                Introducción
   Pila Bluetooth:
                   Introducción
   Seguridad en autenticación - PIN:

       Generalmente de 4 dígitos (soporta hasta 16).
       Productos con PIN por defecto: 0000.
       Posibilidad de obtener un PIN de 6 dígitos en 12,5
        segundos (fuente: @atstake).
Identificación de dispositivos.




  Captura de tramas HCI.
                  Introducción
   Claves utilizadas en el “Paring”:
       Kx: Kx = E21(LK_RAND, BD_ADDR): clave de
        cada dispositivo Kx (se genera solo una vez).
       Kinit: Kinit=E22(PIN, PIN_LENGTH,
        IN_RAND): clave inicial necesaria para siguientes
        pasos.
          “A” genera y manda en texto claro a “B”,
           IN_RAND, un número aleatorio.
          Se genera en cada dispositivo: LK_RAND.

          Se transmiten los RAND.

       Klink: clave temporal de enlace.
          Puede ser Kx o Kab (depende del modo de
           seguridad y características del dispositivo).
          Se utiliza en el proceso de autenticación.
               Introducción
Clave Kx:




Clave Kinit:
                     Introducción
   Autenticación en el “Paring”:

       Dispositivo “B” transmite a “A” su BD_ADDR.
       Dispositivo “A”, genera AU_RAND y lo transmite a “B”.
       Dispositivo “B” genera SRES y lo envía a “A”.
       SRES: SRES=E1(AU_RAND, BD_ADDRb, Klink)
       Se comprueba que ambos dispositivos tienen el mismo SRES
        y se concluye la autenticación.
               Introducción
   Clave Kab, generada dependiendo del modo de
    seguridad:

       Ambos dispositivos crean la clave.
       Se genera en cada dispositivo LK_RANDx.
       Se transmiten LK_RAND usando Kinit.
       Se genera la clave K del otro dispositivo, con el
        LK_RAND y Kinit.
       Se genera Kab: Kab=XOR(Ka,Kb).
             Introducción
Autenticación:




Clave Kab:
                    Introducción
   Cifrado de datos:

       Los datos se cifran con el
        algoritmo:XOR(BD_ADDR, CLOCKa, Kc).

       Generación de Kc:
               Kc: Kc=E3(EN_RAND, Klink, COF).
                   COF: Obtenido de ACO, en el proceso de
                     autenticación.
                   COF: Concatenación de ambas BD_ADDR.



       CLOCKa: hora del sistema.
             Introducción
Clave Kc:




Cifrado de datos:
    Identificación de dispositivos.

   Identificación de dispositivos visibles.

       Hcitool: herramienta del paquete “bluez” de Linux.

                # hcitool scan
                   22:22:22:22:22:22 PDA
                   33:33:33:33:33:33 t630
                   44:44:44:44:44:44 nokia660


       Obtención de información posiblemente interesante: modelos
        y marcas de dispositivos.
    Identificación de dispositivos.
   Blueprint.

       Identificación de dispositivos utilizando una base de
        datos, que almacena:
            BD_ADDR.
            Servicios (SDP).

# sdptool browse --tree 00:02:78:38:94:3C | ./bp.pl
                00:02:78:38:94:3C -nomac
                00:0A:D9@4063698
                device: Sony Ericsson T610
                version: R1L013
                date: n/a
                type: mobile phone
                note: n/a
Identificación de dispositivos.
Identificación de dispositivos.
   RedFang.

       Identificación de dispositivos “no
        detectables”, mediante fuerza bruta.

       Soporte para múltiples “dongles”.

       Excesivamente lento.
Identificación de dispositivos.
     Identificación de dispositivos.
   Bluespam.

         Identificación de la categoría de dispositivos con el fin de
          mandarle Spam.

              Clase: mediante este atributo es posible obtener que tipo de
               dispositivo es.




    https://www.bluetooth.org/foundry/assignnumb/document/baseband
               Vulnerabilidades
   Bluejacking.

       Consiste en enviar un contacto cuyo nombre es el
        texto que se desea que aparezca a la persona en la
        pantalla de su terminal.

       No es una vulnerabilidad, no implica riesgo.

       Utilizada para mandar mensajes de texto a modo
        de “chat”.

            http://www.bluejackq.com/
            Vulnerabilidades

   PSM Scanning.

       Comprobar los servicios disponibles sin
        utilizar SDP (browse).

       Similar a un análisis de puertos en TCP/IP.

       Herramienta: BTAudit.
        http://www.betaversion.net/btdsd/download/
Identificación de dispositivos.
              Vulnerabilidades
   BlueSnarf.

       Es posible obtener datos confidenciales sin realizar
        autenticación: agenda, sms.
       Utilizando OBEX realiza el GET en un servicio
        utilizado generalmente para recibir contactos
        (vCards); “OBEX PUSH”.
       Archivos conocidos: (IrMC, Ir Mobile
        Communications). Ejemplo: telecom/pb.vcf.
       Sony Ericsson T68, T68i, R520m, T610, Z1010.
       Nokia 6310, 6310i, 8910, 8910i.
Identificación de dispositivos.
            Vulnerabilidades
   BlueSnarf++.

       Similar en concepto a bluesnarf.

       El contenido es navegable (semejante a un FTP).

       Se pueden obtener datos de sistemas de almacenamiento
        externos; SD, MMC.

       Permite escritura y lectura.

    -   No existen datos públicos (WTH).
              Vulnerabilidades
   Bluebug.

       Riesgo alto.

       Permite realizar una conexión al terminal e
        introducir comandos AT (RFCOMM).

       Llamadas de voz/datos, envío de SMS, obtención
        de información: IMEI, modelo del sistema, agenda.
         http://new.remote-exploit.org/index.php/BT_main.
       Lista de comandos AT:
              Vulnerabilidades

   BlueSmack.

       Denegación de servicio al estilo “ping de la
        muerte”.

       Se realiza utilizando peticiones del tipo “request”,
        en L2CAP.

       No requiere autenticación.

       Riesgo bajo.
                Vulnerabilidades
   Abuso del modo 3.

       Ataque que aprovecha la falta de autorización por
        canal.

       Ejecución:

            El atacante consigue introducirse en la lista de dispositivos
             de confianza, enviando una vCard por ejemplo. Requiere
             ingeniería social.
            El dispositivo no comprobará a que servicios puede acceder
             permitiéndole acceder al servicio de puerto serie, Obex
             FTP, etc.
               Vulnerabilidades

   BlueBump.

       Requiere ingeniería social: crear una conexión segura.
            Ejemplo: Enviar un vCard y forzar el modo-3.
       El atacante solicita borrar su clave, manteniendo la conexión
        establecida.
       La victima no controla que aun sigue la conexión establecida.
        El atacante solicita que la clave se regenere.
       El atacante consigue entrar en la lista de la victima sin tener
        que autentificarse nuevamente.
            Vulnerabilidades
   BlueDump o Bluespoof.

       Se realiza para obtener el PIN del emparejamiento
        de dos dispositivos.

       Es necesario conocer ambas BD_ADDR.

       Consiste en realizar un “spoof” de uno de los
        dispositivos (BD_ADDR y class) y enviar una
        petición del tipo
        “HCI_Link_Key_Request_Negative_Reply”, que
        causa la generación de una nueva clave.
             Vulnerabilidades

   Denegación de servicio en OBEX

       Mala implementación del protocolo OBEX.

       Dispositivos afectados: nokia 7610, 3210, ¿otros?.

       Envío de un archivo con caracteres “prohibidos”
        por el protocolo: “:” y “\”. (Punto 4.3, pagina 46
        de IrOBEX12.pdf).

       Requiere aceptar la conexión: riesgo bajo.
Identificación de dispositivos.
        Otras consideraciones

   Carwhisper.

       Enlace con sistema de manos libres en coches.

       Clave por defecto.

       Oír o interferir en las conversaciones.
        Otras consideraciones
   Bluetooone / Bluesniper.

       Potenciar la señal de los dispositivos bluetooth
        mediante antenas.
       Bluesniper:
    http://www.tomsnetworking.com/Sections-article106.php
        Otras consideraciones
   Gusanos.

       Cabir: vallez@29A.
            Primer gusano de transmisión vía bluetooth.
            Requiere aceptar la instalación
            Riesgo bajo.


       Commwarior: e10d0r.
            Primer virus de propagación por MMS.


       Lasco: vallez@29A.
            Evolución de Cabir
            Infecta otros archivos “.sis”.
       Medidas de Seguridad

   Desactivar Bluetooth si no se utiliza.
   Configurar el dispositivo como “no detectable”.
   Utilizar un nombre que no sea representativo de las
    especificaciones técnicas.
   Utilizar un PIN complejo.
   No aceptar conexiones de dispositivos desconocidos.
   Verificar, de forma periódica, los dispositivos
    tipificados como de confianza.
   Configurar el dispositivo para que acepte cifrado.
   Mantener el “firmware” actualizado.
              Conclusiones

   Los fallos encontrados pertenecen a una mala
    implementación del protocolo en el
    dispositivo.

   Actualmente se puede considerar un protocolo
    seguro.

   Se han reportado debilidades en multitud de
    sistemas distintos.
                    Referencias

   http://www.bluetooth.org

   http://www.trifinite.org/

   http://www.securityfocus.com/infocus/1836.

   http://www.blackops.cn/whitepapers/atstake_smashing_teeth.p
    df

   http://www.geektown.de/index.php?catid=9&blogid=1.
           Agradecimientos
   Organización de NCN, Govern Balear,
    Parc BIT.

   !dSR

   FREED0M, ICEHOUSE, Ilo--.