This Is Not a Post About BLE, Introducing BLEAH

This is not a post about BLE, but rather on how to hack it … well, to be honest, BLE devices are usually very easy to hack, so it’s just a quick intro to it, I’ll also take the chance to open source one of the last tools I’ve made and that I kept private so far. I moved the features I thought to be dangerous ( aka: auto fuzzing all the BLE things and bring chaos ) in a private fork which will stay private, however it’s not that complicated to chain bleah with other tools ( cough … radamsa … cough ) and have lots of fun.

Oh and this is also because someone asked me some intro on BLE, so yeah, his fault.

For some more detailed (and serious) information, there’s a lot of stuff online already, you know how to Google.

Bluetooth Low Energy - the honest version.

BLE is a cheap and very insecure version of Bluetooth, in which you have no channel hopping (all hail easy sniffing and MITM!) and no builtin protocol security (fuzzing like there’s no tomorrow dudez!), it is mostly used for two reasons:

• Decent batteries are expensive.
• Decent batteries are big.

If you wanna build and sell some IoT-smart-whatever crap, and you wanna do it quickly because your competitor is about to go on the market with the same shit, you take Bluetooth, you strip it from the very few close-to-decent things it has and voilà, you have its retarded little brother which won’t bother the battery too much but will be functional enough to burp random data at you from time to time … easy win, litte R&D efforts, very small production costs.

</rant>

Being the retarded little brother of BT, it doesn’t really take too long to explain how to hack it.

Imagine you have a BT device, which 99% of the times it’s discoverable, on the same frequency and channel, always, that literally burps at you its information ( what it’s called advertisement data, sometimes they also broadcast security tokens, etc … to anyone … ), you connect to it (because 99.999999% of the times it allows anyone to connect) and the device tells you everything you need to know in order to control it, read data from it and write data to it … how kind, isn’t it? :D

You are provided with read and write primitives / channels ( called characteristics ), each one with a specific identifier, some of them are standard and some of them are usually vendor specific, therefore you won’t be able to easily map something like d0611e78-bbb4-4591-a5f8-487910ae4366 to something like Apple Continuity Service (more on how to solve this problem later).

Rather than this, all the implementation details ( aka: the communication protocol ) are up to the vendor … you see now?

Methodologies and required hardware (?)

As I was saying yesterday night to Viss, you can approach BLE hacking in two ways.

You can go passive, therefore you’ll need a Ubertooth One to sniff raw BLE packets out of the air and Wireshark to visualize them. In this case you’ll end up performing signal analysis / RE on the raw bitstream you’ve managed to capture, simply try some replay attack or blackbox fuzzing ( aka: throw mutated stuff back at the mother fucker ). As for this first methodology, there’re already plenty of good examples online, it’s just like sniffing TCP, but with BLE.

Or you can go active (the way I like it :D), and that doesn’t require any specific hardware other than a bluetooth dongle which supports BLE, most likely your Linux laptop already does, and exploit those little bastards for what they are, just retarded bluetooth devices. Find the mobile app (they always have one, they’re smart toys after all), reverse it to find the right characteristics to use for your goal and then just blow the thing up. My point is that you’ll end up reversing “something” anyway, so let it be cheap and effective, right?

Let’s start by verifying if your hardware supports BLE by performing a scan ( I’m assuming you are using GNU/Linux, bluez and all the default BT stack utilities are installed, etc ):

sudo hcitool lescan

If it worked, you’ll see an output like:

LE Scan ...
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF STORZ&BICKEL
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF (unknown)
AA:BB:CC:DD:EE:FF [LG] webOS TV OLED55E6V

That means you’re ready to go. Go find the Android application of the device and reverse it, here’s my 1 on 1 on Android reversing and here you will find a few examples of how to use this approach.

I could now explain you how to read advertisement data using hcitool, how to connect to it using gatttool and how to enumerate services, characteristics and handles, how to mask flags and translate their bits to permissions, etc … but I made it a little bit easier for you (and for me), so let’s skip this boring stuff ok? :P

Introducing BLEAH

BLEAH is a dead easy to use tool, because retarded devices should be dead easy to hack, based on Iah Harvey‘s bluepy python package.

But let me give you some examples and swag.

Scanning for BTLE devices continuously:

sudo bleah -t0

Connect to a specific device and enumerate all the things:

sudo bleah -b "aa:bb:cc:dd:ee:ff" -e

Write the bytes hello world to a specific characteristic of the device:

sudo bleah -b "aa:bb:cc:dd:ee:ff" -u "c7d25540-31dd-11e2-81c1-0800200c9a66" -d "hello world"

Hint: there’s a --data-file argument which is perfect in combination with things like radamsa … just saying.

As usual the public fork of this tool is on github, now you know and have everything you need to bring chaos in the BLE world, enjoy :D