Friday, October 17, 2008

BD_ADDR spoofing attack

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.



Wednesday, October 15, 2008

Changing HTC Shift integrated BD_ADDR

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.

Monday, October 6, 2008

Sending / Getting files from mobile phones

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.

Saturday, October 4, 2008

Sending AT commands to mobile phones

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.

Friday, October 3, 2008

Discovering Bluetooth devices and services

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.

Thursday, October 2, 2008

I got the Shift

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:
  1. Unlock Windows Mobile File Explorer
  2. HardSPL the HTC Shift
  3. Install a custom ROM
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... :)

Wednesday, October 1, 2008