The problem with this approach for email generation is that this also applies to email domains of large email providers. For example, if the owner is using an outlook.com email address, the Room’s email address will be room__<account ID>@outlook.com. Since anyone can create an arbitrary Outlook email address, we can create a valid email inbox for a Zoom Room!
Next, we followed the Zoom sign-up flow using the Zoom Room’s email address. This caused an email activation link to be sent to the Zoom Rooms email address. However, as we now controlled this email inbox, we could click on this link and activate the account. Upon activation, Zoom’s backend automatically logged us into the organization’s Zoom tenant as the service account. Given that a service account is treated as a team member, we could now gather information laterally across the tenant.
Zoom Rooms, as service accounts with at least two licenses, had considerable access within the tenant as they were effectively treated as normal team members. They could view all users in the organization using the Contacts feature, hijack the meeting itself if they were the host, view all organization-wide whiteboards, and more.
We noted interesting behavior in the Team Chat feature. Zoom provides a feature called Channels, which as the name implies, is a system of text channels. Channels are open to tenant employees by default. Room users were able to view the contents of any channel, including confidential information and persist in this access completely invisibly. Room users could not be removed from the channel by any administrator – even the Owner.
Following several conversations with the Zoom team, the vulnerability was validated and promptly remediated. To mitigate this issue, Zoom removed the ability to activate Zoom Room accounts.