Recently, the Rapid7 security research team discovered multiple security vulnerabilities in the Hickory Bluetooth smart series BlueTooth Enabled Deadbolt locks. The vulnerabilities involve its mobile app and cloud-hosted web services and MQTT protocol.As of the vulnerability disclosure deadline, Hickory had not acknowledged these vulnerabilities nor released any patches or fixes.
Introduction to Hickory Smart Bluetooth Enabled Deadbolt
The Hickory Smart Bluetooth Enabled Deadbolt is a smart lock designed to be installed over traditional locks, product model H076388-SN, which contains electronic components certified by FCC ID 2AEHJSRU233. It is a fundamental IoT device that Rapid7 focused on testing.It can be controlled by Android and iPhone/iPad devices through its mobile app, and it is cloud-hosted for its related web applications and MQTT middleware proxy/server.The versions of the Hickory mobile application tested by Rapid7 were Android 01.01.43 and iOS 01.01.07, both named “Hickory Smart,” available for download from Google and Apple app stores.Additionally, the Hickory Smart Ethernet Bridge model H077646 was also utilized in the tests.The tested lock devices were sourced from Hickory Hardware’s official products, and the mobile applications were developed by Delphian Systems, the upstream vendor of Hickory Hardware, which also manages the related cloud servers and MQTT services.Below are the vulnerabilities discovered by Rapid7.
Vulnerability Information
R7-2019-18.1: Insecure Data Storage in Android Mobile Application (CVE-2019-5632)
Some mobile applications store personal sensitive information such as usernames and authentication tokens on mobile devices for later use. If this information is not encrypted or password-protected, other users on the system may be able to access this sensitive information.
Upon examining the Hickory Android mobile application, we found unencrypted SQLite data in the /data/data/com.belwith.hickorysmart/databases directory, which contains key information for users to remotely control the lock device:
Importantly, when the current user logs out of the application and then restarts it, the aforementioned information still exists and is not deleted.
R7-2019-18.2: Insecure Data Storage in iOS Mobile Application (CVE-2019-5633)
Similar issues were found in the iOS application. In the directory /private/var/mobile/Containers/Data/Application/3CAC91D1-872C-4F96-9460-A93F770AC42D/Library/Caches/com.belwith.HickorySmart, we found unencrypted remote unlocking information related to the user:
R7-2019-18.3: Logging Enabled in Android Mobile Application (CVE-2019-5634)
Debug logs are used for development and troubleshooting. Once the application is product-ready, debug functionalities and related logs should be disabled and deleted to prevent sensitive information leakage.In our tests, all network API services and lock connections made through the mobile application via Bluetooth were logged in the HickorySmartLog/Logs/SRDeviceLog.txt debug log, which was stored on the mobile device’s SD card and could be accessed by any file viewer without any root device operations, as shown below:
R7-2019-18.4: Inadequate API Access Control Vulnerability
Testing revealed that any authorized user of the lock could query the API to extract the IDs of all authorized users (AuthorizedUserDevice IDs). This means that one user could control the lock using another user’s identity.These AuthorizedUserDevice IDs are generated during the mobile application’s runtime or account configuration process, and the lock device does not enforce any expiration or change requirements on them.Below is a post request to the API querying SRDeviceUpdate, and the lock’s response message includes all current authorized user IDs – AuthorizedUserDevice IDs, which also comes from the debug log in the previous vulnerability “SRDeviceLog.txt.”
R7-2019-18.5: Deregistered Users Still Have API Access
Tests found that if a user’s account is disabled or deregistered, they can still make requests to the cloud-hosted API to regain control of the lock’s ID information, as shown below:
R7-2019-18.6: Plaintext Credential Transmission (CVE-2019-5635)
During testing, we discovered through Wireshark that the Hickory Smart Ethernet Bridge device communicated with the MQTT remote protocol broker without encryption, which could lead to the exposure of usernames and passwords used for authentication with the MQTT broker, as shown below:
Conclusion
Except for the last vulnerability, malicious attackers could exploit several of the other vulnerabilities to manipulate the Hickory Smart Bluetooth Enabled lock, posing risks to the safety of Hickory users’ persons and property.When such locks are widely procured for use in certain IoT systems, the impact could be extensive and dangerous.
Vulnerability Reporting Process
2019.5 Vulnerability discovered
2019.5.16 Reported vulnerabilities to Hickory Hardware
2019.6.25 Reported vulnerabilities to Hickory’s upstream vendor Delphian Systems
2019.7.1 Reported vulnerabilities to CERT/CC
2019.7.2 CERT/CC assigned vulnerability number
2019.8.1 60-day vulnerability deadline passed, Rapid7 disclosed vulnerabilities
Original source:FreeBuf
