From Disclosure to High Severity: Leveraging Dyte API Key for Maximum Impact

As a bug bounty hunter engaged in a VDP program, I recently uncovered a JavaScript file that unveiled a trove of sensitive API keys and tokens. Among them was the Dyte API key, an unfamiliar entity in my exploration. This discovery revealed a mix of widely recognized keys like Google Developer, Stripe API, and Firebase credentials — each holding significant sensitivity. Curiously, while scouring through resources like the Keyhacks GitHub repo, I found no information on exploiting the Dyte API key, particularly the DYTE_ORG_ID and DYTE_KEY.

In this article, I aim to delve into the intricacies of exploiting the Dyte API key, exploring its vulnerabilities and potential impact.

So the javascript file look like this:

I did a quick Google search to find out more about what the Dyte API key is all about. Turns out, Dyte offers a solution for real-time video and voice integration into websites, mobile apps, and desktop applications. It’s all about making those video and voice calls.

I stumbled upon the Dyte API documentation at https://docs.dyte.io/guides/rest-apis/quickstart.

In Dyte’s API documentation, I discovered that their APIs rely on API Keys for request authentication through HTTP Basic Auth. The process involves sending an HTTP request that includes an Authorization header. This header contains the term ‘Basic,’ followed by a space and a base64-encoded string comprising the organizationId and apiKey. This method ensures secure validation of requests made to Dyte’s APIs.

I promptly encoded the values of the Dyte organization ID and Dyte key using Base64 in the format ‘organizationId:apiKey’, maintaining the specified order.

Now i have Authorization header value now it is time to test . After i craft following curl request with authoriazaiton header to create a simple test meeting.

14/12/2023 : Discover and Reported

16/12/2023: Changed the state to Triaged

19/12/2023: Changed the state to Resolved