Read on Twitter
So three years ago I kickstarted a smart lock (360lock). It finally arrived this week. It has different modules like a keybox (below) and a bike chain.
How good is it? 1/
How good is it? 1/
The keybox appears to be made of some flavour of Zamak alloy, so this would not resist a Dremel or hacksaw for more than two minutes 2/
The app requires that you register with an email address (or via Facebook or Google) before you can even unlock the device. It does accept weak passwords too 3/
I have a sniffed BLE connection of initialisation and the first couple of unlocks which I will go into later, but first I need to show you something. 4/
Here is the bottom of the padlock. 4 star screws? WTAF? 5/
After removing the screws, the bottom panel appears to be glued on, I'm trying to not stab myself and lever it up, but the gap is small, I may come back to this after I dremel it open. 6/
I can definitely feel a void beneath the screw holes. 7/
So onto my other laptop to look at BLE. A tip @cybergibbons gave me was that Wireshark can work through ADB to pull the hci logs directly from an Android phone, so you can view BLE traffic in Wireshark through. Let's have a look 8/
Nordic TX/RX, oh this is going to be easy... So I suspect data will be written through the TX characteristic and read via notification on the RX characteristic.
Here is is setting up to listen to notifications by setting the CCCD for the RC characteristic 10/
So here's the first write and its corresponding notification. We can start to see patterns. The 1234560000000 in the body and the response of 644726 seems to be some sort of passcode. In the app it did mention changing the password. 11/
And, here's the next write - so this looks like my passcode is now 644726 12/
Here's a sniffed unlock. The next step is to replay it. 13/
Bit of a delay here as my Kali instance doesn't like gatttool, so I went to a Fedora one. After I did the below commands it popped open. The first packet is authorisation, the second the open command. So it is vulnerable to replay attacks 14/
Right time for coffee and then I'll have a look at the app. 15/
Quick detour through some BLE recon. Here are the services. the ones with a UUID of 1800 and 1801 are the standard BLE descrptions. 0x8e400001 is nRF OTA and 0x6e400001 is nRF serial. 16/
Here are the characteristics, the first three are standard BLE ones. Handle 0xb is OTA and 0xf and 0x12 are the RX and TX ones. But look at those permissions - the ones for handle 3 have read and write permissions - -we can rename this bugger 17/
Oops 18/
Now it's worth messing around with doing stuff that you shouldn't be able to, as GATT permissions for a characteristic are only in the metadata. The underlying GAP attribute may have totally different permissions. So look at the TX and RX characteristics. 19/
Those are notify on handle 0xf and write and write without response on 0x12. Can we read from them? Yes, it turns out we can, so GAP and GATT permissions don't match. In theory we can read the passcode back directly here 20/
And the app appears to have broken. I will have to start another thread in a couple of hours once I've got this working again. 21/21
