32
Toshendra Sharma, 113050013 Saptarshi Sarkar, 113050044 Pankaj Vanwari, 114058001 Under guidance of: Prof. Bernard Menezes

Attacks on bluetooth devices

Embed Size (px)

Citation preview

Toshendra Sharma, 113050013

Saptarshi Sarkar, 113050044

Pankaj Vanwari, 114058001

Under guidance of:

Prof. Bernard Menezes

Outline Bluetooth history

Bluetooth Protocol

Layers in Bluetooth

Security in Bluetooth

Vulnerabilities

Attacks/Exploits

Demonstration

Bluetooth Technology proprietary open wireless technology standard for

exchanging data over short distances

was originally conceived as a wireless alternative to RS-232 data cables

It uses short wave length radio transmission in ISM band from 2400-2480 MHz

Benefits of Bluetooth Technology Cable replacement

Ease of file sharing

Wireless synchronization

Internet connectivity

Implementation frequency hopping spread spectrum

chops up the data being sent and transmits chunks of it up to 79 bands

Packet Based Protocol with a Master-Slave Structure

Piconet

A piconet is an ad-hoc computer network which used to link group of devices, where protocols allow one master device to interconnect with up to seven active slaves

Bluetooth Profiles Bluetooth Profile is a specification regarding an aspect

of Bluetooth based wireless communication between devices

Bluetooth Architecture two specifications:

the core and

the profile specifications

The core specification discusses how the technology works

profile specification focuses on how to build interoperating devices using the core technologies

Bluetooth Protocol Bluetooth Controller

Bluetooth Host

The physical links are created on the basis of masters/slaves

Typical Scatternet

Layers in bluetooth

Device Address (BD_ADDR)

NAP: Nonsignificant Address Part

UAP: Upper Address Part

LAP: Lower Address Part

Bluetooth Security Authentication

Confidentiality

Authorization

Security Modes

Non-secure

Service level enforced security

Link level enforced security

Authentication Step 1. The verifier transmits a 128-bit random

challenge (AU_RAND) to the claimant.

Step 2. The claimant uses the E1 algorithm to compute an authentication response using his unique 48-bit Bluetooth device address (BD_ADDR), the link key, and AU_RAND as inputs. The verifier performs the same computation. Only the 32 most significant bits of the E1 output are used for authentication purposes. The remaining 96 bits of the 128-bit output are known as the Authenticated Ciphering Offset (ACO) value, which will be used later to create the Bluetooth encryption key.

Contd.. Step 3. The claimant returns the most significant 32

bits of the E1 output as the computed response, SRES, to the verifier.

Step 4. The verifier compares the SRES from the claimant with the value that it computed.

Step 5. If the two 32-bit values are equal, the authentication is considered successful. If the two 32-bit values are not equal, the authentication has failed.

Bluetooth Vulnerabilities Short PINs are allowed (Attacks on PINs are possible)

Repairing Attack

Manipulating Service and Device Class Information

Inadequate Friendly Name-Handling Exception Error

Friendly Name Command Injection

Windows Mobile Friendly Name Blueline Vulnerability

Unauthorized AT Access

Headset profile Attacks

Short PINs (PIN Attack) Need to capture Pairing data

Attacker needs these information from eavesdropping:

IN_RAND, sent from the initiator to the responder

Two COMB_KEY values, sent from the initiator and the responder devices

AU_RAND, sent from the authentication claimant

Signed Response (SRES), sent from the authentication verifier

Attacking tools

Re-pairing attack an attacker can manipulate the stored pairing status

between two devices by impersonating the BD_ADDR of one of the two devices.

Can use the PIN attack by eavesdropping the pairing data

Tools used: Bluesquirrel

Manipulating Service and Device Class Information Can manipulate device class & services for

impersonating others

Can even change the device class

For eg. Laptop can behave as a phone after changing device class

Demo

Inadequate Friendly Name-Handling Exception Error In September 2008, Julien Bedard reported a

vulnerability in Windows Mobile 6 devices where a long Bluetooth friendly name would cause the device to crash and reboot.

This flaw has been confirmed as triggering a kernel-level driver flaw upon retrieving the device name from a remote device, either through device discovery or upon receiving a connection from a malicious device.

Contd.. # hciconfig hci0 name `python -c 'print "A"*248'`

# hciconfig hci0 piscan

Has been patched up in updates

Friendly Name Command Injection In 2005, a vulnerability in the Linux BlueZ stack was

reported in which an attacker could execute arbitrary commands on the target systems by manipulating their Bluetooth friendly name

The vulnerability was the result of how the Bluetooth stack leveraged PIN authentication shell scripts to validate the identity of the remote entity.

# hciconfig hci0 name '`/usr/bin/id>/tmp/pwned`'

Windows Mobile Friendly Name Blueline Vulnerability

$ sudo hciconfig hci0 name "Keep Bluetooth Enabled?<br><P"

$ sudo rfcomm connect hci0 00:1D:25:EC:47:86 4

Contd.

Unauthorized AT Access In 2004, Adam Laurie reported that a number of Nokia

phones published an undocumented RFCOMM service on channel 17.

This channel did not require any authentication, giving an attacker access to the AT channel on the target mobile phone.

Attack Code $ sudo rfcomm bind /dev/rfcomm0 00:02:EE:6E:72:D3 17 $ cu -l rfcomm0 -s 9600 Connected. ATZ OK AT+CGMI Nokia OK AT+CGMM Nokia 6310i OK AT+CGSN 350997200032616 OK

Headset profile Attacks The Headset profile (HS) likely represents the single

largest deployment and use case for Bluetooth technology.

Through the HS profile, many users leverage the ubiquitous Bluetooth headset paired with a mobile phone to carry audio traffic between the devices

the HS profile is often used in car audio systems (with its counterpart, the Hands-Free or HFR profile) to leverage a local microphone and car audio speakers for voice data between a mobile device and the vehicle

We can identify the presence of the HS and HFR profiles through SDP scanning

$ sdptool records 00:0D:3C:48:72:F5

Carwhisperer Attack Bluetooth Headset Eavesdropping

Can connect to anyone’s bluetooth headset without any permission.

Can record the conversation going on near the victim’s headset

Can play the pre recorded message in victim’s headset

Let’s Do this…..

Demonstration of Carwhispererattack

Queries

Thanks You!!!