Introduction:
During a recent Security Compass ‘Hack Week’ we decided to take a look at smart locks in an attempt to assess the current state of Smart Lock Security. For our project we decided to take a look at the August Smart Lock. The August Smart Lock is an electronic locking mechanism that can be controlled from a mobile device. It supports Apple and Android platforms and allows the owner to grant access to other smart phones on either a temporary time limited, or permanent basis from anywhere as long as there is internet connectivity. The August Smart Lock is mounted on the back of almost any installed deadbolt replacing the existing thumb latch but leaving the rest of the lock in-tact. In our opinion this makes it a great solution for renters who already have high security locks installed as some of the other smart lock products require a full replacement of the deadbolt and provide only a basic lock cylinder.
There have been several articles written about Smart Locks lately, including this well thought-out piece by Schuyler Towne . We have not, however, seen any reports of thorough security testing carried out on these devices. In the few days we had to play with the August Smart Lock we were able to discover a series of vulnerabilities that would allow an attacker to add themselves as a Guest to any lock they were in range of, effectively giving an attacker the ability to unlock any lock they encounter.
The Mobile Application:
In order to assess the August mobile application we made backups of the application at various states of configuration and use. The application was backed up using Chris John Riley’s ‘ab_unpacker.py’ backup script. when the application was first installed, again once the lock had been provisioned in the application, and finally after several lock/unlock commands had been issued and additional users had been added to the test lock.
An initial assessment of the locally stored files revealed that the configuration data stored on the device is encrypted, however there is a log file present that contains some potentially sensitive data. Analysis of the source code quickly revealed the hardcoded encryption key for the local data:
Figure 1 – Hard coded crypto key in August mobile app
Examination of the encryption routines revealed that the cipher used was AES ECB and this information was used to decrypt the contents of the local data files. These files were found to contain the mobile number, user Email address, lock UUID, etc. however the majority of this data had already been discovered in the plaintext log file created by the application.
The API:
Once we had a good handle on the mobile application we decided to take a look at the API and sniff communications between the application and August’s servers. The application made use of certificate pinning so in order to sniff the traffic we had to decompile the application to .smali, remove the certificate validation code, recompile, sign, and re-install the modified application.
While the majority of the API endpoints did not yield any significant findings at this time, there was one end-point that did not properly validate that the user carrying out the action was a registered owner of the lock. This endpoint happened to be the one that allowed a lock owner to add a guest to their lock. It was discovered that an attacker could craft a request to add themselves as a Guest to any lock, provided they know the lock’s UUID.
Figure 2 – API call to add a limited time guest to a lock
In order to carry out this attack both the attacker’s UserID and the target lock UUID must be known. The attacker’s UserID can be discovered multiple ways – by decrypting the local storage on the attacker’s mobile device, intercepting API calls on the attacker’s mobile device, or simply inspecting the local plaintext application log file.
The target lock UUID can be obtained by approaching an August Lock and using the application to scan for any locks in range. The mobile application will output the discovered UUID to the local application log file on the attacker’s device. The result is that an attacker could easily add themselves as a guest to any August Smart Lock and then simply use the application to unlock the door.
Disclosure & Remediation:
Our findings were disclosed to August on January 30th 2015. August should be commended for their concern and positive reaction to the disclosure. The API was patched within 24 hrs of disclosure. We re-tested the API on February 2nd and confirmed that the endpoint is no longer vulnerable – it now validates that the user making the request has appropriate permissions for that particular lock. We were also informed that a new version of the mobile app would be released within a few weeks of our disclosure to address the information disclosure vulnerabilities. A new version of the app was recently released, but upon re-testing it was discovered to still leak lock UUIDs to the local log file. Being that the API vulnerability has been fixed, the severity of this information disclosure is greatly reduced, but we are hopeful that it will still be corrected in a future release.
Future Work:
Our research focused strictly on the API and mobile application because we only had a few days to work on this. In the future we plan to take a look at the hardware implementation and firmware and are also looking at smart locks from other manufacturers.
About The Authors:
Stephen Hall is a Security Consultant at Security Compass. He has spoken at several conferences including DerbyCon, BSidesTO, and Hack3rcon. Stephen is co-author of the Yasuo tool and is @Logicalsec on Twitter.
Paul Lariviere is a Security Consultant at Security Compass. He is a member of the Toronto chapter of The Open Organisation of Lockpickers (@TOOOL-TOR), has a background in Industrial Control Systems and Embedded development, and is @Dcept905 on Twitter.
