(Old - 5) Messing with BLE
Greetz Internet friend!
So I’ve mentioned a few times so far on this blog that I’ve been on a little vacation for the last week, during which I had a few goals. I wanted to experiment with building a static website with Jekyll, and I wanted to use git because I’d never done a project with it and I wanted to step up my programming to the next level and that required more version control, as well as the ability to easily collaborate. This had the fun unintended consequence of causing me to learn markdown, which I’ve actually (much to my surprised) really enjoyed. I’ve taken notes on what I’ve learned about markdown so far and will turn it into a blog post at a later time.
Besides a website, I also wanted to port an existing exploit to metasploit, and I had one in mind. So I spent a little time building out a virtual environment (since it turns out it’s recommended to be on a Debian based system and I’m on Arch) with vagrant but quickly realized to test the exploit I wanted to build would require finding the version of the vulnerable CMS and installing it on a webserver and that didn’t sound like much fun.
Instead, I’ve had this BLE CTF that was flashed onto an esp32 for the last six months or so, and I’ve never found the time to properly hack on it. So that’s what I’m doing today, and I’m writing this post from a live session of Kali on my hacktop. One thing that’s cool about markdown is that I can do the whole post, save it, and upload it easily when I’m done playing around to somewhere like Google drive and then pull it down when I boot into my regular Arch system later in the day to make final edits and upload the post.
I’ve tried hacking BLE before and not made much headway, so I decided to find a blog to help guide me in the right direction. This article here has some great resources as the end, including this whitepaper which I found tremendously helpful and gave me some good ideas on moving forward with the project. It also gave me an idea. Take notes and make them part of a blog post so I could refer back to the notes later. So without further adieu, here are my notes from reading the previously linked paper on BLE hacking.
Notes from reading the paper
I don’t know if this will be helpful for anyone but myself in the future, but below are my notes from reading the whitepaper I linked to above.
UUID = Universally Unique Identifier - each service and characteristic is identified by one and typically services use short UUID values defined in the Bluetooth spec. Two most commonly used descriptors: 0x2901 (humand readable user description) and 0x2902 (client characteristic configuration”
GATT = Generic Attribute Profile (GATT) - defines a structured list of services, characteristics and attributes of a given application. Reading and writing to characteristics is done according to GATT.
BLE encryption requires devices to undergo a pairing procedure. Options include
- “Just Works” - static pin value: 000000
- Passkey Entry - can be brute forced using Crackle
- Out Of Band - not widely adopted
As of the time of the paper, “Out Of Band” was not widely adopted. In the specification it says “Just Works and Passkey Entry do not provide any passive eavesdropping protection.”
The paper goes on to note that a significant amount of devices don’t implement any security features. Some vendors “do not associate any significant risk with the possibility of intercepting the transmission. So they accept it.”
Although allowed by the standard, the paper notes “with the exception of smartphones and smartwatches, MAC randomization is currently not very widely adopted.”
Interestingly, the paper goes on to note, “a mobile applicatin that interprets advertisements broadcasted by a device can be attacked by advertisement spoofing.” Advertisement attacks can be used for DOS or (more interesting) a man-in-the-middle (MITM) attack.
MITM attacks can do cool stuff like command injection, replay attacks (copy the challenge-response). There are attacks against a module’s interface that allow unauthenticated attackers to change the Bluetooth modules configs. Some devices can be brute forced to figure out the 6 digit password, or use improper random number generators. There may be services available without auth and some devices may be vulnerable to fuzzing or logic flaws.
You could also do attacks on pairing. “Just Works” - the authors note this is probably the most popular paring method - often doesn’t require invoking any action on the device to perform new paring. While connected, the attacker can create its clone and trick the victim application to connect.
to install the tool that was released with the paper, just install npm and type the following npm install gattacker however it appears I don’t know enough about JS to get this working. So I’m going to come back to this later when I understand JS better and move on to using bettercap. Note, perhaps part of my problem was not having a dedicated Bluetooth dongle. I thought my computer had built in bluetooth, but perhaps I just need to invest in a dongle. If you know feel free to holler at me on Twitter
I did a little more digging and it appeared that I was able to use my built in Bluetooth to mess with stuff, but I’m going to talk to some people smarter than I am and see if I actually want to invest in a dongle. Again, if you have some advice and want to point me in the right direction, feel free to holler at me on Twitter.
Additional resources for learning BLE hacking
I personally find watching videos to be a great way to learn, and the first blog post I linked to shared this post and I found it really helpful. As I did for the whitepaper above, here are some notes I took from the talk. Again, mostly to help my future self, but also in the event that the person reading this also finds some benefit in the notes I took.
From the DC24 talk on BLE hacking
- Select the target
- Enumerate it’s services and characteristics
- Reverse the application protocol
- pwn
btmon - this will sniff ble traffic
Suggests reading “Bluetooth Low Energy: The Developer’s Handbook” by Robin Heydon
Mike Ryan’s research lacklustre.net/bluetooth and github.com/mikeryan
Now to what I’m doing with the CTF
Here is the github repo for the BLECTF which includes a link to buying a pre-flashes esp32 microcontroller if you want to play along at home.
First thing I did was fire up btmon so I could catch the traffic and see what I was doing. Then I fired up bettercap and turned on the ble.recon module and the btmon screen more or less exploded. New plan! Take a few minutes to ‘read the fine manual’ for bettercap’s RTFM and see that you can enumerate by the single MAC address and try again.
So I was able to access the device, but it required having the ble.recon module on, which was still nuking my btmon session. Note to future self, look at filtering btmon by MAC address. Then I closed the window with btmon and just entered the following command from my bettercap session:
ble.enum 80:7D:3A:C5:D5:EA which then showed me the scoreboard for the CTF and also activated a cool blue LED on the esp32 board.
I have been having trouble off and on getting gatttool to work, so I have to bring down and back up against my bluetooth interface, and I did that with the following commands
hciconfig hci0 down
hciconfig hci0 up
hcitool dev
hcitool lescan
Then I was able to use gatttool to get the first flag is what I arrogantly wrote, assuming that it was going to work. But it didn’t work. Like so much of my experience with mucking around with BLE, it was flaky and didn’t work right. So I decided to call it a day and go run some errands.
In this end, here are my notes for my session playing with the BLE CTF. Like most of my times playing with BLE, I didn’t have much success, but that’s OK because I often learn more from failing than from success. Anyway, it’s about time for me to head off to the monthly meeting of Irvine Underground - one of the local hacker groups I’m involved with. So on that note I will bid you a fond farewell and a hearty HACK THE PLANET!
Cheers