BLE
BLE CTF Walkthrough
Oct 30, 2019
CTF stands for ‘Capture the Flag’, a means for hackers to test their chops in breaching simulated systems with specific securety flaws. As it happens, hackgnar set up a wonderful Bluetooth Low Energy CTF to teach folks about server client interactions over BLE. I highly recommend you approach this from scratch before looking for help, struggling a bit is often the best way to learn. Unfortunately, I’m shit at BASH programming, so I needed to dive a bit deeper to figure out what the hell I was doing, even with a cursory knowledge of BLE. Here is my walkthrough for those of you with a similar knowledge base.
It’s run off of an ESP32 with freely availble firmware from github, or you can buy pre-flashed versions for $20. I tried the latter, got sick of waiting, and went with the former.
I did the CTF in kali, it works nicely. I also used ‘bleah’, a handy BLE enumeration tool that makes everything much more human readable.
enter ‘bleah’ into your terminal to get a nice view of the bluetooth world around us
image
Look for a device labeled BLECTF, and find it’s MAC address. Mine was 3c:71:bf:84:b9:ca
image
Enter bleah -b 3c:71:bf:84:b9:ca -e
-b : connect to a specific mac address -e : ennumerate, make it human readable and pretty
You should get something like this:
image
You’ve made it to the starting line! Several scripts are reccomended to make things easier
submit.sh - a shell script that submits flags to the correct service in order to score points
#!/bin/bash
gatttool -b $MAC –char-wrte-req -a 0x002c -n $(echo -n “$1”
xxd -ps)
gatttool |use gatttool| -b |feed it a mac address| $MAC |Actual mac address of your BLECTF device| –char-write-req|Make a request to write a character| -a |specify writing to a handle| 0x002c |the handle that stores the score| -n |going to be writing a value| echo |display a line of text| -n ?? NEW LINE? “$1” ?? FIRST CHARACTER INPUT | |pipe it!| xxd |hex dump of a text file -ps |Output in a postscript plain hexdump style
BLE Security for the tech illiterate
Sep 2, 2019
For the vast majority of cases, BLE security flaws come from poor implementation of BLE security practices, NOT from weaknesses in the BLE protocol itself. It’s not about making something that is flawlessly secure, that is a pipe dream. The goal is to make something too secure to be worth breaching, a level which LE Secure Connections Mode meets.
Bluetooth Low Energy Security can be a confusing, garbled mess even for the most astute of wireless developers. As the saying goes, the “S” in “IOT” is for Security. In addition, none of the BLE security features are mandatory, meaning you could encounter any combination of the following features in the wild.
In order to start a connection between two BLE devices, they must undergo a process called Pairing. This involves sharing things like keys in order to allow security capabilities such as encryption to be used. Paired devices can store this information for further use, making them bonded.
This process begins with a Pairing Feature Exchange:
Initiator: Sends SMP Pairing Request PDU to Responder
Responder: Replies with SMP Pairing Response PDU
This Tells each device:
-LE Legacy or LE Secure Connections?
-Device Authentication during pairing? What kind?
-Which key types should be distributed and generated?
-What key length should the LTK be?
BLE
In Control
Listening
Gap
Central
Peripheral
GATT
Client
Server
Master
Slave
Initiator
Responder
The request and response PDU: Name Size Function IO Capability What can the device do in terms of input/output. Keyboard only, display only, button only, some combination, none Bonding Flags Whether or not the device wants to store the keys for later use SC Flag 1 bit Supports Secure Connections Pairing MITM Flag 1 bit Requests Authentication as MITM protection OOB Data Flag Sends data over a mechanism other than BLE Maximum Encryption Key Size 7-16 octets (56 to 128 bits) Picks the smaller of the two devices capabilities (must have same size) Initiator Key Distribution LTK, CSRK, and/or IRK Responder Key Distribution LTK, CSRK, and/or IRK
If secure connections can be used, it must be
The Big List of BLE Acronyms:
ATT – Attribute Protocol
BLE – Bluetooth Low Energy
CRC – Cyclic Redundancy Check
CSRK – Connection Signature Resolving Key – used in signing data sent over unencrypted link
DHKey – Diffie Hellman Key
GAP – Generic Access Profile
GATT – Generic Attribute Profile
HMAC – MAC function based upon a hash function
IRK – Identity Resolving Key – used in Bluetooth Privacy feature
LTK – Long Term Key – Used in link encryption
MAC – Message Authentication Codes (Same as MIC)
MIC – Message Integrity Codes (Same as MAC)
MITM – Man in the Middle
NIST – National Institute of Standards and Technology
OOB – Out of Band – Used to exchange keys over non-BLE protocol
PDU – Protocol Data Unit – Single nit of information transmitted
SC – Secure Connections
SMP – Security Manager Protocol
TK – Temporary key – Used in Legacy LE Pairing
Bluetooth for People Not Paid to Care
Aug 16, 2019
Bluetooth Low Energy (BLE) is a low power wireless protocol designed as a cable alternative. It was designed for ease of use and implementation of developers, so as a result can be a bit of a mess.
Bare Minimum:
GAP: Generic Access Profile - How BLE devices discover each other, navigate a way to set up a secure communication channel. These set up the initial connection.
GAP Peripheral: Advertises, accepts connections. (i.e. a fitbit)
GAP Central: Scans for advertising packets, initiates connections (i.e. a smartphone)
There’s also GAP Broadcasters, which advertise but do not accept connections (i.e. a beacon), as well as GAP Observers, which scan for advertising packets, but do not initiate connections (i.e. app looking for beacons)
GATT: Generic Attribute Table - The framework for describing capabilities and descriptors of a BLE device. Made up of Services, Characteristics, and descriptors. This is how connected devices send data back and forth, and the secret sauce of how they work.
Services: Top level, describes what the BLE device does; their primary feature (i.e. heart rate monitor) Contain one or more characteristics. BLE SIG has a long list of predefined services to use in design.
Characteristics: Mid level, individual items of state data. Have a name, a value, and support one or more operations (read/write)
Descriptors: Low level, text description for characteristics regarding content and interaction
Security is covered on a later post