Address changed – Reset device now

December 22, 2007 at 16:34 · Filed under Bluetooth

He adquirido un Bluetooth USB Adapter, es decir, un cacharro USB para conectarme por Bluetooth a otros chismes. Andaba tiempo detrás de uno, desde que empezó todo el tema del bluehacking.

Ayer tarde, cuando llegué con mi flamante Adapter de 17 euros –Conceptronic CBTU2, funciona perfecto en Linux hasta donde he probado– me puse a probarlo y a enredar con él. Al final acabé a las dos de la mañana habiendo leído la mitad del proyecto fin de carrera Seguridad en Bluetooth, de Alberto Moreno.

Uno de los ataques que se describen (dicho sea de paso, en la actualidad muy pocos de ellos son practicables) consiste en suplantar la identidad de otro dispositivo mediante el cambio de la MAC de nuestro adaptador Bluetooth.

Los interfaces Bluetooth tienen asociada una dirección unívoca cada uno de ellos. Bluetooth, de hecho, es el estándar IEEE 802.15 (ethernet es el 802.3, y wireless es el 802.11), por lo que las direcciones de Bluetooth son exactamente iguales que las Ethernet. Se trata de 48 bits, divididos en 24 superiores para indicar el OUI (identificador del fabricante del adaptador), y en 24 bits inferiores, para identificar el dispositivo fabricado por una determinada empresa. El espacio de direcciones se reparte por tanto, entre todas las normas 802.x que requieren direcciones MAC, por lo que no encontraremos un dispositivo Bluetooth con las misma MAC que una tarjeta inalámbrica o una ethernet.

El ataque llamado Blue MAC Spoofing se basa en los niveles de confianza en que se organiza el acceso a los servicios Bluetooth. Según sea el servicio, se podrá acceder tan sólo estando autorizado, o también estando autenticado.

Por estar autorizado se entiende que la MAC de tu adaptador Bluetooth está en la lista de MACs permitidas del receptor. La autenticación implica además el conocimiento de una clave compartida de 128 bits y una clave de sesión (un desafío de 128 bits). A partir de la dirección MAC propia, y esas dos claves se genera una respuesta de autenticación de 32 bits, que sirve para autenticarse ante el otro dispositivo.

Como hay servicios que tan sólo estando autorizados podemos utilizar, podemos dejar que sea otro dispositivo el que pase a ser autorizado, y luego suplantando su identidad, alcanzar su mismo nivel de privilegios. Supongamos un escenario donde una persona (A) le transfiere a otra conocida (B) un fichero (una fotografía, p.ej.). Si para poder hacer esta transferencia se necesita estar autorizado, al comenzar el móvil de B alertará y pedirá permiso para empezar a recibir la transmisión de A. Una vez que se le ha permitido la recepción (A y B son conocidos, y confían entre sí) la MAC de A pasa a la lista de autorizados de B. Si posteriormente cambiamos la MAC de nuestro dispositivo por la de A podremos hacernos pasar por A, heredando sus permisos.

El cambio de MAC se hace con la aplicación bdaddr, y no sé si funciona con todos los adaptadores (con el Conceptronic CBTU2 sí). Esta aplicación pareceser que viene en el paquete bluez-utils, aunque ahora mismo estoy con Debian SID actualizado y el paquete bluez-utils no cuenta con esa aplicación. Me he bajado el fuente de otro lado (aquí y acá) y he montado un .tar.bz2 con (casi) todo lo necesario para que compile el programa. Hay que tener instaladas las cabeceras en /usr/include/bluetooth/, y eso se consigue instalando el paquete libbluetooth-dev. Una vez bajado el bdaddr.tar.bz2, se descomprime y se compila:

Y se ejecuta:

O para cambiar la MAC, como root:

Lo de reset device hay que tomárselo al pie de la letra: he tenido que desenchufar y volver a enchufar el adaptador, la orden hciconfig hci0 reset no funcionó.

En principio con eso hemos cambiado la MAC (si hacéis un hciconfig hci0 veréis que ha cambiado). Pero, ¿cómo saber la MAC del dispositivo autorizado? Aún estoy en ello, pero me figuro que a base de hcidump se podrá sniffar el tráfico de la red y determinar qué MACs están autorizadas.

Más interesante aún sería automatizar todo esto de forma que permanentemente se esté analizando el tráfico del entorno, y se determine qué MACs establecen conexiones y son autorizadas.

Update (2007-12-29): Efectivamente con hcidump se puede esnifar el tráfico, pero el tráfico dirigido hacia ti. En Bluetooth no hay nada parecido al modo promiscuo de las tarjetas ethernet. Las tramas de bluetooth van saltando de canal en canal de forma seudoaleatoria. Predecir ese salto son palabras mayores (por lo menos para mí), y disponer de hardware que pueda seguir los saltos también. Lo explican en este hilo de la lista de desarrollo de Bluez. Desde luego esa idea de averiguar qué MACs se comunican con qué MACs es nada factible ahora mismo. De alguna forma hay que conseguir que la víctima se conecte con tú dispositivo bluetooth para hallar su MAC.

Comments (4)

Spinlocks

December 15, 2007 at 16:50 · Filed under Sistemas operativos

Un spinlock es un mecanismo para controlar bloqueos. Quien haya echado un vistazo al código fuente del kernel Linux lo habrá visto sin tener que profundizar mucho.

Básicamente es un procedimiento que, mediante espera ocupada, permanece inactivo hasta que se libera el bloqueo, en cuyo caso pasa a tomarlo.

Realmente es la forma más sencilla de acceder a un bloqueo, con el único inconveniente de que está consumiendo CPU a cambio de no hacer nada más que esperar:

mientras haya bloqueo {
   repetir
}
adquiere bloqueo

Lo extraño aquí es que se utilice espera ocupada, ya que siempre se trata de evitar este método. La idea es que los spinlocks van a ser muy breves, la espera ocupada va a ser tan breve y fugaz, que sería muy laborioso para el procesador y el sistema operativo andarse con procedimientos más avanzados. No merecería la pena por unos pocos nanosegundos de espera ocupada andar montando todo un circo con semáforos, o señales o algún otro mecanismo para sincronismo.

Desde luego, si van a ser más de unos nanosegundos no es nada recomendable que los hilos pierdan su cuota de tiempo de proceso iterando sin hacer nada productivo.

Otro problema potencial es que desde que se sale del bucle hasta que se apropia del bloqueo puede surgir una condición de carrera. Para evitar los problemas que ello acarrea se usarán instrucciones atómicas en ensamblador que comprueben el bloqueo y lo adquieran, pero obviamente, esto requiere soporte por parte de la arquitectura. Por supuesto, hay más soluciones, como el algoritmo de Peterson y el de Dekker.

Bibliografía:

• Entrada en la Wikipedia EN
• El fichero /Documentation/spinlocks.txt en el código fuente de Linux contiene información acerca de los spinlocks y su implementación en el kernel linux.

Comments

lastfm://

December 15, 2007 at 16:38 · Filed under lastfm

Si habéis usado alguna vez Last.FM y Firefox quizá os hayáis encontrado en la necesidad de conseguir que el navegador asocie el protocolo lastfm:// de las URIs con el reproductor de last.fm.

Para resolver este problema básicamente busqué en el google y encontré esta respuesta, que fusilo aquí mismo:

1. Abrir una pestaña con la URL about:config
2. Con el botón derecho del ratón (o el izquierdo, si somos zurdos :) haremos click para conseguir un menú contextual. Allí elegiremos la opción de Nuevo->Cadena
3. Como nombre de la cadena pondremos network.protocol-handler.app.lastfm
4. Como valor de la cadena usaremos /usr/bin/lastfm, o la ruta hacia el ejecutable de last.fm en nuestro ordenador (si no sabéis probad con which lastfm).

A partir de ahora todos los enlaces como este: lastfm://play/tracks/13258182 deberían funcionar, abriendo el reproductor de Last.FM y reproduciendo la canción desde allí.

Comments (1)