VOICE-ZEUS: Impersonating Zoom’s E2EE-Protected Static Media and Textual Communications via Simple Voice Manipulations

Zoom Video Communications, commonly known as Zoom [5], has gained massive popularity since its inception in 2011, thanks to its user-friendly interface, simplicity, versatility, and ease of use. The COVID-19 pandemic has immensely accelerated the adoption of Zoom as a preferred communication tool among businesses, educational institutions, and individuals worldwide, due to the need for social distancing and remote work [20]. This has highlighted the necessity of a viable communication solution, and Zoom has emerged as an efficient and trustworthy option that fulfills this requirement. Its intuitive interface and rich set of features make it a top choice for virtual communication among diverse users [10, 14, 21]. One of its pivotal features is its virtual meeting capability, enabling participants from diverse locations to seamlessly connect and cooperate, making it an indispensable tool for remote work, telecommuting, global partnerships, and more. Moreover, Zoom’s recording feature enables users to record meetings or webinars for future reference or sharing with absentees, while screen sharing enables participants to share their screens with others, facilitating more collaborative and interactive meetings.

However, it is worth mentioning that Zoom has faced some challenges and controversies as well [30, 29]. At the outset of the pandemic, apprehensions surfaced regarding the effectiveness of Zoom’s security and privacy measures, as reported cases of "zoombombing" involved disruptive unauthorized participants or insiders with legitimate access introducing inappropriate content [19]. These incidents have highlighted the inherent risks of relying on digital platforms such as Zoom to conduct academic activities. Furthermore, this trend has exacerbated concerns surrounding potential threats to academic freedom and privacy, specifically concerning the phenomenon known as the "zoomification" of academia, and the associated issues of data privacy, surveillance, and censorship [7]. With increased use, video conferencing platforms such as Zoom have become appealing targets for eavesdropping and espionage activities by governments and other malicious actors. These incidents have brought into question the platform’s overall security posture and prompted Zoom to address the identified vulnerabilities and fortify its security features. Consequently, Zoom has implemented robust security measures, such as E2EE, to protect the privacy and integrity of meetings and data exchanged during Zoom sessions and to reinforce the overall security posture of the platform [17].

The implementation of E2EE has become crucial in modern communication systems to protect against unauthorized access and data breaches. It has emerged as an effective security protocol for ensuring the confidentiality and security of sensitive information shared during virtual meetings. E2EE guarantees that only the intended recipients of the communication can decrypt and access the data shared during the communication, making it particularly attractive to companies and organizations handling sensitive data. This prevents unauthorized access, interception, or interpretation of the data by malicious actors. This robust method encrypts the communication at the sender’s device and decrypts it at the receiver’s device, effectively preventing unauthorized entities, including service providers and attackers, from intercepting or tampering with the data during transit. E2EE’s ability to provide this level of security makes it an essential tool for protecting sensitive information in virtual meetings.

Recently, Zoom incorporated E2EE in its meetings, leveraging public key cryptography where the host generates encryption keys and distributes them to the meeting participants [17]. The keys are then used to encrypt and decrypt the data shared during the meetings, making it inaccessible to outside parties, including Zoom itself. To use this feature, users must enable E2EE in their account settings before setting up the meeting. However, E2EE meetings in Zoom are not compatible with certain features like cloud recording and live transcription [32], as they require access to unencrypted data, thus posing data security risks to users. Cloud recordings, for example, could be vulnerable to attack by malicious servers (such as the service provider Zoom), which could access the information stored in them. Thus, while E2EE offers many advantages in data security, online communication platforms need to ensure compatibility with all features and assure users that their sensitive information is secure at all times.

E2EE applications currently operate in an opportunistic mode, wherein the security assurances they provide depend on users trusting the service provider. This mode establishes secure connections between parties without mutual authentication [18, 11]. Despite its opportunistic nature, these applications offer significant privacy advantages over conventional communication methods like email and standard instant messaging [27, 9]. They effectively protect users from passive attackers, such as government surveillance agencies, seeking to eavesdrop on connections and collect sensitive information.

While opportunistic E2EE mode protects against passive MitM attacks, it leaves the system susceptible to active MitM attacks. These attacks may be perpetrated by rogue service providers or by compromising the server itself [11, 31]. The critical security challenge arises from the dependence on provider-supplied keys in these E2EE applications. During the key exchange service, a malicious or hacked server might simply launch an attack known as a key substitution attack, which compromises the entire E2EE system. This key substitution attack involves replacing a legitimate key with a fake one controlled by the malicious server. Consequently, without proper authentication of the encryption keys, users cannot ensure that they are indeed communicating with the intended recipients and not with an impersonator or malicious attacker.

Similar to other E2EE applications, Zoom employs an opportunistic E2EE mode that enables the creation of a secure communication channel between two parties without authenticating the other party. Consequently, the E2EE security of the Zoom application heavily relies on the authentication ceremony, a process that verifies the security code of encryption keys shared by participants. This ceremony allows Zoom users to verify that they are communicating exclusively with the intended parties during Zoom communications, thereby preventing impersonation and MitM attacks. Therefore, users must compare and verify the security code through this ceremony to establish complete end-to-end security. By adopting this approach, users can detect and thwart potential attack attempts, ensuring the secure sharing of sensitive information during virtual meetings.

In recent years, E2EE has become increasingly popular as a method of ensuring the confidentiality and privacy of online communications. Zoom, one of the most widely used video conferencing platforms, recently introduced E2EE for its users [17]. However, the security of this feature has been called into question by several researchers who have identified a number of potential vulnerabilities and attacks. In a study by Isobe and Ito [12], the authors conducted a thorough security evaluation of the E2EE feature in Zoom, examining various attacks. They discussed an attack where colluding participants share the meeting key with a malicious Zoom server, compromising meeting confidentiality. The authors explored additional attacks by exploiting vulnerabilities in the E2EE protocol. They proposed impersonation attacks by malicious participants in group meetings, impersonation by the malicious Zoom server using binding information from previous meetings, collusion of participants with the malicious Zoom server to fully impersonate legitimate users, and collusion-enabled impersonation attacks when multiple users share a device. They also highlighted security concerns such as the use of vulnerable encryption mode and potential denial of service by the malicious Zoom server.

Our work shares similarities with the above work [12] in terms of focusing on assessing the security of Zoom’s E2EE feature. However, our study differs from their work as we specifically focus on examining the implementation of the authentication ceremony in the Zoom application. We highlight a weakness in the authentication ceremony and provide evidence of a particular type of attack that can exploit this vulnerability. We specifically explore the vulnerability of the authentication ceremony arising from the absence of using OOB channels, relying solely on voice to announce the security code. The authors in [12] acknowledge that their findings are based on the Zoom whitepaper [32] and they have analyzed only the cryptographic protocol of E2EE. They did not implement or test their proposed attacks. In contrast, our work proposes a specific attack on the authentication ceremony in Zoom’s E2EE feature. We have also implemented a demo attack to demonstrate the feasibility of our proposed attack.

In a study by Kagan et al. [15], privacy risks in virtual meetings were highlighted, revealing the ease of extracting personal information like face images, age, gender, usernames, and even full names from publicly available images. This extracted data poses security and privacy threats online and in the real world, especially when cross-referenced with social network data. Similarly, our work focuses on the privacy and security risks in virtual meetings. We demonstrate an attack where malicious users can collect sensitive personal data, such as voice samples, by recording the victim’s voice during the authentication ceremony. Through simple voice manipulations, the attacker can create a new security code in the host’s voice, allowing them to impersonate the meeting host in future meetings and carry out malicious activities.

Similar to our work, the authors in [23] use voice reordering attacks to challenge the assumption that the voice channel, used for validating Short Authenticated Strings (SAS), provides integrity and source authentication in voice over the Internet (VoIP) communications. They report on automated SAS voice imitation MitM attacks that compromise the security of Crypto Phones. While their focus is on MitM attacks and short codes like SAS, our work employs simple voice manipulations with a longer numeric code in an authentication ceremony. We show a real impersonation attack rather than a real-time MitM attack, making our approach more practical.

The impersonation attack is a serious security threat in group-based E2EE protocols, such as Zoom. The attack involves injecting a new session into legitimate communication sessions between two or more parties, with the aim of creating a new session with different parameters or goals. From a security perspective, E2EE is a protocol, and the authentication ceremony is a crucial component of it. Therefore, our aim is to demonstrate that E2EE can be compromised by breaking its authentication ceremony. Here are the steps of the attack that must be executed successfully to compromise the group E2EE in Zoom:

1. 1.

   Recording the host’s voice as they speak only digits, aiming to collect audio snippets of all ten digits (from 0 to 9) for future use:

   1. (a)

      The attacker can join a legitimate Zoom E2EE meeting as a legitimate participant and record the host’s voice during the authentication ceremony when the host verbally announces the numerical security code.

   2. (b)

      The attacker could be a malicious Zoom server with access to Zoom recordings stored in the cloud from default Zoom meetings (non-E2EE meetings) that were previously recorded by the host. Subsequently, the attacker extracts only the audio snippets containing the digits.

   3. (c)

      The malicious Zoom server could potentially infiltrate default Zoom meetings that do not employ E2EE, simply by using meeting IDs known to the Zoom server. Subsequently, the attacker can gain access to parts of the host’s voice during conversations where numbers are spoken and record them.

2. 2.

   After capturing the necessary voice snippets, the malicious participant or the malicious Zoom server can proceed to create a new Zoom E2EE meeting session and falsely claim it was initiated by the previous host. The attacker may employ social engineering or phishing attacks to deceive and invite other participants to join the new session.

3. 3.

   Generating the new security code in the previous host’s voice is accomplished by performing a VOICE-ZEUS attack, where snippets of legitimate audio signals from previous recordings are cut and pasted.

4. 4.

   The attacker can ask participants to compare and verify the new security code for the new meeting during the authentication ceremony.

5. 5.

   Once the attacker successfully completes the authentication ceremony, all forms of communication within the session, including text-based interactions and screen-sharing presentations, are considered authenticated.

6. 6.

   The attacker can then proceed with the session, utilizing chat and screen-sharing features available within the meeting to disseminate offensive language, racial slurs, or even threaten specific individuals. This can result in harm to participants, damage the reputation of the victim host, and create a hostile environment.

To demonstrate the effectiveness of this attack, we will perform an attack on a Zoom E2EE meeting and use our proposed VOICE-ZEUS attack to generate a security code in the voice of the host. A high-level overview of our attack is provided in Figure 3.

Our study examines the capabilities of an attacker at two levels:

In a malicious Zoom meeting scenario, we assume that the attacker as a host has disabled the video feature, leaving only the audio voice functional for the duration of the meeting. The role of the host in managing an audio-only meeting is pivotal, especially in situations where the attacker claims issues with the video feature. When initiating an audio-only meeting on Zoom, the attacker possesses the capability to customize the meeting settings before it begins. This includes the option to disable video, ensuring that participants only communicate using audio channels. This functionality is easily accessible through the host’s Zoom account settings, allowing for a seamless transition to audio-only mode during the meeting.

Once the video is disabled and the authentication ceremony is completed, it becomes easy for the attacker to limit communication to non-vocal means. The attacker may claim issues with their audio or video and proceed with the meeting, relying solely on the chat function for textual communications. Additionally, the attacker can utilize the screen-sharing feature as a valuable tool for visual communication, displaying images, slides, or other visual aids instead of verbal content.

In all the following scenarios, we assume that the host (the attacker) will follow the same steps outlined in Subsection 3.1 to execute the attack. Additionally, the attacker is assumed to have the ability to disable the audio/video feature and conduct meetings using only the chat and screen-sharing features.

To evaluate the feasibility of our attack, we conducted two Zoom E2EE meetings, each involving three users, with one acting as the host and two as participants. Our experimental setup consisted of a laptop computer, an iPhone device, and an Android device, with one device serving as the host and the other devices as participants. In the initial meeting session, we established a legitimate Zoom E2EE meeting using the iPhone device as the host. The laptop computer and Android device were used as participants, with the laptop computer serving as the attacker whose objective was to record the host’s voice uttering numbers from 0 to 9 for future use. During the authentication ceremony, we generated an audio sample of the security code using a free online TTS generator [3] for experimental purposes. We used samples from three male English speakers and three female English speakers, representing US, British, and Australian accents. Here the attacker needs to capture the host’s voice while uttering numbers, utilizing any available software that offers an audio recording service. It is assumed that the host has not granted permission for any participants to record the meeting. Consequently, the attacker will need to use third-party software or an external device, such as a smartphone, to record the host’s voice. In our study, we utilized both methods to record the host’s voice for all speaker samples. First, we utilized the Audacity software [1] to record the host’s voice during the authentication ceremony and export it as a WAV-format audio file. Second, we used an external device (Samsung Galaxy S21) to record the host’s voice during the authentication ceremony, employing the Samsung Voice Recorder app [2] installed on the device to capture and export the voice as a WAV-format audio file.

During the initial meeting session, the attacker’s objective is to detect the presence of any digit in either the authentication ceremony or the regular conversation uttered by the host. It is obvious that all digits can be spoken during the security code presentation in the authentication ceremony. Therefore, the attacker only needs to activate the Audacity software before the host initiates the authentication ceremony to ensure recording all digits. For a different type of attacker, such as the malicious Zoom server, the attacker may need to record the entire Zoom meeting or acquire access to the Zoom recordings stored in the cloud. Subsequently, the attacker can extract only the snippets containing the digits from the host’s voice for future use. In the second meeting session, we established a Zoom E2EE meeting as an attacking session, utilizing the laptop computer as the host of the meeting, with the primary objective of impersonating the previous host. We utilized the other devices (the iPhone device and the Android device) to participate in the meeting as legitimate participants. During the authentication ceremony, we executed the VOICE-ZEUS attack to impersonate a previous legitimate host by reordering all digits of the security code in his voice. In our experimental setup, we attempted the attack twelve times and captured the host’s voice on six occasions using the Audacity software and six instances using the Samsung Galaxy S21 phone device. The process of conducting the attack involved the creation of two Zoom E2EE meetings on each attempt. We utilized samples of six speakers (TTS samples) to read out the security code during the authentication ceremony. The TTS samples were produced using a freely available online TTS generator [3].

To further investigate the feasibility of our attack, we expanded our experimental scope by incorporating speech samples from the FSDD dataset in addition to the TTS samples. The FSDD dataset contains audio recordings of single digits (0-9) spoken by six human speakers, saved in WAV files, and is available as an open-source voice dataset at [13]. In our expanded experiment, we followed the same set of steps as in our previous experimental setup. We recorded spoken digits in one Zoom meeting and reordered them in another Zoom meeting. During the initial meeting session, we introduced speech samples from the FSDD dataset to read out the security code during the authentication ceremony. The attacker’s objective remained the same: capturing the host’s voice while they uttered the numbers. To record the host’s voice, we utilized both the Audacity software and an external device (Samsung Galaxy S21), enabling us to export the recorded audio as WAV files. In the subsequent meeting session, created as the attacking session, we performed a VOICE-ZEUS attack. This entailed rearranging all digits of the security code in the voice of a previous legitimate host during the authentication ceremony, achieved by cutting and pasting snippets of digits extracted from previously recorded audio files. Similar to the previous scenarios involving TTS-generated samples, we conducted twelve attempts of this extended experiment using human speech samples from the FSDD dataset. We were able to capture the host’s voice in six instances using the Audacity software and another six instances using the Samsung Galaxy S21.

Our study demonstrates how easily someone can impersonate a Zoom meeting host by employing a voice channel and conducting a VOICE-ZEUS attack to speak the security code. Despite Zoom expressing concerns about the potential use of deepfake technology for this type of attack [32], we demonstrate that we can compromise the system without employing such sophisticated techniques or attacks. Therefore, our attack surpasses a deepfake approach, delivering superior results at a remarkably low cost and with greater ease of deployment and effectiveness. This flaw in the authentication ceremony significantly compromises the security of Zoom’s E2EE mechanism. The attacker could be a malicious participant in a meeting or even a malicious Zoom server. The attack involves collecting audio snippets of all ten digits (from 0 to 9) spoken by the victim. These snippets can be obtained by either a legitimate participant in previous meetings or retrieved from uploaded recorded meetings in the cloud. Collecting ten-digit audio snippets is an effortless task as only a few seconds of eavesdropping can provide sufficient audio samples. During the authentication ceremony, the attacker can wait for the victim to read the security code, which contains all 10 digits. Alternatively, the attacker can record numeric utterances in prior unprotected Zoom meetings. In some cases, the attacker could physically be close to the victim during a public talk or presentation, using the opportunity to record such samples.

We observed that the attacker can easily impersonate the victim’s voice because the reordered voice has no distinguishable difference from the original voice, as demonstrated by our objective evaluation where the MCD was equal to 0. This occurs because the attacker reorders the ten spoken digits of the same victim, keeping the voice filtering features, which provides similar characteristics to the original voice. It is obvious that the current implementation of the authentication ceremony in the Zoom application represents a significant vulnerability that threatens the security of Zoom’s E2EE mechanism. Once an attacker successfully exploits this vulnerability, he can engage in various nefarious activities, including zoombombing, posting obscene content, making threats against specific individuals, or disseminating morally objectionable content. Our attack poses a significant threat not only to Zoom but also to any E2EE application relying solely on audio channel authentication. While we demonstrated this on Zoom, we assert that E2EE applications like Viber [4], utilizing audio channels for number-based authentication, may also be vulnerable.

The susceptibility of numeric security codes in the Zoom application to simple voice manipulations underscores the need to explore alternative mechanisms for addressing and mitigating this vulnerability. One possible approach could involve displaying the security code only after the host and participants have joined the Zoom E2EE meeting session. Currently, the Zoom authentication ceremony only uses the (IVK_l) during the handshake protocol to generate the security code for the E2EE meeting session. This gives an attacker enough time to execute the VOICE-ZEUS attack by creating the Zoom E2EE meeting session and starting it before all participants join the meeting. In this scenario, the attacker has enough time to reorder the previous snippets in the previous host’s voice to speak a new security code. To mitigate this, the Zoom application should generate the security code only after the host and participants have joined the Zoom E2EE meeting session. This would make it challenging for the attacker to have sufficient time to reorder any numbers during the authentication ceremony.

Another potential defense against impersonation attacks is to perform the authentication ceremony using multiple channels, incorporating an additional OOB channel, such as SMS or email, alongside the audio channel. By utilizing multiple channels, the robustness of the system’s defense could be enhanced, making it more resistant to manipulation. This would pose a higher level of difficulty for attackers, as they would need to compromise all audio and other OOB channels, effectively doubling their efforts to carry out an impersonation attack. It is important to note that further research and optimization of the implementation of these defense mechanisms are crucial to ensure their effectiveness in mitigating the vulnerability posed by simple voice manipulations in the Zoom application. Careful consideration and thorough testing are necessary to design robust and secure mechanisms that can effectively protect the security of Zoom’s E2EE implementation against potential attacks. By adopting these alternative mechanisms and conducting rigorous research and testing, the Zoom application can strengthen its security measures and safeguard against impersonation attacks, thus ensuring the privacy and security of its users.