Full Report
Locks being controlled by computers are great, until you realize that they are subject to security vulnerabilities like everything else. This post goes through hacking a smart lock through various techniques. The system has a single global AES key that is used to communicate with the lock. Although there is client side protections for giving and taking keys, since they have the AES key this doesn't matter. The authors realized that a MitM attack was possible to get an encryption challenge and response by spoofing the locks information, since it will only hold a single connection at a time. By having our device get this open, we can advertise our fake lock only to get a victim app to connect to it. The authentication process uses a challenge to communicate with the lock. This challenge value is only 16 bit integer. By trying to authorize with our encrypted message from the MitM, getting a 1/65536 chance then sending back the challenge response, we will become authenticated! This takes several seconds per attempt, resulting in several days for this to work. When performing the decryption of the AES encrypted data, the code needs to know how many iterations to do. To find this out, it takes the length of the buffer and divides it by 16. However, it doesn't check if they are in groups of 16. So, by sending a non-divisible value of 16, such as 15, the decryption won't occur on those bytes. What does this mean? We can trick the process to process our plaintext data as decrypted. Abusing a different authentication, we can use vulnerability to trick the authentication process. The app has an original version of the protocol. With this, the only encryption is a 1 byte repeating XOR key, such as 0xABAB.... It's possible to downgrade a user with a MitM to force this version of the protocol. Again, amazing. The lock has another device called a gateway. This is used for internet communication. By spoofing a MAC address when talking to a server, it's possible to force a re-registration to reset some parts of the key material. This does require knowing the MAC address, which is difficult to get. There is support for a wireless keypad to connect to the lock. Since the communication key is hardcoded for this initially, all users can send data here now problem. They can now send key presses over a single connection, which speeds up the process drastically. The code uses the strstr function as well, so de Bruijn sequences can be used to make this even more efficient. There is a lockout for failed attempts here though. There is a second Bluetooth service being advertised. This literally allows for updating the firmware without any signature checks. That's game over. Most of the time, debug ports are good for reverse engineering. In this case, the debug port is on the part of the board that is on the onside of the lock. So, if an attacker drilled a small hole in the lock, they could communicate with the debug port. With debug access, we would have complete control over the lock. There are many, many classic cryptography issues within this. Downgrade attacks, brute forcing... many awesome things! This also shows that cryptography isn't always crazy complicated; just understanding some basics is helpful for exploitation.
Analysis Summary