Making Smart Locks Smarter (aka. Hacking the August Smart Lock)
By: Paul Lariviere & Stephen Hall
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
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
Figure 1: Hardcoded AES Key
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.
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: Vulnerable API Endpoint
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
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.
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, has his own blog, 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, has a background in Industrial Control Systems and Embedded development, and is @Dcept905 on Twitter.