Make the smart lock more intelligent (Black off the August smart lock)
Introduction:
In the Security guide released by the hacker Security Week recently held by Security Compass, we decided to study the smart Lock Device and evaluate the current situation of the smart lock. In this project, we plan to study the August smart lock. The August smart lock is an electronic lock device that can be controlled by a remote mobile terminal. It supports Apple devices and Android-based devices. It also allows users to authorize other types of smart phones to access smart locks wherever they are connected, the access method can be temporary access with limited time or permanent access. The August smart lock can be attached to any protected device to replace the existing protection mechanism. The remaining smart locks will be automatically completed. In our opinion, this loading mechanism is a good solution for users with high security smart locks, because other types of smart locks need to replace all existing protection measures, the replacement is just a simple device lock. Recently, several articles have reported smart locks, including Schuyler Towne's well-thought-out conclusion. In any case, we have never seen any report mention such detailed Security Test details on such devices. We have been studying August smart locks over the past few days. We have discovered a series of vulnerabilities on this device. Attackers can exploit these vulnerabilities to identify themselves as visitors, and access any smart lock device they can reach. These vulnerabilities can effectively enable attackers to unlock the smart lock they encounter. Mobile Application: To evaluate the mobile application of the August smart lock, we back up various configuration files and use logs generated when the application is running. When the program is installed for the first time, the program backup uses the AB unpacker of Chris John Riley. py backup script. Once the application configures the smart lock, the new user will be added to the tested Smart lock after several lock unlocking commands are run. After a preliminary evaluation of locally stored files, we found that the configuration record files stored on the device are encrypted, which indicates that these log files may contain some potentially sensitive data. In the analysis of the software source code, we can easily find the key hard-coded encryption code for local data encryption:
Figure 1: AES hard-coded key
In the parsing of the encryption step, we found that the encryption algorithm used by the program is AES and ECB. This information can be used to decrypt the content of the local user data file. These files contain data such as the user's mobile phone number, email address, and user ID of the smart lock. We have found a large amount of such data from the log files created by the program. API interface: Once we have mastered the mobile application of this device, we will study the programming interface of this program, in addition, the data that the application communicates with the server of the August smart lock is sniffed and monitored. The application uses certificate binding, so we have to decompile the application. smail type, remove the certificate verification module, re-compile and install the modified application. Although most programming interfaces in the program did not find many meaningful things this time, there is still a terminal node that does not well verify whether the user's operations belong to a registered smart lock user. This terminal node allows a smart lock user to add a visitor to their smart lock. At the same time, we also found that an attacker could forge a request to add themselves as a visitor to any smart lock device through the user lock ID they obtained.
Figure 2: API terminal node Vulnerability
In order to carry out this attack, we must know the user ID of the attacker and the user ID of the target smart lock. Attackers can obtain user IDs through multiple channels. We can decrypt the local data stored by attackers on mobile devices, or intercept API requests applied by attackers on mobile devices, or directly view the program log files stored locally. The User ID of the target smart lock can be obtained by intruding into the August smart lock device or scanning a certain range of smart lock devices using scanning programs. The mobile app will output the scanned user ID data to the local log file of the attacker's device. As a result, an attacker can easily add themselves as a visitor to any August smart lock and then directly unlock the application. Disclosure and repair: In January 30, 2015, we announced our findings to August smart lock. The company should be commended for their attention to the problem and for their positive response. The API Vulnerability was fixed within 24 hours after it was published. In February 2, we re-tested the API and confirmed that no vulnerability exists on the terminal node. Now, we also confirmed that users who send requests to smart lock devices are given the appropriate permissions. We also learned that a new version of mobile application will be released within a few weeks after the vulnerability is published, in order to fix and handle the public vulnerability. Recently, a new version of the application has been released, but after the program is re-tested, it is found that the program will still leak the user ID of the smart lock to the local log file. Given that the vulnerability of the API interface has been fixed, the severity of the vulnerability information has been greatly reduced, but we still hope that the vulnerability can be corrected and fixed in the next version of the program. Future work: Our research focuses strictly on API interfaces and mobile applications, because we only have a few days to conduct our research. In the future, we plan to study the hardware implementation and hardware devices of smart locks. We will also analyze and study the products of other manufacturers.
