Upload
oss6000
View
22
Download
0
Embed Size (px)
Citation preview
BlueSniffEve 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 OverviewMaster deviceInitiates 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