360lock Smart Lock Review

Two years ago I helped kick start a smart lock, the 360lock. It finally arrived this week. It has different modules like a keybox (below) and a bike chain.

I originally live tweeted the hack on Tuesday Sep 8, 2020.

So, how good is it?

Blockchain integration!

According to the website the 360lock has Blockchain integration:

Thanks to a Blockchain system and advanced crypto codes the level of security is maximum: the lock is completely hacking proof and the operation will be certified on Ethereum!

Also this:

…that’s quite a lot of hype, which spurred me on to see just how hacking proof the device really is.

Keybox

The keybox appears to be made of some flavour of Zamak alloy, so this would not resist a Dremel or hacksaw for more than a few minutes.

The app requires that you register with an email address (or via Facebook or Google) before you can even unlock the device. It accepts weak passwords too.

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.

Here is the bottom of the padlock. 4 star screws? WTAF?

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.

I can definitely feel a void beneath the screw holes.

BLE Investigation time

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

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.

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.

And, here’s the next write – so this looks like my passcode is now 644726

Here’s a sniffed unlock. The next step is to replay it.

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.

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.

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 it.

Oops.

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.

Time for BLE rethink…

I’ve pulled the apk off my phone and loaded it into bytecode viewer. A bit of looking around and the class that handles BLE is a4_storm.com.a360lock.ble

Here are the defined characteristics and they match up with what we saw on the device

The LockBleWrapper class contains all the useful stuff. Here we have the errors which define the sizes of the LockID and Password “lenght”

And the bit that makes the lock/unlock packet. Some notes here – decompiled Java integer constants will always be signed, so -3809 is actually 0xf11f, remember seeing that?

Decoding the method the lock/unlock is now simple. If we combine the previous two packets we sent into one and match the data, where yellow is static, green is the lockID, blue is the password, grey is action (30 = lock) and purple is a one byte CRC.

These means that we can, at the least brute force an unlock in 8 digits – that’s 10^8 guesses. This would take ~31 years to maximally brute force at 1 guess/second. So that’s not a sensible vector for attack (although don’t forget was can sniff the passcode quite easily).

But there is this method where var0 = lockID, var1 = defaultpass (“00000000”) and var2 = new password. Does it check the password is valid?

My mangled packets didn’t work – so it’s time to go back to the app, which I managed to get reworking by uninstalling and reinstalling it. I’m going to stick burp on it and have a look at the API calls.

Okay this is a dead end for now – the app now refuses to talk to my lock; using a new user and it seems the default password is default. The app uses JWT and there aren’t simple IDOR or authorisation errors. It may be time to get physical. Besides, the replay is pretty bad!

Actual brute force

So it’s time to get physical. First off there’s a keybox that gets attached. This is held with the shackle going through a rather small bit of some flavour of Zamak. I know I could hacksaw through it, but can I brute force this (literally)?

There’s a lot of clearance here from a simple spudger. Time for a lump hammer. As @LockPickingLwyr would say “it’s time to go down to the garage”.

I couldn’t find my big lump hammer, so it was just an old, beat up 1 kg one. It took one hit to shear through the connector. Do not use this key box!

There was also a bike “chain”, one of those square ones which is meant to resist bolt cutter.

It looks to made out of a Zamak alloy too. This is how long the bike chain lasted against a bloke with a 1 kg lump hammer:

So dug the dremel and hacksaw out and manage to dig that block out – it was only held in by silicon sealant. So all you need to cut is something large enough to get a screwdriver in the gap.

The main MCU is a nrf51822 Bluetooth and some other 2.4 GHz protocols.

There’s also a TP4056 to manage the cell charging

And a DST1302Z real time clock.

This is pretty much a reference design. There are no debugging pads though :-(. One chip I can’t identify is this one I think it’s the touch and light controller, but it’s really, really small.

Finally, a tip off from @LucaBongiorni drew my attention to the plastic on the front panel, I’d initially ignored this as I couldn’t get a spudger under it, but as I’d already destroyed the lock, what’s the worst that could happen? Two hits with my new favourite mallet, using a screwdriver as an impromptu chisel allowed me to lever up the plastic on the front panel:

Once the four screws are removed you can access the motor and likely spike it from here:

Conclusion

Adding blockchain doesn’t make your smart lock (or smart anything) ‘hackproof’ as a result.

A simple security review would have picked up the BLE replay issue, plus other potential issues. How was this missed?

Lock bodies shouldn’t be made of Zamak and similar alloys. It’s easier and cheaper to cast/machine, compared to steel, but there’s a reason conventional locks use case-hardened metals…

Don’t buy this lock.