Multiple vulnerabilities in Wink and Insteon smart home systems

Last updated at Thu, 29 Aug 2024 20:20:41 GMT

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and the Insteon Hub uses an unencrypted radio transmission protocol for potentially sensitive security controls such as garage door locks.

As most of these issues have not yet been addressed by the vendors, users should ensure mobile devices enable full disk encryption if possible, and avoid the use of these products for sensitive applications until the vulnerabilities are patched. While the potential impact is high, these vulnerabilities are not exploitable over the internet: access to the user's phone, or close proximity to connected devices in the replay case, is required for exploitation. This post provides additional details on the vulnerabilities and steps users can take to protect themselves.

Wink: Android app authentication token storage and API authentication token revocation vulnerabilities

Two issues related to authentication were discovered in the Wink Android mobile application and related API:

• CVE-2017-5249, R7-2017-19.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Wink Android application to authorize user access was not stored in an encrypted and secure way.
• R7-2017-19.2, CWE 613 (Insufficient Session Expiration): when users log out of the Wink Android application, the authentication token used for that session is not revoked, nor does the generation of new tokens revoke older ones. There is no way currently for users to see all valid authentication tokens connected to their account, but there is a method available to revoke all authentications aside from their current one (detailed below). No CVE was assigned to this issue, as remediation would likely be done on Wink's servers.

Product Description

Wink Hub 2 is a smart home system designed to help consumers manage multiple home IoT products and protocols from various vendors. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page.

Credit

These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy.

R7-2017-19.1

Details and Exploitation

During analysis of the Android mobile application for Wink (Wink application version 6.1.0.19 on Android 5.1 running kernel 3.10.72), it was discovered that the OAuth token is stored unencrypted within the following file: /data/data/com.quirky.android.wink.wink/shared_prefs/user.xml

To determine the longevity of this preference file, the Android device was rebooted, after which the unencrypted OAuth token shown in Figure 1 below was still present. It was determined that the token remained until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in, however. Thus the authentication tokens are likely to stay valid indefinitely, unless the user doesn't interact with the application for more than 30 days.

Remediation

A vendor-supplied patch for the mobile app should be provided to prevent storing potentially sensitive information, such as authentication tokens, in cleartext. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used.

[Updated Sept 22, 2017]
The latest version of the Wink Android application, v6.3.0.28, fixed the authentication storage issue. This was released on Sep 13, 2017. Users should update to this version immediately.

Users should also consider enabling full-disk encryption (FDE), and be sure to log out of the Wink application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable.

R7-2017-19.2

Details and Exploitation

Further examination of the Wink app's use of OAuth revealed that the normal user logout process does not include OAuth token revocation. When the user logs out from the mobile application, it only sends a delete request for the mobile device tracker in specific (as shown in Figure 2 below). This tracker plays no direct roll in the authentication process.

When the user logs back in, they are assigned a new OAuth token. However, testing showed that the previous OAuth token still remained valid. To further validate the security of this, the user's password was changed, at which point revocation of that user's tokens was expected. The system rebooted, but the original OAuth token still remained valid, as shown in Figure 3:

This means that if a user loses their mobile device, or if it is stolen, a malicious actor could extract the unencrypted OAuth token from the user.xml file, giving the malicious actor full access to the Wink Hub 2 remotely.

Remediation

A vendor-supplied patch should be provided to revoke the user's OAuth token after logout from the mobile application. In addition, a mechanism should be added to allow for the revocation of all tokens across all mobile devices with access to the user's Wink Hub 2. This would help prevent unauthorized access to the device and services even if a device is lost or compromised.

[Updated Sept 22, 2017]
Wink reports that they plan to address this issue in the near future through a server-side change.

[Updated Sept 26, 2017]
Users are currently able to force a log out of other user sessions. This can only be done by going to change your password, and then selecting the "Log Out Others" option presented in figure 4:

This step will invalidate all associated OAuth tokens, except for the one currently in use by the user. This lowers exposure greatly, as it is much less likely for an attacker to have that current token, rather than an older one.

We recommend users change their password and log out other sessions associated with their account to avoid exposure. If users are able to view sessions associated with their account in the future, they should review that regularly.

R7-2017-19 Disclosure Timeline

• Wed, Jul 19, 2017: Initial contact with Wink
• Wed, Jul 20, 2017: Wink acknowledged receipt
• Fri, Jul 28, 2017: Details disclosed to Wink
• Mon, Jul 31, 2017: Wink acknowledged Android token issue, plans to fix
• Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5249 for R7-2017-19.1
• Mon, Aug 14, 2017: Disclosed to CERT/CC
• Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0
• Fri, Sep 22, 2017: Wink confirmed that R7-2017-19.1 was fixed on Sep 13, 2017, and that they intend to fix R7-2017-19.2 in the near future.

Insteon Hub: Unencrypted credential storage and radio replay vulnerabilities

Two issues related to authentication and radio transmission security were discovered in the Insteon Hub:

• CVE-2017-5250, R7-2017-20.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Insteon Android application to authorize user access is not stored in an encrypted and secure way.
• CVE-2017-5251, R7-2017-20.2, CWE 294 (Authentication Bypass by Capture-replay): the radio transmissions used for communication between the Hub and connected devices are not encrypted, and do not provide sufficient protections to guard against capture-replay attacks.

These issues can be used to compromise and control an Insteon Hub environment.

Product Description

The Insteon Hub is a smart home system designed to help consumers connect various home IoT products and manage home automation. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page.

Credit

These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy.

R7-2017-20.1

Details and Exploitation

Analysis of the Android mobile application for Insteon Hub (Insteon application version 1.9.7) revealed that the account and password for both Insteon services and the Hub hardware was stored unencrypted within the following file: /data/data/com.insteon.insteon3/shared_prefs/com.insteon.insteon3_preferences.xml

To determine the longevity of this file, the Android device was rebooted, after which the plaintext username and password shown in Figures 1 and 2 below was still present. It was determined that the account credentials remained in the file until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in.

Remediation

A vendor-supplied patch should be made to the mobile app to prevent storing sensitive information, such as user credentials, unencrypted. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used.

Absent a vendor-supplied patch, users should consider full-disk encryption (FDE), and be sure to log out of the Insteon Hub application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable.

R7-2017-20.2

Details and Exploitation

The Insteon Hub uses radio signals to communicate with connected devices, specifically a 915MHz Frequency Shift Keying (FSK) communication protocol. Analysis of this protocol revealed that the transmissions do not appear to be encrypted, nor to contain any security mechanisms to prevent replay attacks. A malicious actor can easily capture and replay the radio signals at any time to manipulate any device being managed via this communication protocol.

To test the Insteon Hub's security against replay attacks, an Insteon Garage Door Control Kit (Device 43) was configured via an Insteon Hub (2245-222). Using software-defined radio (SDR), the 915MHz radio signal used to open and close the door via the Garage Door Control device was captured. Once captured, the signal was filtered to remove background noise and then replayed to successfully actuate the Insteon Garage Door Control device. This confirmed that the Insteon RF protocol is vulnerable to replay attacks, and is shown in Figure 3 below:

Remediation

A vendor-supplied patch should be provided to configure the 915MHz signal to encrypt the data being communicated, or to apply a rotating certificate to prevent replay of captured RF signals.

Absent a vendor-supplied patch, users should avoid using the Insteon's radio-control features with security-related and access control devices if they are concerned about potential radio eavesdroppers.

R7-2017-20 Disclosure Timeline

• Wed, Jul 19, 2017: Initial contact with Insteon
• Wed, Jul 20, 2017: Insteon acknowledged receipt
• Fri, Jul 28, 2017: Details disclosed to Insteon
• Mon, Jul 31, 2017: Insteon acknowledged receipt, intent to review
• Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5250 for .1 and CVE-2017-5251 for .2
• Mon, Aug 14, 2017: Disclosed to CERT/CC
• Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0