Investigating the Plumbing of the IoT Ecosystem (R7-2018-65, R7-2019-07) (FIXED)

Last updated at Fri, 29 Dec 2023 20:13:31 GMT

When poking around for vulnerabilities, researchers often look for some particular low-hanging fruit in order to see first whether the basics in secure design have been covered, then whether they can turn a low-severity vulnerability into something more useful for an attacker.

When assessing IoT in particular, we tend to spend quite a bit of time looking at the enabling technologies around the IoT gadget, rather than the gadget itself. We often can find issues in either the mobile application that's used to control the device or the cloud-based web application that's used to mediate communications between the device and the various consuming endpoints. And, just as in traditional vulnerability research, the goal is often to find some small issue and see whether we can leverage it for something more useful.

Sometimes those small issues are just that—low-severity vulnerabilities that don't seem to lead us anywhere. But, rather than fall into the no-priority bugs trap and just never disclose these issues, we figured this would be a fine time to demonstrate some of the bugs we've come across (in accordance Rapid7's vulnerability disclosure policy, if only to outline some of the design antipatterns other IoT security researchers and IoT application developers might want to watch out for. After all, the IoT device you're looking at might have some similar issue, which you, intrepid researcher, might be able to leverage for more interesting results.

With that goal in mind, what follows is a tale of two IoT products: Eaton’s Home Lighting HALO Home Smart Lighting System and BlueCats’s AA Beacon. As of the time of this disclosure, both BlueCats and Eaton Home Lighting have addressed the issues described.

All of these issues, first discovered and reported by Rapid7 researcher Deral Heiland, range from low- to medium-severity—they don't get attackers very far when it comes to traditional attacker goals like remote code execution or total loss of PII, but they do all represent some level of information disclosure.

R7-2018-65: Multiple BlueCats AA Beacon information disclosure vulnerabilities

The BlueCats AA Beacon system is a Bluetooth Low Energy (BLE) beaconing system, often used to enrich a given mobile application's dataset with location awareness. More about the product offering can be found at the vendor's website.

R7-2018-65.1: Insecure storage of sensitive information: Android mobile application

While examining the Android mobile application ‘BC Reveal’ (BlueCats Reveal v3.0.18), the username and password for access was found stored in clear text in the following file, data/data/com.bluecats.bcreveal/shared_prefs/com.bluecats.bcreveal.xml. An example is shown below:

The persistency of this data was tested by logging out and rebooting the device. Upon logging out, this information was indeed removed. However, the mobile application user will remain logged in until either they purposely log out or the session times out from non-usage, which often can be upward of 30 days, presuming no user activity.

R7-2018-65.2: Insecure storage of sensitive information: iOS mobile application

While examining the iOS mobile application ‘BC Reveal’ (BlueCats Reveal v3.0.18), the username and password for access was found stored in the cache as a base64 encoded string in the following files:

• ./Library/Caches/com.bluecats.BC-Reveal/Cache.db
• ./Library/Caches/com.bluecats.BC-Reveal/Cache.db-wal

An example of this is shown below:

The persistency of this data was tested by logging out and rebooting the device. Logging out and rebooting had no effect, and the critical information remained in both cache files. The primary purpose of the cache is to store information related to the application’s http/https communication to the API web services. Since the base64 encoded username and password are passed as a header in each API call, this data is naturally stored in the cache database files.

Impact of R7-2018-65 (BlueCats)

The insecure storage issues described can lead to a compromise of the affected BlueCats implementation, should the attacker be in a position to compromise the mobile device (iOS or Android), either through some physical, local attack, or via some other malware installation on the device.

Vendor statement for R7-2018-65 (BlueCats)

"IoT solutions only deliver on their immense promises if every system element and touchpoint is architected with a security-first mindset. The team at BlueCats fully embrace this mindset, and continue to develop cutting-edge solutions for Industry which deliver results and provide trust throughout the entire chain.

"BlueCats appreciates Rapid7's research efforts and professionalism, and we addressed the discoveries as a priority. Moreover, this exercise was a great example of the security community raising awareness about critical considerations for any IoT solution."

Remediation for R7-2018-65 (BlueCats)

Users are advised to update to the latest version of the mobile application for their BlueCats devices through either Google Play or the Apple App Store. In most cases, these updates are automatic, but users are urged to check for the latest versions, released in May 2018, if there are any concerns about updating.

Disclosure timeline for R7-2018-65 (BlueCats)

• Monday, Jan. 7, 2019: Initial disclosure to the vendor
• Monday, April 15, 2019: Disclosure to CERT/CC (VU#264421)
• Tuesday, April 23, 2019: Acknowledgement of receipt by the vendor
• Monday, May 6, 2019: CVE-2019-5626, CVE-2019-5627 reserved
• Wednesday, May 8, 2019: Acknowledgement of remediation underway by the vendor
• Wednesday, May 15, 2019: Version 5.14 of the iOS mobile app released
• Thursday, May 17, 2019: Version 3.0.19 of the Android mobile app released
• Tuesday, May 21, 2019: Public disclosure via publication of this blog post

R7-2019-07: Multiple HALO Home Smart Lighting information disclosure vulnerabilities

HALO Home Smart Lighting is provided by Eaton Lighting and is marketed for use in private residences. More about the product can be found at the vendor's website.

R7-2019-07.1: Insecure data storage on Android

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 ‘Halo Home’, the OAuth authentication and refresh tokens for access were found stored in clear text in the file location, /data/data/com.halohome/shared_prefs/com.halohome.xml.

A portion of this file is shown below:

The persistency of this data was tested by logging out and rebooting the device. Upon logging out, this information was removed. However, the nature of the mobile application means the user will often remain logged in until either they purposely log out or the session times out from inactivity (which can often be after upward of 30 days).

R7-2019-07.2: Insecure Direct Object Reference at radar.XXX-XX.com

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, malicious actors can bypass authorization and access resources in the system directly (e.g., database records or files).

While initially examining the calls made to https://radar.XXX-XX.com/track?uuid=aaa80b409cb48188 from the mobile application, it was discovered that the last 25 records posted to the site via the API call were viewable without authentication, if the user's UUID was known, shown below:

Further examination revealed that if the GET request is made without specifying the UUID, as in https://radar.XXX-XX.com/track?uuid, the service would return the last 25 records, which contain information on a number of different users. This appeared to be based on order of connection to this API by various users’ mobile application. The data returned contained the following types of records:

• Email address
• User's UUID
• BRIDGE_MAC_ADDRESS
• Mobile device version data

The BRIDGE_MAC_ADDRESS, in particular, is leveraged in the third issue described here.

R7-2019-07.3: Insecure Direct Object Reference at api.XXX-XX.com

Unauthorized access to other users' data can occur when access rights to data are not properly restricted to the data owner. As a result of this vulnerability, malicious actors can bypass authorization and access data records of users via a record identifier.

To validate this issue, two separate user accounts and product ecosystem were set up and configured for testing purposes.

By leveraging the BRIDGE_MAC_ADDRESS data that was harvested from the R7-2019-07.2 issue described above, an authenticated user can query data about another user’s lighting devices by making a request to https://api.XXX-XX.com/abstract_devices/119fbd941cd?state=true.

An example of this is shown below:

Please note that the BRIDGE_MAC_ADDRESS is actually the lighting devices’ BLE Media Access Control (MAC) address modified. The modifications consist of swapping the actual BLE MAC address’s first two octets with the last two octets. For example, if the actual device BLE MAC address is 88d03906c733, then the address used for device identification in the APIs is c733390688d0. In this example, we can see that the first four characters, 88d0, are swapped with the last four characters, c7333.

Information on a user’s bridge device can also be queried if the device’s MAC address can be determined. The bridge device is a hardware appliance used to make the BLE lights accessible over the internet.

The current status of a user’s light can be determined by making a request to the following URL with the modified MAC address of the device: https://api.XXX-XX.com/devices/119fbd941cd6/state

Impact of R7-2019-07 (HALO)

By leveraging the service vulnerabilities (R7-2019-07.2 and R7-2019-07.3), attackers can learn private information about potential targets, such as the registration email address, the unique identifier of the HALO Home Lighting System, and ultimately, the on/off status of the lighting system, from anywhere reachable from the internet. While it is usually trivial to tell whether a person's home lights are on when nearby, these issues allow malicious actors to determine this information at scale and at range.

The insecure storage issue described in R7-2019-07.1 can allow an attacker to impersonate the legitimate user by reusing the stored OAuth token, and could then inspect and change personal information stored by the mobile device on the backing cloud service. Note that the attacker would need to either gain physical control of the Android device or compromise the Android device with a malicious app.

Remediation for R7-2019-07 (HALO)

The vendor has issued a patch to remediate the first issue and to retain compatibility with the service fixes for the second and third issues. Users should update their HALO Home app after April 15, 2019 in order to get the updated version of the application.

Disclosure timeline for R7-2019-07 (HALO)

• February 2019: Issues discovered by Deral Heiland
• Wednesday, Feb. 27, 2019: Initial disclosure to Eaton through its vulnerability handling program
• Wednesday, March 20, 2019: Update from the vendor regarding patch plans at the end of April
• Wednesday, April 3, 2019: Disclosed to CERT/CC, VU#529267
• Monday, April 15, 2019: HALO Homeversion 1.11.0 released to address CVE-2019-5625
• Tuesday, May 21, 2019: Public disclosure via publication of this blog post
• Tuesday, May 21, 2019: Vendor advisory published