WarezTheRemote: Turning Remotes into Listening Devices

WarezTheRemote used a man-in-the-middle attack to exploit remote’s RF communication with the set-top box and over-the-air firmware upgrades – by pushing a malicious firmware image back the remote, attackers could have used the remote to continuously record audio without user interaction.

The attack did not require physical contact with the targeted remote or any interaction from the victim – any hacker with a cheap RF transceiver could have used it to take over an XR11 remote. Using a 16dBi antenna, we were able to listen to conversations happening in a house from about 65 feet away. We believe this could have been amplified easily using better equipment.

We worked with Comcast’s security team after finding the vulnerability and they have released fixes that remediate the issues that made the attack possible.

You can download our full research paper for the technical details of the WarezTheRemote project. You’ll find much more information on the reverse-engineering process inside, as well as a more bits-and-bytes perspective on the vulnerability and the exploit.

Background

Our day-to-day research at Guardicore focuses mostly on enterprise network security. Most of the time this doesn’t lead us to home devices; however, set-top boxes piqued our interest because they connect directly to cable providers’ datacenters – they’re not quite part of the datacenter, but they aren’t completely external, either. We thought we could gain some insight into cable providers’ networks by experimenting with these boxes.

As part of this research, we found a way to open a shell over Ethernet on an Xfinity X1 set-top box. Although this required physical access to the box’s hardware, it was still interesting from a security perspective, since these boxes are distributed to customers’ homes – a home user could potentially take advantage of this capability to start snooping around Comcast’s cable network. After reporting the issue to Comcast (which owns the Xfinity brand) we decided to look at the XR11 voice remote it came with.

The XR11 has a microphone button that you can press and hold to issue voice commands to the set-top box. This offers users a convenient way to change channels, search for TV shows, find recommendations, and more.

Another relatively modern feature of this remote is that it communicates with the set-top box over radio frequency (RF) rather than the more traditional infra-red (IR) that you see more often on television remote controls. This has a couple of advantages: the remote doesn’t have to be pointed directly at the cable box in order to work, and it functions properly even when it is obstructed or far away from the TV.

The combination of recording capabilities with RF-based communication led us to believe that the XR11 can be of particular interest to an attacker: RF enables contact with the remote from afar, which makes for a larger attack surface than a remote control would otherwise have, and the recording capability makes it a high-value target. Furthermore, a prior disclosure from the CableTap research project showed that these remotes have an over-the-air firmware upgrade capability, and that the firmware images need not be signed for the remote to install them. (To the best of our knowledge no one has published any meaningful use of this issue up until now.) This meant that if we could find a way to upload our own malicious firmware image to the remote, we might be able to abuse its microphone to run continuously and exfiltrate the recorded audio.

As the CableTap exploit relied on the remote being paired to a set-top box controlled by the attacker, it essentially required physical access to both the remote and the box: pairing is performed by manually entering an on-screen PIN from the remote. We hoped to get around this limitation by attacking the firmware upgrade mechanism over RF. Next, we wanted to implement a full exploit that would effectively transform the remote into a listening device.

The vulnerability

By extensively reverse-engineering both the remote’s firmware and the corresponding software it communicates with on the set-top box, we were able to find a vulnerability in the way the remote handled incoming RF packets.

The remote communicates with the set-top box over a protocol named RF4CE (Radio Frequency for Consumer Electronics), which is a subset of the Zigbee family of power-saving RF protocols. RF4CE has a feature named “security”, which in practice encrypts the contents of RF4CE packets.
In theory this encryption should have prevented an external attacker from injecting his or her own packets into the connection. As it turned out, though, in the XR11’s implementation, RF4CE security is set on a packet-by-packet basis. Each RF4CE packet has a “flags” byte, and when one of its bits is set to 1, security is enabled for that packet, and its contents will be encrypted. Likewise, if the bit isn’t set, the packet will be sent in plaintext.

The vulnerability was that the original XR11 firmware didn’t verify that responses to encrypted requests are encrypted as well. This means that if an attacker within RF range had responded to outgoing (encrypted) requests from the remote in plaintext, the remote would have accepted the spurious responses. Because of this bug, if an attacker had guessed the contents of a request from the remote, they could have easily formulated a malicious response to that request.

An attacker could have taken advantage of this behavior to impersonate the set-top box that the remote control was paired with. For example, you could have answered the remote’s periodic check for a firmware upgrade with a spurious positive answer. Compounded with the vulnerability from CableTap, which allowed installation of an unsigned firmware image, this meant an attacker could remotely force the installation of a firmware image of their choice to the remote.

By default, the XR11 remote’s firmware queries the box it is paired with for a new firmware once every 24 hours. The request packet is encrypted, so an attacker can’t actually read its contents, but there is a non-encrypted byte in the packet’s header that indicates that this request is firmware-related, which allows the attack to guess its contents without actually decrypting it.

Normally, the box would respond to this request by saying that no new firmware is available. However, with our plaintext packet, we could have told the remote that there is, in fact, a new firmware image available, and the remote would have accepted our answer.

Following this initial exchange, the remote sends out a series of requests asking for the contents of the firmware image, chunk by chunk. Each request asks for a specific offset and length. Normally the box would decrypt these requests and send the corresponding chunk. However, in our case, we can’t decrypt these requests.

As it turned out, though, the order these chunk requests are sent in is entirely predictable, which allowed us to guess which chunk of the firmware the remote is asking for. By carefully timing our responses, we were able to send exactly the right firmware chunk to the remote each time.
Furthermore, we found a way to temporarily crash the software running on the cable box using a malformed RF4CE packet. This simple DoS prevented the box from interfering over the course of the attack.

As this attack literally flashes the remote’s firmware, we decided to name it WarezTheRemote. We implemented a full proof-of-concept of a malicious firmware upgrade using this method.

First, we tried a very minor change to the original firmware – changing the color of one of the LEDs on the remote. Then we proceeded to take over the microphone.

Exploiting the microphone

By further reverse-engineering of the remote control’s firmware, we were able to find the code that handles the recording button; this triggers the microphone and streams the recorded audio over RF. For our purposes, though, we wanted to trigger this behavior when the button isn’t pressed, too. Ideally, recording would commence when an attacker commands it over RF to do so.

In normal circumstances, all communication between the remote and the box is initiated by the remote – this is a common power-saving strategy for low-energy devices, since it enables them to power off whenever they are not used. This means that we can’t directly send a “start recording” command to the remote from the outside – we can only do it in response to a query from the remote.

In accordance with this constraint, we created a series of patches to the original firmware that cause it to broadcast such a query once a minute. We actually took advantage of the regular firmware upgrade mechanism to achieve this.

First, we made it to check for new upgrades once a minute instead of once every 24 hours. Second, we added a new type of response to this check (besides “new firmware is available” or “no new firmware is available”) that caused the remote to trigger the recording code. The remote would continue recording for up to ten minutes.

Once this period had elapsed, the attacker could continue recording by simply replying in the same way to the remote’s next query. In effect, this meant the attacker could stop recording when they were out of range or no longer interested. Continuous recording uses up a lot of power, so this feature would have been important to an attacker. (It also kept us from eating up the battery during our own research.)

Because we didn’t have access to the remote’s source code, developing our patch to the firmware was not at all straightforward – we had to carefully edit the firmware binary without breaking anything. By strategically choosing where and how to change the original firmware image, we were able to make all of our changes to the regular remote control behavior in the space of just a few dozen bytes.

Running the attack

First, to push the malicious firmware to the remote, we had to catch a firmware upgrade query from the remote. As we’ve seen, the remote sends these out only once every 24 hours, by default, so we had to wait a while before taking advantage of it.

After sending a response to the firmware check, the firmware itself had to be delivered chunk by chunk. Depending on the attack implementation, this could take some time. At our fastest, we managed to push firmware to the remote in about 20 minutes, but that implementation tended to fail at the slightest interference. A more consistent implementation took about 35 minutes to push firmware to the remote.

Once we figured out the audio format the remote streams, it turned out we could discern conversations quite clearly from the remote’s microphone. We were able to hear a person talking 15 feet away from the remote almost word-for-word, and it’s almost certain we could have stretched that distance out, too.

How easily you could have pulled off WarezTheRemote depends, in a large part, on the equipment you were using. A basic RF transceiver is very cheap – a Texas Instruments CC2531 costs only a few dollars for a whole development kit. We used an ApiMote, which is much more convenient for quick prototyping, but costs closer to $150. (Each of these devices has its quirks; we ended up spending much of our time fine-tuning and working around the ApiMote’s issues.) To overcome interference from the set-top box, it proved easiest to use three transceivers (one for each RF4CE channel.).

The distance you could have run WarezTheRemote from also depended on your equipment – namely, the antenna you were using. A cheap 2 dBi antenna can be had for about a dollar, but we weren’t able to dependably upload our firmware to a remote more than an unobstructed couple dozen feet away with these.

We had much better results with a 16dBi antenna. We didn’t push this to the limit, but we were easily able to push firmware to the remote around 65 feet away from outside the apartment it was in. This is the alarming part – it conjures up the famous “van parked outside” scene in every espionage film in recent memory.

Vulnerable devices

As Comcast has completed its remediation efforts, we know of no vulnerable devices at this time. Up until the fixes were released, though, every XR11 remote could have been attacked in this fashion. Besides leaving out the batteries, there was no effective way to mitigate it, either.

Since then, Comcast has released patch 1.1.4.0 to the remote, which causes it to discard non-encrypted firmware packets. (You can view the remote’s firmware version on your X1 set-top box under Settings/Remote Settings.)

Besides the fix to the issue we found, Comcast has also remediated CableTap’s earlier CVE-2017-9498 by introducing device update validation to the remote’s bootloader. This prevents untrusted firmware from being installed on the device. Because replacing the firmware is the most straightforward attack vector on these devices, this fix goes a long way to keeping them locked down from external attackers.

Finally, Comcast also fixed the minor issue we found on the cable box itself, which allowed us to temporarily put it out of commission (we used this to keep it from interfering with the attack).

Working with Comcast

We originally disclosed the encryption issue on the remote – along with the simple DoS on the X1 box and a reminder about the open CableTap CVE – in late April. Comcast responded very quickly and were courteous and professional throughout the disclosure process. Within a couple of months they had started deploying patch 1.1.4.0, which addresses the issues we disclosed. They were also generous enough to provide us with details of the fixes so we could continue our research.

Comcast’s statement

Nothing is more important than keeping our customers safe and secure, and we appreciate Guardicore for bringing this issue to our attention. As detailed in this report, we fixed this issue for all affected Xfinity X1 Voice Remotes, which means the issue described here has been addressed and the attack exploiting it is not possible.

Technologists for both Comcast and Guardicore confirmed that Comcast’s remediation not only prevents the attack described in this paper but also provides additional security against future attempts to deliver unsigned firmware to the X1 Voice Remote.

Based on our thorough review of this issue, which included Guardicore’s research and our technology environment, we do not believe this issue was ever used against any Comcast customer.

Comcast builds security into every phase of product development and deployment as part of a continuous commitment to make our products as secure as possible. This includes secure architecture, design, code, and testing. As part of that work, we actively engage with the global security research community, and work quickly to address issues they bring to our attention. We value the work of independent security researchers and the important role they play in our commitment to keeping our customers safe and secure. We encourage researchers to reach out to us with any issues through our reporting page.

Responsible disclosure timeline

April 21, 2020 vulnerability reported to Comcast + case opened
April 24, 2020 Comcast starts looking into findings
May 5, 2020 Comcast acknowledges the issues and begins work on a patch
June 25, 2020 Comcast begins testing on patch
July 14, 2020 Comcast begins release of patch
September 24, 2020 Comcast confirms all devices have been patched

Implications

WarezTheRemote is significant because it illuminates a new aspect of the problematic state of IoT in the present. There’s no shortage of research on vulnerable smart home devices from the last few years. In fact, there’s hardly a security conference without at least one talk on the topic. One can assume that by now, most consumers have at least some idea of the risks in having a WiFi-connected baby monitor or voice-controlled smart speaker in their homes. It’s easy to forget, though, that the term IoT encompasses a lot more Things than just the clear-cut examples. Few people think of their television remote controls as “connected devices”, fewer still would guess that they can be vulnerable to attackers, and almost no one would imagine that they can jeopardize their privacy. In this case, the recent development of RF-based communication and voice control makes this threat real. Even more so in these strange times: with so many of us working from home, a home recording device is a credible means to snoop on trade secrets and confidential information.

Capabilities like these used to be the closely-guarded secrets of sophisticated, nation-state actors. In the last few years, though, they’ve reached the public awareness in full force. We know from leaked information that government agencies have been taking advantage of IoT devices for years to covertly record conversations. And while the cybercrime world is not nearly as advanced as these organizations, their first steps into the world of IoT indicate that it’s only a matter of time until we see them investing in these sorts of attacks as well. It’s easy to imagine how a criminal could make use of a remote recording device for identity theft or extortion.

In this instance, we had the good fortune to work with a vendor that was very responsive to our research. This was an example of an effective cooperation between technology vendors and the security research community: Comcast proved very willing to work with us on the issues we found, and within a couple of months they had released fixes to the remotes. We believe that manufacturers that encourage this sort of engagement go a long way towards keeping the technology that surrounds us safe.

Looking forward, we can only guess that this will happen with more and more devices you normally wouldn’t think of when someone says “IoT”. SoCs are cheaper than ever, and no one is surprised to see a Bluetooth logo on the box their coffeemaker came in. The truly dangerous devices are the ones with more insidious connections to our homes, our networks, and our private information.