Last updated at Thu, 01 Aug 2019 13:38:08 GMT

Rapid7 offers IoT Security Testing Services as part of our portfolio of assessment services, and as a result, from time to time, our researchers uncover IoT vulnerabilities in hardware, mobile apps, and cloud infrastructure as part of ongoing academic efforts. This disclosure represents one such independent, non-contracted project.

The Hickory Smart BlueTooth Enabled Deadbolt IoT ecosystem (which includes mobile applications as well as a cloud-hosted web and MQTT infrastructure) has several vulnerabilities, as detailed in the table below. As of the initial release of this vulnerability disclosure, the vendor has not acknowledged these vulnerabilities, nor has it offered a software update to address these issues.

Identifier Vulnerability Component CVSSv3 Score CVE
R7-2019-18.1 CWE-922: Insecure Storage of Sensitive Information Mobile App (Android) Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) CVE-2019-5632
R7-2019-18.2 CWE-922: Insecure Storage of Sensitive Information Mobile App (iOS) Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) CVE-2019-5633
R7-2019-18.3 CWE-532: Inclusion of Sensitive Information in Log Files Mobile App (Android) Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) CVE-2019-5634
R7-2019-18.4 CWE-284: Improper Access Control Web API Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) None
R7-2019-18.5 CWE-286: Incorrect User Management Web API Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) None
R7-2019-18.6 CWE-319: Cleartext Transmission of Sensitive Information Mobile/MQTT Server Medium: 6.5 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) CVE-2019-5635

What is the Hickory Smart Bluetooth Enabled Deadbolt?

The Hickory Smart Bluetooth Enabled Deadbolt (Model H076388-SN, which contains electronic components with FCC ID 2AEHJSRU233) is the base IoT device that was the focus of this testing. It is supported by mobile applications for Android and iPhone/iPad devices, as well as cloud-based, hosted web applications and a hosted MQTT broker/server. The mobile applications under test were version 01.01.43 for Android and 01.01.07 for iOS. Both are called "Hickory Smart," in the Google Play store and the Apple App store. In addition, the Hickory Smart Ethernet Bridge H077646 (Model SRR533) was used in testing.

These devices are products provided by Hickory Hardware, a Belwith Products brand, although it appears that another company, Delphian Systems, is the upstream provider for the hosted web and MQTT services. Delphian Systems may also provide the development and maintenance of the mobile applications.

Who discovered these IoT security vulnerabilities?

These issues were discovered by Deral Heiland, a security researcher at Rapid7. They are being disclosed in accordance Rapid7's vulnerability disclosure policy.

How are these vulnerabilities exploited?

This section outlines the six security issues discovered in the Hickory Smart Bluetooth Enabled Deadbolt IoT ecosystem:

R7-2019-18.1: Insecure storage on Android vulnerability (CVE-2019-5632)

Mobile applications may store information on the mobile device, which the application can retrieve later. This could be application-related data or other sensitive information such as usernames, authentication tokens, or personal details.

If this information is not encrypted or password-protected, another user on that system could gain unauthorized access to the user's confidential information. A malicious actor with physical access to a device could also compromise this sensitive data.

While examining the Android mobile application, critical data was found stored unencrypted in the SQLite database SecureRemoteSmartDB.sqlite in the directory /data/data/com.belwith.hickorysmart/databases. The database was found to contain information that could be used to control the lock devices remotely. An example of this data is shown in the figure below:

To validate the persistency of the data on the devices, the user was logged out and the devices were rebooted. It was discovered that none of the data identified above was removed.

Mitigation for R7-2019-18.1 (CVE-2019-5632)

An update to the app should be provided by the vendor that leverages the Android keystore system to protect the app's sensitive data. Without such an update, malicious applications or users can trivially extract this data. Furthermore, the app should be updated to regularly purge temporarily saved sensitive data, such as during a reboot or a sign-out of the application.

In the absence of an update from the vendor, users should set a device PIN, password, or pattern in order to protect the app's insecurely stored sensitive data in the event of a lost or stolen device. Of course, users should also avoid installing malware on their devices, as this data is also available to any other mobile application.

R7-2019-18.2: Insecure storage on iOS vulnerability (CVE-2019-5633)

A nearly identical finding to R7-2019-18.1 was found in the iOS version of the mobile app, where it was discovered that sensitive data was stored persistently in the Cache.db database at the path /private/var/mobile/Containers/Data/Application/3CAC91D1-872C-4F96-9460-A93F770AC42D/Library/Caches/com.belwith.HickorySmart, as shown in the figure below:

Mitigation for R7-2019-18.2 (CVE-2019-5633)

Mitigation recommendations are identical for R7-2019-18.1. An update should be provided by the vendor that utilizes the keychain services provided by Apple, and users should protect their mobile device with an appropriate locking mechanism.

R7-2019-18.3: Logging enabled on Android vulnerability (CVE-2019-5634)

Debug logs are used for development and troubleshooting issues within an application. Once the application goes into products, these features should be disabled to avoid the exposure of sensitive information.

During testing, all communications to the internet API services and direct connections to the lock via Bluetooth Low Energy (BLE) from the mobile application were being logged in a debug log on Android device at HickorySmartLog/Logs/SRDeviceLog.txt. This information was found stored in the Android device's default USB or SDcard storage paths and is accessible without rooting the device. It is easily accessed via any file access application on the mobile device, as shown in the figure below:

It's important to note that a user given any level of access to remote control the lock, even on a temporary basis, could use this log data to gain unauthorized access at a later time.

Mitigation for R7-2019-18.3 (CVE-2019-5634)

An update should be provided by the vendor that disables application debug logging, or at the very least, carefully avoid logging sensitive data.

R7-2019-18.4: Improper API access control vulnerability

It was discovered that any user granted access to the lock could also query the API to extract all AuthorizedUserDevice IDs. These, in turn, allow access to control the assigned locks, as other users. These AuthorizedUserDevice IDs are created and assigned during application and account setup and do not appear to expire or change. If AuthorizedUserDevice IDs are compromised, the lock owner would need to reinstall all authorized applications and delete all existing accounts.

The figure below shows an API POST to SRDeviceUpdate, which returns all AuthorizedUserDevice IDs currently assigned to the lock. Note that this data is also captured in the debug log “SRDeviceLog.txt “ on Android devices by default (see R7-2019-18.3).

Mitigation for R7-2019-18.4

As this appears to be a web service issue, the vendor should update the web service to limit the response data to this API call in order to not disclose other AuthorizedUserDevice IDs. In addition, the service should generate new, unique AuthorizedUserDevice IDs and expire old IDs after a reasonable period.

In the absence of a vendor-supplied update, users should not rely on the temporary access features of associated locks, as any user can leverage temporary access into permanent access.

R7-2019-18.5: Disabled users retain API access

It was found that a user whose account had been disabled (presumably, to prevent lock access), could still make calls to the hosted web application APIs and retrieve critical data such as the AuthorizedUserDevice IDs, as shown below:

Mitigation for R7-2019-18.5

The vendor should update the web application to prevent the API from returning sensitive data to disabled user accounts.

In the absence of a vendor-supplied update, users should not rely on account disabling to prevent unauthorized access to the lock.

R7-2019-18.6: Cleartext credential transmission (CVE-2019-5635)

During testing, network communication was captured using the popular packet capture application Wireshark. Captured data revealed that the Hickory Smart Ethernet Bridge device was communicating over the network to an MQTT broker without using encryption. This exposed the default username and password used to authenticate to the MQTT broker, as shown below:

While we were able to uncover this username and password to the MQTT service associated with the cloud-hosted infrastructure, it's unclear what exactly an attacker would be able to do with this password, as all other data appeared to be encrypted or encoded or otherwise obfuscated.

Mitigation for R7-2019-18.6 (CVE-2019-5635)

The vendor should update the Bridge and the MQTT service to require the use of normal TLS encryption.

In the absence of an update, the vendor should not rely on the username and password to remain secret.

The impact of the Hickory Smart Bluetooth Enabled door lock vulnerabilities

In all but the last of these identified vulnerabilities, a malicious actor could ultimately operate the associated Hickory Smart Bluetooth Enabled door locks just as the valid owner could. This, in turn, may present a physical risk to the people and property protected by these locks. As mentioned in R7-2019-18.6, it's unclear at the time of disclosure what the MQTT issue impacts from the user's or vendor's point of view, but generally speaking, it's unwise to share usernames and passwords in cleartext over the internet. At a minimum, MQTT services should use SSL/TLS wrapping to avoid exposure over the network.

Note that, in all cases, some level of access to an already associated mobile device is required to exploit these issues. That said, the design of the device's IoT ecosystem assumes that some access to mobile access will be provided to some users on a temporary basis (for example, when a homeowner provisions access to a temporary house sitter, or a short-term renter through a service such as Airbnb or HomeAway). The impact of all these vulnerabilities would extend this "temporary" access to a much more permanent, and largely untraceable, level of access to the associated door locks.

Remediating these IoT vulnerabilities

The vendor should update both the end-user mobile application as well as the hosted web and MQTT services in order to address these issues. As of the writing of this disclosure, the vendor has not acknowledged to Rapid7 receipt of these vulnerability reports, nor have they issued software updates.

In the absence of vendor-supplied patches, users of these iOS and Android applications and their associated door locks should take care to not share access with people who should not have long-term, permanent access to the protected property.

Regardless of updates provided by the vendor, mobile devices should be protected with a unique PIN, password, or pattern in order to prevent the accidental disclosure of sensitive passwords and tokens in the event the mobile device is lost.

Disclosure timeline

  • May 2019: Issues discovered by Deral Heiland of Rapid7
  • Thursday, May 16, 2019: Initial disclosure to Hickory Hardware
  • Tuesday, June 25, 2019: Initial disclosure to Delphian Systems
  • Monday, July 1, 2019: Disclosed to CERT/CC
  • Tuesday, July 2, 2019: CVE IDs reserved, CERT/CC assigned VU#414075
  • Thursday, Aug. 1, 2019: Public disclosure deadline (planned, 60+ days past May 16)

Learn more about our IoT security testing services

Get Started