Unveiling a Security Vulnerability in Zoho Meet: Gaining Unauthorized Access to Private Meetings

In the era of remote work and virtual collaborations, video conferencing platforms have become essential tools for businesses worldwide. Among these platforms, Zoho Meet has gained popularity for its user-friendly interface and robust features. However, in the pursuit of seamless communication, security vulnerabilities can sometimes be overlooked, posing significant risks to users’ privacy and confidentiality.

In this article, I will shed light on a security flaw I discovered in Zoho Meet, which enabled unauthorized access to private meetings.

“Zoho upgraded meeting passwords to alphanumerics thanks to my successful exploitation attempt in their program! 😄”

Upon joining my first company as a PHP developer in 2021, I found myself in a team of six individuals based in India. Our daily meetings with the CEO and CTO, who resided in America, were conducted seamlessly through Zoho Meet. It was during these virtual gatherings that I first encountered Zoho Meet.

There were two primary methods to join a password-protected meeting:

1. The first method involved having the meeting ID and its corresponding SHA-256 value.

https://meeting.zoho.in/meeting/login/join.jsp?key=1393913035&name=sumit&t=SHA-256

1. The second method required the meeting ID along with the raw password(removing t query param from url).

https://meeting.zoho.in/meeting/login/join.jsp?key=1393913035&name=sumittet

One day, while experimenting with the login URLs, I made a curious discovery. By simply removing the “t” parameter from the query, the system prompted me for a raw password, which at the time consisted of a six-digit code. This unexpected behavior shed light on a potential vulnerability in the platform’s authentication process.

While examining the JavaScript code of Zoho Meet, I came across a clear implementation of a dual authentication.

With each password being a six-digit code, encompassing the numbers 0 through 9, the total number of possible combinations amounts to 10⁶, equating to one million unique payloads. This extensive payload range underscores the significant effort required to brute force the meeting passwords successfully.

The lazy Sunday sun peeked through my window as I sat before my computer. An idea sparked in my mind: “Why not try logging into Zoho Meet without a password?” With a quick decision, I created a test account and initiated a meeting.

Meeting ID was the only requirement for performing this attack.

As I continued with my brute force attack, sending multiple requests simultaneously, I hit a roadblock: Zoho’s strong rate limiting system. After reaching ~1,000 requests, my access was cut off, leaving me stuck for a moment. It was then that I acknowledged the impressive security measures Zoho had in place. Despite the setback, I couldn’t help but appreciate their effective defenses.

I started tinkering with a technique called “IP spoofing” or “header manipulation.” The vulnerability involves attackers attempting to impersonate trusted IP addresses or manipulate headers (such as X-Forwarded-For) in order to bypass security controls like IP whitelisting or header validation.

Manipulating headers, attackers may attempt to trick the server into trusting malicious requests as if they were coming from trusted sources, potentially bypassing access controls, rate limiters, or other security measures.

In order to enforce rate limits. This identification can be based on various factors such as IP addresses, API keys, user authentication tokens, or client identifiers.

I began my penetration testing by focusing on manipulating headers first. Adding various headers such as X-Forwarded-For, X-Forwarded-Host, X-Client-IP, X-Remote-IP, X-Remote-Addr, and X-Host, all set to 127.0.0.1, I sent requests to the system. To my amazement, the system accepted these requests without question, which leads to granting me access to login to any passwords-protected meeting.

X-Forwarded-For : 127.0.0.1
X-Forwarded-Host : 127.0.0.1
X-Client-IP : 127.0.0.1
X-Remote-IP : 127.0.0.1
X-Remote-Addr : 127.0.0.1
X-Host : 127.0.0.1

Upon analyzing the responses from the backend server, I discovered a crucial indicator: when the correct password was submitted, the response length was consistently 567 characters. Utilizing my penetration testing tool for my tests, I discerned that upon successful validation, the server returned the hash of the password in the response body:

{
  "isPwdProtectEnabled": true,
  "isPwdValidated": true,
  "encryptPwd": "bfd9a5c03a1b1d60e82f42f717012373224d67a90ba315ccf9187df7e7e3d82f"
}

This hash, denoted by “encryptPwd,” served as confirmation that the submitted password was correct.

To verify that you have successfully logged in to a private meeting, you can modify the URL by replacing {encryptPwd} with the encrypted password used for authentication

https://meeting.zoho.in/meeting/login/join.jsp?key=1393913035&name=sumit&t=bfd9a5c03a1b1d60e82f42f717012373224d67a90ba315ccf9187df7e7e3d82f

Yeaahhhhhhhh I did it! 😄 😄 😄 😄

My excitement bubbled over like an overenthusiastic soda bottle as I cracked the password! Picture me doing a victory dance that could rival any TikTok sensation, complete with a few fist pumps and a triumphant “YES!” echoing through the room. It felt like winning the jackpot in a game show, but instead of cash, I had unlocked the secret to Zoho Meet’s security puzzle. Cue the confetti and a chorus of imaginary applause — it was a moment of sheer, unadulterated hacker happiness! 🎉

I created a security researcher account and promptly submitted my report to Zoho on July 9, 2021, complete with a solid proof-of-concept and step-by-step instructions to reproduce the issue on their end. Imagine my surprise when, within just a few hours, Zoho’s support team responded with a swift acknowledgment: ‘Hi, thanks for the report. Our team is on it and will get back to you soon.’

But they didn’t stop there. In a matter of hours, they confirmed the bug! Talk about efficiency!

Then, on August 12, a Zoho support member jazzed up my ticket with this gem: ‘Hi @eka_lavyaa, we consider this bug to be squashed now. Can you please confirm?’ By the way, at the time of submitting report my username was ‘eka_lavyaa’ is my Zoho researcher username.

But did they really fix it? Oh, you bet they did! I put their claim to the test, and lo and behold, the bug was indeed history! And just to sprinkle a little extra seasoning on the victory, I received a generous bounty payout on August 13, 2021.

I don’t remember on what date i got listed on their hall of fame.

Link to Zoho’s hall of fame: https://bugbounty.zohocorp.com/bb/info#hof
You can find me in year 2021, just search for sumit.

Now, that’s what I call a rollercoaster ride of bug-busting excitement! 🎢💻🔍

Security Mitigation:

I was lucky that Zoho’s rate limiter was only blocking requests based on IP addresses. A reverse proxy or load balancer has a set of rules that determine which traffic is allowed in and out and from what origin. This is what a firewall is used for. However, sometimes when configuring a reverse proxy, we forget to include checks for localhost, 127.0.0.1, etc. This allows attackers to bypass the rate limiter because their rules don’t exist for these hosts. Additionally, there should be validation that checks if the header has been tampered with or not.

“Zoho’s security upgrade didn’t stop there! After implementing server fixes, they transformed meeting passwords from simple 6 digits to 6 characters, incorporating a mix of letters (a-z, A-Z) and numbers (0–9). With this added layer of complexity, cracking the code now poses a challenge even for the savviest of pentester! 😎🔒”

Initial report — July 9, 2021

Bug confirmed — July 9, 2021

Bug fixed — August 12, 2021

Bounty payout — August 13, 2021

Dear Readers,

I want to extend my deepest gratitude to each and every one of you for joining me on this journey. Your support, engagement, and enthusiasm mean the world to me. Without your encouragement, none of this would be possible.

Thank you for taking the time to read, comment, and share your thoughts. Your feedback drives me to continually improve and strive for excellence. Together, we’re making a difference in the world of cybersecurity, one bug at a time.