How Zoom’s Zero Touch Provisioning Becomes a Remote Root Exploit

TLDR: Researchers discovered that Zoom’s Zero Touch Provisioning (ZTP) mechanism for enterprise desk phones lacks sufficient authentication and integrity checks, allowing attackers to hijack devices remotely. By manipulating the vendor redirect service and exploiting hardcoded cryptographic keys, an attacker can force phones to download malicious firmware and gain root access. This research highlights the critical danger of trusting cloud-based provisioning platforms without verifying the underlying hardware security.

Enterprise desk phones are often treated as "set and forget" hardware, relegated to isolated VLANs where they sit quietly in the background. We assume these devices are secure because they are managed by centralized cloud platforms. However, the research presented at Black Hat 2023 on Zoom’s Zero Touch Provisioning proves that this trust is misplaced. When you combine legacy hardware with modern cloud-based management, you often end up with a massive, unauthenticated attack surface that allows for remote code execution without ever touching the device.

The Anatomy of the ZTP Hijack

The core of this vulnerability lies in the trust relationship between the desk phone, the vendor’s redirect service, and the provisioning server. When a new phone boots up in its factory settings, it reaches out to a hardcoded URL to check if it has been assigned to a provisioning service. This is the "Zero Touch" part of the process.

The problem is that the vendor redirect service, which tells the phone where to go for its configuration, does not require any authentication. An attacker who knows the MAC address of a target device can simply register that device in their own Zoom admin panel. Once the device is registered, the vendor redirect service will point the phone to the attacker’s malicious provisioning server instead of the legitimate one.

This is a classic A07:2021-Identification and Authentication Failures scenario. By controlling the provisioning server, the attacker can push arbitrary configuration files to the phone. These files are not just simple settings; they can contain instructions to download and install custom, malicious firmware.

Breaking the Firmware Chain

The research team analyzed the AudioCodes C450HD and found that the firmware update process was fundamentally broken. The device lacked an immutable root of trust, meaning it would happily execute any firmware image that passed a simple, flawed integrity check.

The team discovered that the "integrity check" was not a cryptographic signature verification, but a simple checksum calculation. By using Ghidra to reverse engineer the flasher binary, they identified the logic used to validate firmware sections. The "magic" was just a sum of all bytes in a section.

# Extracting the key from the binary using dd
offset=$(python3 -c 'print(int("00001ef8", 16))')
dd skip=$offset count=64 if=decryption_tool of=secret.bin bs=1

Once they understood the structure, they could modify the firmware, recalculate the checksum, and upload the malicious image. The phone accepted the update, and the attacker gained a root shell. This is documented in CVE-2023-22955, which covers the missing immutable root of trust in the hardware.

Hardcoded Secrets and Cryptographic Failures

Beyond the firmware update process, the configuration files themselves were a goldmine. The researchers found that the vendor used hardcoded cryptographic keys to encrypt sensitive data like SIP credentials and system passwords. This falls squarely into A02:2021-Cryptographic Failures.

By extracting these keys from the binary, they could decrypt the configuration files of any device they could intercept. The combination of these vulnerabilities—CVE-2023-22957 and CVE-2023-22956—creates a perfect storm. An attacker can not only take over the device but also extract the credentials needed to pivot into the internal network, potentially accessing the company’s Active Directory or other sensitive infrastructure.

Testing and Defensive Strategy

For a pentester, this is a high-impact finding. If you are performing an engagement that includes physical or IoT assets, do not ignore the desk phones. Use Wireshark to inspect the traffic during the device boot process. If you see the phone reaching out to a vendor redirect service, you have a potential entry point. If you can spoof the DNS or intercept the traffic, you can test if the device validates the provisioning server’s identity.

Defensively, the fix is not just about patching. It is about architectural changes. If your devices support mutual TLS (mTLS), enable it immediately. This ensures that the phone only talks to a provisioning server that can prove its identity with a valid certificate. Furthermore, limit the network communication of these devices. A desk phone should only be able to talk to the specific IP addresses required for its operation. If it does not need to reach out to the public internet, block that traffic at the firewall.

This research serves as a stark reminder that convenience is often the enemy of security. Zero-touch provisioning is great for IT efficiency, but it creates a massive, automated pipeline for attackers if the underlying security controls are absent. When you are auditing a network, look at the devices that are supposed to be "managed" and ask yourself if that management is actually secure, or if it is just a wide-open door waiting for someone to walk through.