
BlueSteal: Popping GATT Safes - abbeyj
https://www.twosixlabs.com/bluesteal-popping-gatt-safes/
======
ChuckMcM
So to be fair I find the idea of a "blue tooth connected gun safe" to be
something of a weird product to begin with. I think that because I believe a
gun safe serves two purposes; Keeping kids (and others in the house) from
getting access to a gun, and making stealing the gun more difficult or less
useful.

That said, given that I have been approached by, and on occasion done work
for, manufacturers who wanted to add some additional "techno" flair to their
existing product, I have seen requirements documents which were painfully thin
on measurable security requirements. It does not surprise me at all that the
implementation of this system was functional and from a security perspective
quite flawed. What would surprise me is that the company learned from that and
actually upgraded their requirements generating process.

------
simias
Pretending to use encryption when you don't is pretty damning. Everything else
can be blamed on incompetence but it seems hard to imagine that they thought
they were using AES256 when they aren't.

~~~
qwerty456127
I have always believed ALL the BlueTooth connections are encrypted strongly
too. And this is why I thought BlueTooth keyboards are safe while common non-
BT wireless keyboards can be easily sniffed by a neighbour.

~~~
YouKnowBetter
Bluetooth <> Bluetooth. There are (about) 37 distinct profiles [0]. One of
these is HID (Human Interface Device Profile) Keyboard and keypads must be
secure. For other HIDs security is optional.

[0]
[https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles](https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles)

------
danesparza
What kind of a world do we live in where a gun safe requires a firmware update
to patch a security vulnerability?

~~~
kabdib
Don't trust electronic locks.

Years ago I got a safe that wasn't one of the top-end models of its line. In
particular, the manual said that it only had one combination slot.

But other models had more premium features, such as multiple combinations,
"master" and "slave" combos, etc. -- I acquired the manual for them, and sure
enough, these features were present on my cheaper model, with default
combinations. My guess is that anyone could walk up to one of these safes in
someone's home and open it within seconds.

I assume this is well known in the industry. I also have to assume that there
are additional hidden combinations, meant for manufacturer convenience, or put
there with a wink and a nod to the police, or installed by unscrupulous
firmware engineers.

~~~
ufmace
Exactly. This sort of thing is why nobody who owns or uses guns has much
interest in so-called "smart guns". A real security audit on what they're
supposed to accomplish and how they would physically work will show that it's
not a very effective idea.

------
IshKebab
BLE isn't actually totally secure in any mode except OOB pairing, which is
only supported on Android, and only via NFC.

Kind of ridiculous really. I'm pretty sure they didn't make any attempt to fix
the issues in Bluetooth 5 either.

~~~
bschwindHN
What can you do to ensure security on a BLE connection? Do your own key
exchange and encrypt on top of the BLE layer?

~~~
IshKebab
Yeah the only way really is to totally reimplement your own key exchange and
encryption on top of unencrypted BLE. That is an absolute mountain of work
though, unless you happen to have an uncharacteristically powerful BLE device.
I seriously doubt anyone would ever attempt it. Maybe Google would, but last I
looked at their IoT stuff they still hadn't got around to supporting BLE at
all so...

I think the best compromise is to use "just works" pairing which doesn't have
any flaws that I know of, but allows MitM by design. And then add a QR code so
you have at least some vague protection against connecting to the wrong
device.

Oh also there is a 'numeric comparison' authentication method but it requires
your device to have a screen, which is not very common.

~~~
bschwindHN
Okay so I'm implementing a device which connects to Wifi, and I'm using BLE to
hand off Wifi creds from a phone app to the device. This is based on the esp32
chip. They actually have something similar to what I described that they call
"blufi" but it's poorly documented and seems difficult to use:

[http://esp-idf.readthedocs.io/en/latest/api-reference/blueto...](http://esp-
idf.readthedocs.io/en/latest/api-reference/bluetooth/esp_blufi.html)

Right now I'm just using the "just works" pairing as you've described. A QR
code might be a good addition to that, though the product then needs a unique
sticker for each device which is kinda lame. Without the QR code, the threat
model is basically someone eavesdropping on the connection and discovering the
Wifi credentials when the user first sets up the device. Not the worst but
still not great...

~~~
StavrosK
Why use BLE instead of wifi? That's what most devices do (especially with the
ESP8266, which doesn't support BLE).

~~~
bschwindHN
That's a good question, actually. As far as I'm aware, it's not particularly
well supported to programmatically connect to another access point, but that
may have changed recently.

But that aside, using BLE seems like a better user experience. There's no
changing of the user's currently connected access point, and it _might_ be
faster, though I haven't tested.

If I can make the setup over Wifi completely transparent to the user then that
would be acceptable for me. I actually don't own any ESP8266-based devices,
maybe I should buy one and see how it is.

~~~
StavrosK
I don't think the ESP8266 wifi story is different from the ESP32, but it might
be. You do have to connect to another access point, yes, but if you have an
Android app, the app can handle that itself. I think the iOS UX is a bit
worse, though, so BLE might be worth it there.

A lot of firmware for the ESP8266 has been using the access point method, and
it's worked great all the times I've tried it.

~~~
bschwindHN
Yeah the Wifi story is pretty much the same between the two chips. I agree
about Android, I don't think I'd have much problem configuring it there, but
my first focus is on iOS. There seems to be some better support for that in
iOS 11 though:

[https://developer.apple.com/library/content/qa/qa1942/_index...](https://developer.apple.com/library/content/qa/qa1942/_index.html)

So that might be a good option in the near future!

~~~
StavrosK
Ah, great, because when I last looked at an iOS device, the user had to switch
between the WiFi network manually, which was a hassle.

------
erohead
Very informative walk-through of a BT security analysis. Thanks for including
links to tools and clear code snippets.

