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 ‘’ 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:

Hardcoded Crypto Key
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.

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.

Vulnerable API Endpoint
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 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, 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.