I Found the Secret Key to a Backdoor in a Video Conference System

Not long ago I bought a second-hand video conference solution on an auction site for 30 euro, and while I had fun experimenting with it, I also (re)-discovered a major security flaw.

The video conference system I purchased was end-of-life, meaning that it was no longer receiving updates and was stuck on an outdated firmware from 2020. Due to limitations in the hardware the system was prevented from being upgraded to a newer version of Android. Basically, it's stuck on Android 4, rendering the system obsolete.?

Despite these limitations, I wanted to experiment with the system and learn more about SIP and H323-based video conferencing. However, I quickly gave up on the H323 and SIP protocols, as I couldn't get them to work the way I wanted, and I therefore began to focus on reverse engineering the system itself.

After upgrading the firmware to the latest firmware version (released in 2020), I tried to jailbreak/root the Android operating system to gain control over the camera and other hardware components. It was during this process that I stumbled upon a previously published security flaw - a backdoor that enabled anyone with the secret key to remotely access the system.?

When googling for ways to jailbreak this device, I found a set of exploits for older versions of the firmware published by Brendan S. in 2019. He also identified the fact that the firmware image contained public-ssh-keys that would allow anyone with the corresponding private key to access the system remotely. The holder of the private would be able to access the video conference system remotely over the network and potentially also access its camera and microphones. This presented a major security risk for anyone using the system, as it could be exploited by malicious actors to eavesdrop on video calls but also possible on the rooms where it is installed. The 2019 advisory did however not mention anything about the whereabouts of the private key.?

But then I found that secret key!?

To start with, I gained access to a regular ADB shell on the device by enabling Android Debug and connecting via ADB over the network. Through this shell access, I was able to view running processes, network connections, file system layout, and configuration files. It took me a while to notice, but I eventually discovered an ongoing network connection to an unknown IP address. The IP address in question was 198.51.100.5, and my initial assumption was that the device was communicating with something on the internet. I have now learned that the IP range 198.51.0/24 is actually a reserved IP address range even though its not part of RFC1918, but instead a reserved IP-address range from another RFC (RFC5737) called "IPv4 Address Blocks Reserved for Documentation".?

And 198.51.100.5 isn't on the Internet at all. It's actually on a device internal network, used by a completely separate Linux machine. In fact, there seem to be a Linux machine nested inside the original Linux machine. See the movie Inception for further details.?

$ telnet 198.51.100.5

login: root?

Password:

#

And since there was no root password it was possible to access the internal Linux system from Android by loging in as root using telnet. From a technical standpoint, this was all quite fascinating. The video conference system comprised of two Linux devices connected to an in-device internal network. One ran Android, and the other was a custom Linux machine built to manage video capture and encoding.

Regarding the machine-to-machine integration between these two devices, the inner video processing Linux machines utilized an RSA-based SSH key to authenticate with the Android machine. To do this, the inner linux required the private (secret) RSA key. With root access to the inner device, I obtained this key.

To verify that the private RSA key was, in fact, valid for external authentication with the device, I tested it on my own device. It was possible to authenticate remotely as the 'admin' user using this RSA key, and I was also able to access the system using sftp with root privileges. I was also able to confirmed the MD5 fingerprint of the identified SSH private key with the public keys published in the advisory from 2019. These devices shipped with a backdoor, and the skeleton key was hidden under the floor mat.

This leads us to the million-dollar question: Was this backdoor intentionally created to spy and eavesdrop on video conference calls, and possibly even bug conference rooms where these devices were installed? My opinion, which is purely speculative, is that it's unlikely that it was intentionall. I believe it's more likely a result of inexperienced developers and poor engineering practices. However, we will probably never know. It does however highlight the need for diligence when selecting both vendors and products.?

My device will be dismantled into spare parts. The HDMI/VGA capture and video encoding hardware still intrigues me and that 12x optical zoom PTZ camera is quite nice.?