BlueSniff

Eve meets Alice and Bluetooth

Dominic Spill Andrea Bittau

University College London

Background to Bluetooth

Wireless communication protocol

Operates in the 2.4GHz ISM band 1Mb/s transfer rate Up to 100m range

Primarily used as a cable replacement technology Shipped in most cell phones, PDAs and similar devices

Bluetooth Security

Pin encryption cracked in 2006 (Y Shaked . and A. Wool)

Need to sniff handshake

Trifinite Group exploits

Attack Bluetooth implementations Exploit discoverable devices

Security advice suggests using undiscoverable mode

Bluetooth Overview
Master device
Initiates connection

Slave device

Response

All devices have MAC address and internal Clock

Bluetooth Characteristics

Packets are whitened (scrambled)

XORed with pseudo-random stream of data Based on an internal (unknown) clock value

Uses Frequency Hopping Spread Spectrum (FHSS) to minimize interference

1600 hops/second

Bluetooth devices do not have promiscuous mode

Whitening

Whitening set by lower 6 bits of the clock

A 7 bit register is initialized with 6 clock bits, the top bit is always '1' A stream of pseudo-random data is produced The stream is then XORed with the packet

Frequency Hopping

1 packet, 1 frequency 79 frequencies 1600 hops per second

Hops chosen based on MAC and clock of master device Neither MAC nor clock are known

GNU Radio

Software framework for signal processing Built in blocks

Demodulators Filters Sources and sinks (file/USRP)

Written in C++, glued together with python

Universal Software Radio Peripheral

Hardware platform used with GNU Radio

Radio sampled in hardware All processing done in software Sample 5 Bluetooth channels simultaneously ~$700 Dedicated sniffing hardware, e.g. FTS4BT is ~$10,000

7MHz Bandwidth

Affordable

Demodulating Packets

Using GNU Radio GMSK demodulator

decimation = 16 mu = 0.32 samples per symbol = 4

Finding Packets

GNU Radio passes all demodulated data The Access Code starts and ends with either 0101 or 1010

This is used to find packets in the data

000010111110101110101010101010101010101010101010101010101010 101010101011011111001100001011011001100110011111100110100101 100011110010101011111111100000011100000000000000000000011111 111100000011110000111100001111000011110000111100001111000011 110000111100001111000011110000111100001111000011110000111100 001111000011110000111100001111000011110000111100001111000011 110000111100001111000011110000111100001111000000001000011111 000101010011100011101101110011101101001101000100001000101010

Recovering Data

Device specific state

MAC address

Required for frequency hopping pattern Required for frequency hopping pattern Also needed for whitening

Clock value

User data

OBEX file transfer Voice data

The MAC Address

Assigned to manufacturer

Assigned by manufacturer

Split into Lower, Upper and Nonsignificant Address Parts Needed for

frequency hopping establishing connections

NAP+UAP listed in IEEE OUI database

Packet Format

Packets comprised of three parts

Access code Header (including checksum) Payload (including checksum)

Full MAC does not appear in the packet

Although the LAP is part of the Access Code

Unwhitening

Packet whitening is an obstacle to recovering the payload of any packet 64 possibilities small enough to brute force

Generate all 64 possible packets Used fixed/repetitive data to identify correct version Use 6bits of the clock to unwhiten further packets

Extracting the UAP

UAP is used as input to HEC and CRC calculations Both calculations only use XOR and are entirely reversible

Extracting the UAP

Three stage process to find UAP

Unwhiten to produce 64 candidate packet Reverse HEC calculation

generates 64 candidate UAPs A match confirms the UAP and 6bits of the clock

Check CRC on each candidate

Discovering the NAP

NAP completely unused in packet

Have to brute force from 65,536 possibilities

Not required for selection of frequency hopping pattern But, is useful for some attacks

Used for identifying devices Needed for impersonating a device (man in the middle attack)

Discovering the NAP

NAP and UAP together form the Organizationally Unique Identifier

Assigned to device manufacturer Assigned from IEEE MAC address pool

Published OUI database can be used to filter possible NAPs

In practice first byte is often low, 0x02 or lower

Only need to try 256 values for second byte

Some manufacturers are more likely than others to produce Bluetooth devices

Obtaining the MAC

LAP

Read directly from Access Code in the packet Reverse HEC calculation Check result with CRC Search OUI database for UAP Attempt to connect to devices to confirm

UAP

NAP

Using l2ping or hcitool cc

Recovering the LAP and UAP

Discover LAPs being used within range

$./LAP.sh >>> gr_fir_fff: using SSE Found LAP = 0x00fac2

Discover the UAP over 20 packets

$./UAP.sh lap 0x00fac2 Bluetooth UAP sniffer 14 -> Unverified 5b -> Verified by CRC 63 -> Unverified a1 -> Unverified

The Entire MAC Address

Brute force NAP using OUI database and UAP

$NAP.sh uap 0x5b 00-00-5B (hex) 00-02-5B (hex) 00-06-5B (hex) 00-07-5B (hex) 00-0B-5B (hex) 00-0C-5B (hex) 00-13-5B (hex) . . . ELTEC ELEKTRONIK AG Cambridge Silicon Radio Dell Computer Corp. Gibson Guitars Rincon Research Corporation HANWANG TECHNOLOGY CO.,LTD PanelLink Cinema, LLC

CSR and Dell more likely than Gibson Guitars or PanelLink Cinema

Use ping to find out

Eavesdropping an OBEX File Transfer

Use the known LAP and UAP to find and unwhiten packets

./packet_sniffer lap 0x00fac2 uap 0x5b Bluetooth packet sniffer DM1 Slots:1 clock: 32 payload header: 01100110 Start of fragment length = 12 0110011000010000000000000000001000000000110110001111011110010 0000101010101010101010101010101010111110001 Packet CRC:0111000100111000 CRC verified

Future Work

Frequency hopping

Using many USRP devices Using a single USRP device

File transfer (1 way traffic)

Only alternate packets are needed

Phone conversations (2 way traffic)

Requires frequency hopping

Bluetooth V2.0

Frequency Hopping

Problems

Frequency hops every 625s USRP takes 200s to retune GNU Radio buffering Use eight USRP devices to sample the entire range of Bluetooth data

Solutions

Can eavesdrop many connections simultaneously

Only hop to every other frequency GNU Radio will be multi-threaded C++

Conclusions

Bluetooth packets can now be captured without the need for proprietary hardware or firmware It is now possible to discover the MAC address of some undiscoverable devices in under a minute, regardless of implementation Also possible to unwhiten packets without prior knowledge of the clock value