"Bluetooth Low Energy is probably the most thriving technology implemented recently in all kinds of IoT devices: gadgets, wearables, smart homes, medical equipment and even banking tokens. The BLE specification assures secure connections through link-layer encryption, device whitelisting and bonding - a mechanisms not without flaws, although that's another story we are already aware of. A surprising number of devices do not (or simply cannot - because of the use scenario) utilize these mechanisms. The security (like authentication) is, in fact, provided on higher ""application"" (GATT protocol) layer of the data exchanged between the ""master"" (usually mobile phone) and peripheral device. The connection from ""master"" in such cases is initiated by scanning to a specific broadcast signal, which by design can be trivially spoofed. And guess what - the device GATT internals (so-called ""services"" and ""characteristics"") can also be easily cloned.  Using a few simple tricks, we can assure the victim will connect to our impersonator device instead of the original one, and then just proxy the traffic - without consent of the mobile app or device. And here it finally becomes interesting - just imagine how many attacks you might be able to perform with the possibility to actively intercept the BLE communication! Basing on several examples, I will demonstrate common flaws possible to exploit, including improper authentication, static passwords, not-so-random PRNG, excessive services, bad assumptions - which allow you to take over control of smart locks, disrupt smart home, and even get a free lunch. I will also suggest best practices to mitigate the attacks. Ladies and gentlemen - I give you the BLE MITM proxy. A free open-source tool which opens a whole new chapter for your IoT device exploitation, reversing and debugging. Run it on a portable Raspberry Pi, carry around BLE-packed premises, share your experience and contribute to the code." (Source: Black Hat USA 2016, Las Vegas)

2. Hacking challenge: steal a car!

3. Your "local partner in crime"
Sławomir Jasek
• IT security expert
• since 2005, and still loves this job
Agenda
• BLE vs security
• How to hack the car
• New tool
• Vulnerabilities examples
• Smart lock
• Anti-theft device
• Mobile PoS
• Other gadgets
• What can we do better

4. Bluetooth Smart? (aka Low Energy, 4.0...)
• Probably most thriving IoT technology
• Wearables, sensors, home automation,
household goods, medical devices, door
locks, alarms, banking tokens, smart
every-things...
• Completely different than previous
Bluetooth

5. BLE (v4.0) security: encryption
• Pairing (once, in a secure environment)
• JustWorks (R) – most common, devices without display cannot implement
other
• 6-digit PIN – if the device has a display
• Out of band – not yet spotted in the wild
• Establish Long Term Key, and store it to secure future communication
("bonding")
• "Just Works and Passkey Entry do not provide any passive
eavesdropping protection"
Mike Ryan, https://www.lacklustre.net/bluetooth/

6. BLE (v4.0) security in practice
• 8 of 10 tested devices do not implement BLE-layer encryption
• The pairing is in OS level, mobile application does not have full control over it
• It is troublesome to manage with requirements for:
• Multiple users/application instances per device
• Access sharing
• Cloud backup
• Usage scenario does not allow for secure bonding (e.g. public cash register, "fleet"
of beacons, car rental)
• Other hardware/software/UX problems with pairing
• "Forget" to do it, or do not consider clear-text transmission a problem

7. BLE (v4.0) security in practice
• Security in "application" layer (GATT)
• Various authentication schemes
• Static password/key
• Challenge-response (most common)
• PKI
• Requests/responses encryption
• No single standard, library, protocol
• Own crypto, based usually on AES
Controller (firmware)
Link layer
Physical layer
Host (OS)
Host Card Interface
L2CAP
SMP ATT
GATT
UNENCRYPTED

9. Satisfies regular users, but how about you?

10. So, how to hack the BLE car lock?
• Remote relay?
Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
http://eprint.iacr.org/2010/332.pdf

11. So, how to hack the BLE car lock?
• Remote relay?
• Jamming?
• Brute force?
Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
http://eprint.iacr.org/2010/332.pdf

12. So, how to hack the BLE car lock?
• Remote relay?
• Jamming?
• Brute force?
• BLE sniffing?
• Mobile app
analysis?
• ...
• MITM? http://greatscottgadgets.com/ubertoothone/

13. Man in the Middle?
Alice
Bob
Mallory

14. How to MITM: isolate the signal?

15. How to MITM?
Stronger signal?
• Class 1 adapter? +8dBm, 100m range
"little difference in range whether the other
end of the link is a Class 1 or Class 2 device
as the lower powered device tends to set
the range limit"
https://en.wikipedia.org/wiki/Bluetooth
More signals?
And how to handle them in a single system?

16. Typical connection flow
Advertise
Connect the advertising device (MAC)
Start scanning for advertisements
Specific advertisement received,
stop scanning
Further communication

17. MITM
Start scanning for advertisements
Advertise more
frequently
MITM?
Keep connection to
original device. It
does not advertise
while connected ;)
Specific advertisement received,
stop scanning
Connect the advertising device (MAC)
Further communication

18. New tool - architecture
Gather
advertisement
and services
data for
cloning
Keep
connection to
original device
forward
req/resp
Advertise
Get serv
servicesData
interception
and
manipulation
Advertise
(high freq)
Offer exact
services
Forward
req/resp
Get serv
services
websockets

19. New BLE MITM Tool – a must have for IoT tester!
• Open source
• Node.js
• Websockets
• Modular design
• Json
• .io website
• And a cool logo!

20. Car hacking challenge: authentication
Get "Challenge"
Commands (Open, Close...)
Random challenge
AES("LOGIN",AES(Challenge,key))
AES("LOGIN",
AES
(Challenge,
key
NOT ENCRYPTED: Open, Close...

21. Authentication: attack?
Open
AES("LOGIN",
AES
(Challenge,
key
Other cmdMITM
Get "Challenge"
Random challenge
AES("LOGIN",AES(Challenge,key))

22. Other commands (based on mobile app):
• setEngineBlockadeSetting – turn on/off
• setBlinker – blinker sequence unlocking engine
• initConfigMode – initiate the configuration – overwrite the
passwords
• initiateDataTransfer – dump the whole configuration (including all
passwords)

23. PRNG?
- Is there any function which allows to generate a random number?
- There is no function to do this. However, there is a reasonably good
alternative (...), which reads the module's serial number and uses the two
least significant bytes, then triggers a channel 14 (temperature) ADC read
and combines the two with some very basic math* to generate a sort of
"multiplier seed" which can be used for randomness.
* (multiplication of the values by themselves)
https://bluegiga.zendesk.com/entries/59399217-Random-function

24. Smart lock
• Challenge-response, session key
• Commands encrypted by session key
• Challenge looks random
• Ranging: GPS-enabled, you have to leave the area and return
• What could possibly go wrong?
• Let's take a look at the details...

25. Smart lock - protocol
Get "Challenge"
Challenge
SESSION KEY =
AES(Challenge,
KEY
Commands AES-encrypted by session key

26. Smart lock - protocol
Get "Challenge"
Challenge
SESSION KEY =
AES(Challenge,
KEY
Close lock
OK, closed
MITM
(intercept,
record,
pass
through)

27. Smart lock – attack
Get "Challenge"
Challenge (previously intercepted)
SESSION KEY =
AES(Challenge,
KEY
Close lock
OK, closed (repeat the encrypted)
MITM
(replay)
The same as
recorded session

28. Smart lock – attack v2
Get "Challenge" MITM
Do not forward
req to device.
Advertise status
"Closed"
STALL
CLOSED

29. Smart lock – DEMO

30. Smart lock: AT commands
• BLE module AT interface exposed

31. AT commands

32. AT commands

33. AT commands

34. Fallback to analog key may be unavailable...

35. DEMO: AT commands

36. DEMO: Anti-thief

37. DEMO: interception – static password

38. DEMO: Mobile PoS

39. But what about BLE encryption?
Bond – encrypted communication

40. "Just Works"
Bond – encrypted
communication
MITM
Bond – encrypted
communication
?

42. Remove pairing, new connection with MITM
Bond – encrypted
communication
MITM
Bond – encrypted
communication
New connection

43. PIN entry – trick into pairing again, sniff, crack
Bond – encrypted
communication
MITM

44. Passive
interception of
pairing process
Crack the PIN
using crackle
PIN entry – trick into pairing again, sniff, crack
Bond – encrypted communication

45. Some attacks
• Denial of Service
• Interception
• Replay
• Authentication bypass
• Proximity actions
• Misconfiguration/excessive
services abuse
• Logic flaws
• Badly designed crypto
• Brute force
• Fuzzing
• ...

46. Risk? It depends...
• Your pulse indication will not have any significance for
by-passing people
• But an adversary may be extremely interested in it
during negotiations
• Or, if it is used for biometric authentication in banking
application
http://www.ibtimes.co.uk/fears-barack-obamas-new-fitbit-fitness-
tracker-represent-national-security-risk-1492705
https://www.theguardian.com/technology/2015/mar/13/halifax-trials-
heartbeat-id-technology-for-online-banking

47. How to fix the problem?
• Use the BLE encryption, bonding, random MACs properly
• Do not implement static passwords
• Design own security layers with active interception
possibility in mind
• Beware excessive services, misconfiguration
• Prepare fallback for Denial of Service
• ...
• More details in whitepaper

48. Q&A?
More information, these slides, whitepaper, videos, tool source code:
slawomir.jasek@securing.pl