A long, fairly beginner friendly post about attacking a Bluetooth lock, there is a lot of process information here as it was an intern’s research project. What the vulnerability comes down to though is a lack of any real authoization checking instead only validating the integrity (poorly!) of the request and trusting the app did all the heavy lifting.

What they found was that the lock would communicate with the mobile application over bluetooth and the app would communicate over HTTP (not even HTTPS) with the backend API that actually performed most of the actions. tampering with the request resulted in an warning about illegal access to resources. This was because of a custom SecSignDest header containing what appeared to be a MD5 hash. After some digging about how this header was crafted it was a MD5 of the request data (date, data, and path) along with a fixed “OKLOK” string.

Being able to craft their own SecSignDest header was all that was necessary as there was not authorization or authentication checking. So they could go ahead and unbind a lock from the victim’s account and bind it to their own.