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.
SHA-1 Has One Foot In the Grave