Team82 has researched the security of the OvrC cloud platform, which is used by businesses and consumers to remotely manage IoT devices.
We uncovered 10 different vulnerabilities that, when chained, allow attackers to execute code on OvrC cloud-connected devices, remotely over the cloud.
OvrC Pro and OvrC Connect are affected; updates were released in May 2023 via ICSA-23-136-01 for eight vulnerabilities, and the two remaining issues were addressed in an update announced today: CISA's advisory is here.
Attackers successfully exploiting these vulnerabilities can access, control, and disrupt devices supported by OvrC; some of those include smart electrical power supplies, cameras, routers, home automation systems, and more.
We appreciate and thank SnapOne and CISA for coordinating the disclosure.
There are certain commonalities when the cybersecurity of internet-of-things (IoT) devices is researched and discussed. Manufacturers have long treated the security of these connected things as an afterthought, failing to prioritize the use of strong authentication and access controls, or relying on weak or outdated protocols for device communication to the cloud, and avoiding costly encryption implementations for data security.
Why? Some manufacturers may pressure developers to get features and functions out the door quickly, and opt to address vulnerabilities, code defects, and other bugs as they’re disclosed. IoT devices have shorter lifecycles than their IT, or certainly OT, counterparts, further supporting this dynamic of features first and security later. There are other reasons too around complexity, a lack of security expertise, and bottom-line costs that force device makers to put less focus on cybersecurity.
While there may be some validity to all of these reasons, the fact remains that as more so-called smart devices are connected to the internet and managed via a cloud-based interface, attackers are going to seek out and exploit weaknesses that put critical services, user data, and businesses at risk.
That’s the context behind Team82’s latest research, an analysis of the OvrC cloud platform, a cloud-based remote management and monitoring platform. OvrC was acquired in 2014 by SnapOne, a North Carolina-based company founded in 2005 by a group of technology integrators focused on automation technology, specifically around smart IoT devices. OvrC is used by businesses and consumers alike to remotely configure, monitor, and troubleshoot devices, through a mobile application or a websocket-based user interface. OvrC supports devices ranging from smart home automation endpoints, smart electrical switches, smart cameras, routers, and more. According to an OvrC webinar from 2020 around 9.2 million devices were monitored by the platform, so it’s safe to assume that the vulnerabilities we reported affected around 10 million devices world-wide.
Our research uncovered 10 vulnerabilities in OvrC Pro, which provides visibility, troubleshooting, and diagnostic data for remote management of devices, and OvrC Connect, the company’s mobile app that enables initial troubleshooting and management capabilities.
Many of these issues we found arise from neglecting the device-to-cloud interface, a pattern we've observed in numerous other IoT platforms. In many of these cases, the core issue is the ability to cross-claim IoT devices because of weak identifiers or similar bugs. These issues range from weak access controls, authentication bypasses, failed input validation, hardcoded credentials, and remote code execution flaws.
An attacker remotely exploiting these vulnerabilities would not only be able to bypass perimeter security such as firewalls and network address translation (NAT) in order to gain access to the cloud-based management interface, but would also be able to enumerate and profile devices, hijack devices, elevate privileges, and run arbitrary code.
SnapOne and OvrC addressed eight of these vulnerabilities in May 2023, and the remaining two today.
OvrC’s cloud platform allows users to remotely manage, configure, and troubleshoot supported devices, including smart home automation endpoints (e.g. Control4), smart electrical switches (e.g. Wattbox), smart cameras (e.g. LUMA), routers (e.g. Araknis), and many more.
Cloud users can interact and control their devices using a custom UI interface. For example, users can turn their smart electrical switches on or off, get live feeds from their indoor cameras, and disable network ports on their routers.
Luma Surveillance camera: Designed for residential and commercial use. Using OvrC, asset owners can remotely monitor and control these cameras.
Control4: These devices are designed to connect and control various things in a home, such as lighting, audio, video, security, and climate control. Using OvrC, asset owners can remotely use home automation controls to manage devices.
Zebra printers: Specialized printers commonly used for printing labels, barcodes, and receipts in industries such as retail, healthcare, and logistics. OvrC can integrate with Zebra printers, allowing technicians to remotely monitor printer health, perform diagnostics, and manage settings, which improves operational efficiency by reducing onsite support needs.
Wattbox devices are smart power-management units used to control and monitor power for connected devices, often in audio-visual and IT setups. They integrate with OvrC, allowing remote monitoring, rebooting, and control of outlets to troubleshoot issues and improve device uptime without needing physical access.
In addition to OvrC enabled devices, the OvrC cloud platform can integrate with third-party devices, even if those devices do not support the OvrC platform directly. For example, the OvrC cloud supports Roku devices, allowing users to start applications on their TVs. OvrC has a long list of supported third-party platforms, each with varied supported functionality.
As part of device initialization, all devices that support OvrC register with the cloud on startup. Then, in order to link a device to its owner, a user has to “claim” their devices, using secrets only accessible to the device owner. Those secrets include the device MAC address and serial number.
The OvrC cloud platform has two main user types:
System Integrator: An integrator creates a setup of smart devices, linking the devices and claiming them through the OvrC cloud. Then, while having full control over those devices, in case technical support is needed, the system integrator provides access to some basic control functionality over those devices to the end user.
End-User: Consumers managing their own devices, without the use of a system integrator.
The OvrC cloud exposes two main communication interfaces: a user-facing web/mobile app interface for controlling devices, and a websocket-based device-facing interface used for device communication between the cloud platform and managed devices.
In our research, we demonstrate how attackers can use a chain of vulnerabilities identified in both the user-facing and device-facing communication interfaces in order to find devices connected to the OvrC cloud and overtake them, gaining full control.
The short answer is yes—we can. However, reaching this conclusion wasn’t straightforward and required significant effort along the way. Here are the major milestones we reached to finally be able to do so:
Finding all the edge IoT cloud-connected devices
For each device, check if it’s already claimed by another user?
If so, force the cloud to disconnect it from the account, i.e. “unclaim” it
Claim the device and force-connect it to our account
Control the IoT device via the OvrC cloud
Bonus: RCE via the Hub (will be explained later)
Here’s a simple diagram that shows the RCE path whether the device is already connected to another user or not:
We even built an internal PoC tool that does all the heavy lifting for us and lands us with a sweet shell as root:
We discovered that by default all devices try to reach out to OVRC’s cloud immediately whenever they are connected, meaning even if users do not manually opt-in to use OVRC cloud, their devices are still part of the OVRC cloud as “unclaimed” devices, making them vulnerable to the vulnerabilities we discovered.
Furthermore, in our research we discovered that we can fabricate and impersonate any OvrC cloud-connected device we want. We could send messages to the cloud on behalf of any device just by knowing its MAC address (which is not a secret).
Communication Interface: User <--> Cloud
Route: /v1/devices/find?macAddress=MAC_ADDRESS
In the OvrC platform, a MAC address is used to identify devices in some cases. Like most other devices, the MAC address of OvrC-enabled devices is composed of two parts, starting with three bytes identifying the device manufacturing vendor, an organizationally unique identifier (OUI). For example, SnapOne’s SnapAV OUI is D4:6A:91.
Following the first three bytes, the last three bytes are used to identify the device itself, and should be a random value. This means that from each company, the number of possible devices is at most 8*3=24 bits (224=16,777,216), which is a relatively small number and is easily guessable by attackers.
A sample MAC address could look like this, where the information in blue is the manufacturer prefix, and the green is the device suffix part:
D4:6A:91:11:22:33
While identifying a device using its guessable MAC address is not a vulnerability on its own, we discovered that the OvrC servers react differently when users supply specific MAC addresses.
When we supply a MAC address, OvrC servers will return a different result whether the device is already claimed, unclaimed, or does not exist.
This discrepancy in responses allows attackers to identify and profile all possible devices by simply using the device’s MAC address, which can be easily brute-forced.
Using the /v1/devices/find?macAddress=MAC_ADDRESS vulnerable route, we can observe a discrepancy between responses and infer the device status in the following manner:
Device Doesn’t Exist: The response contains an empty manufacturer.
Device Claimed: The response contains the device’s manufacturer and an error message
Device Unclaimed: The response contains the device model
Using this simple technique, we can scan and enumerate all cloud-connected devices, and determine their status, whether they exist, and whether they are claimed by a user.
Communication Interface: User <--> Cloud
Route: /v1/devices/confirm
In order to assure only the owner of a device could claim it and gain control over the device, OvrC requires a user to present a few secrets about the device in the claiming process, only accessible to the owner. Those secrets are the device MAC address (which as we’ve shown before, could be easily guessed), and the device serial number, which is a unique identifier that is not guessable, and can only be found on the label printed on the back of the device. This means that only someone with physical access to the device can claim it.
In theory, one should not be able to claim a device they do not own because they don't have the serial number. However, we were able to discover a way to claim arbitrary unclaimed devices, bypassing the requirement for a serial number.
This vulnerability exists in the following route: /v1/devices/confirm. This route, instead of checking both the device MAC address and serial number, claims (returns the device ID used in the claim route) the device without requiring the serial number. Furthermore, when chained with the vulnerability described above, attackers gain the ability to forcibly claim all unclaimed devices, taking unauthorized ownership over many devices.
Using this route, a malicious actor could simply provide a device’s MAC address (which is easily guessable and enumerable, as shown in the vulnerability above), while still gaining ownership over the device.
Communication Interface: Device <--> Cloud
Websocket Command: dsUnclaimHub
The vulnerabilities we showcased so far only allow attackers to claim unclaimed devices, but do not allow takeover of already claimed devices. This led us to look for a method of unclaiming a device, and then taking ownership over it using the vulnerabilities showcased above.
The OvrC Hub is a device by Snap One that enables remote management of network-connected devices. It provides integrators with tools to monitor, troubleshoot, and control various devices on the network, supporting both Snap One and compatible third-party devices. It’s often used in AV and IT setups to perform tasks such as rebooting devices, updating firmware, and diagnosing network issues without the need for on-site visits.
The Hub is managed by the OvrC cloud and is supposed to centralize and manage nested devices connected to it, creating a small sub-system of devices. This means that as part of the OvrC business logic, some devices could be managed by this Hub entity, and this entity is responsible for those devices.
This discovery of the Hub device type made us think, if devices could be registered under a Hub, could it in turn be used to unclaim those devices? As it turns out, this is the case.
One command that a Hub can send to the cloud is the dsUnclaimHub, which is used to unclaim all of the devices under a Hub. When the OvrC cloud receives this command, it does not check whether the given devices are actually linked to the Hub and “unclaims” those devices immediately. Since this is a websocket action, this only requires the device MAC address.
This means that by impersonating a Hub, we can simply send the dsUnclaimHub command and unclaim devices arbitrarily. By abusing this vulnerability and then using the vulnerability allowing us to claim unclaimed devices, we could simply unclaim any device we want and claim it again, gaining ownership over arbitrary devices.
Communication Interface: Device <--> Cloud
Command: dsUpdateFoundDevices
A similar vulnerability identified in the Hub functionality set is the ability to reclaim already-claimed devices, essentially taking over devices owned by other users. One of the OvrC Hub functionalities is the ability to scan the network it is connected to, and automatically sync and manage all OvrC enabled devices present in the network.
Behind the scenes, the Hub sends a dsUpdateFoundDevices command through the websocket device-cloud communication interface. This command (which is a part of a larger process of commands) basically notifies the OvrC cloud that the Hub managed to find and manage a new device, and that it should be added to the list of devices under this Hub. In return, the server claims this “found” device, adding it to the list of managed devices under the user which owns the Hub.
However, when the OvrC cloud receives this dsUpdateFoundDevices request, it does not validate the given found devices, and doesn’t check whether those devices are already managed by other users. Abusing this improper validation, a malicious actor could simply impersonate a Hub and send the corresponding dsUpdateFoundDevices request, claiming already claimed devices.
We demonstrated that it’s possible to take over any cloud-connected device and claim it to our account. In this context this means we can fully control the remote IoT device and use its functionality—if it’s a web camera we can view the live stream, if it’s a smart power outlet we can turn off the outlets and if it’s a smart printer we can print remotely. From an attacker’s perspective that’s usually enough, but we wanted to see if remote code execution from the cloud is possible too.
Hub devices have their own locally running web server. This web server is accessible from the local network and remotely using the OvrC cloud. This means we can remotely access the web interface of any Hub device we want by force-claiming it using the previously mentioned vulnerabilities.
When researching the authentication method of the Hub web server, we discovered that a built-in, hidden user exists in the system: the Superuser. This user is not visible to the end-user, and has access to all of the device’s management commands, holding the highest privileges possible.
When looking at the password generation for this user, we were surprised to find out that the user’s password is composed of easily-known variables, being the MAC address and the ServiceTag (ST) of the device. Both are visible and can be gained from the OvrC cloud platform in which the device is associated with since we claimed it to our account.
Superuser username: <MAC Address>
Superuser password: <ServiceTag>
Using this knowledge, we can easily retrieve the password for this Superuser account: the ServiceTag, and in turn authenticate and gain valid credentials for the Hub’s web server.
When connecting to the secret Superuser account, a new functionality is opened in the web server, a Superuser only diagnostics tool. This tool is actually an arbitrary command launcher, allowing the Superuser user to execute arbitrary commands on the hub device.
In general, allowing users to execute arbitrary commands on a device from a web server is considered a bad practice, because it means that being an admin on the web server allows you to achieve RCE on the server. We can infer that this is not a valid feature of this device, because it is hidden and accessible only to the Superuser account and not to all admin accounts in this platform.
With more devices coming online every day and cloud management becoming the dominant means of configuring and accessing services, more than ever, the impetus is on manufacturers and cloud service providers to secure these devices and connections.
Our research into OvrC demonstrates how an attacker can chain a handful of vulnerabilities to access, disrupt, or manipulate IoT devices. In this case, we were able to enumerate all devices managed by OvrC, claim devices using known—and unknown—secrets, and also impersonate or take them over. In some cases, we were able to execute arbitrary code.
The negative outcomes can impact connected power supplies, business routers, home automation systems and more connected to the OvrC cloud. Our research demonstrates common security vulnerabilities and weaknesses prevalent across IoT and how attackers can make the most of them.
Our disclosure has helped to improve the security of the OvrC platform; they have addressed all 10 vulnerabilities we reported to them. We would like to acknowledge and thank SnapOne and the Cybersecurity Infrastructure and Security Agency (CISA) for their attention to our disclosure and publication of informative advisories and updates.
CWE-20 Improper Input Validation
The Hub in the Snap One OvrC cloud platform is a device used to centralize and manage nested devices connected to it. A vulnerability exists in which an attacker could impersonate a hub and send device requests to claim already claimed devices. The OvrC cloud platform receives the requests but does not validate if the found devices are already managed by another user.
CVSS v3: 8.6
CWE-204 Observable Response Discrepancy
When supplied with a random MAC address, Snap One OvrC cloud servers will return information about the device. The MAC address of devices can be enumerated in an attack and the OvrC cloud will disclose their information.
CVSS v3: 5.3
CWE-284 Improper Access Control
Snap One OvrC cloud servers contain a route an attacker can use to bypass requirements and claim devices outright.
CVSS v3: 8.6
CWE-319 Cleartext Transmission of Sensitive Information
Snap One OvrC Pro versions prior to 7.3 use HTTP connections when downloading a program from their servers. Because they do not use HTTPS, OvrC Pro devices are susceptible to exploitation.
CVSS v3: 7.5
CWE-345: Insufficient Verification of Data Authenticity
Snap One OvrC Pro devices versions 7.2 and prior do not validate firmware updates correctly. The device only calculates the MD5 hash of the firmware and does not check using a private-public key mechanism. The lack of complete PKI system firmware signature could allow attackers to upload arbitrary firmware updates, resulting in code execution.
CVSS v3: 8.6
CWE-601: URL Redirection to Untrusted Site
Devices using Snap One OvrC cloud are sent to a web address when accessing a web management interface using a HTTP connection. Attackers could impersonate a device and supply malicious information about the device’s web server interface. By supplying malicious parameters, an attacker could redirect the user to arbitrary and dangerous locations on the web.
CVSS v3: 7.1
CWE-798 Use of Hard-Coded Credentials
Snap One OvrC Pro versions prior to 7.2 have their own locally running web server accessible both from the local network and remotely. OvrC cloud contains a hidden superuser account =accessible through hard-coded credentials.
CVSS v3: 8.3
CWE-912 Hidden Functionality
In Snap One OvrC Pro versions prior to 7.2, when logged into the superuser account, a new functionality appears that could allow users to execute arbitrary commands on the hub device.
CVSS v3: 8.3
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
