A misconfiguration in an organizations' setup of their live chat system allowed unauthenticated access to user chat histories with customer support agents.
We recently conducted security research against various organizations that use Live Chat systems. As part of our research disclosures, we wanted to post about a finding that highlights a security concern regarding how these systems are set up and operated.
Whenever we conduct security research, we look for two cases:
1) Direct vulnerability in a provider
2) Misconfiguration could exist due to incorrect architecture/setup on the customer end.
In this case, we found a misconfiguration that we believe could also be more widespread for other companies.
When you interact with a live chat system, you are most likely interacting with either of the three ones:
We were interested in investigating chatbot and live agent systems that take in or store user-related information such as user messages, past orders, and more. These would be available in both Systems 1 and 3.
In both systems, organizations that want to store user information must implement some form of authentication that fetches the current users' information and uses that to interact with or store user-supplied information.
Thankfully, almost every service provider of Live Chat systems come baked in with authentication features that allow organizations to track user messages and information for future reference. One common way authentication mechanisms work is that an organization uses the logged-in user's ID or email from their system to generate a salted hash. This hash is then communicated to the live agent service provider via an API call to authenticate the chat. Here is an example of how this mechanism works from HelpShift's user authentication documentation:
As shown in the flow, organizations use a pre-generated Secret Key provided by the service provider (in this case, HelpShift) to generate an HMAC based on either the user_id or email. This is then communicated back to HelpShift through its SDK.
Similar authentication mechanisms exist for other providers, such as Intercom. For example, HackerOne, which uses Intercom, generates and returns an Intercom token for a logged-in user through a server-side function and returns it in the response that initiates the SDK.
This is relatively safe to keep user chat sessions centralized and tracked if done right. However, as is common with implementing SaaS solutions, this can have misconfigurations.
When investigating live chats, we primarily focused on the ones that allowed communicating with an agent AND stored chat history for authenticated users. Our primary goal was to find ways to read the chats of other users, whether through a vulnerability in the provider or a misconfiguration in an organization.
While testing different organizations, we wanted to analyze how an organization would generate a user_hash or an auth_token for an authenticated chat session. Especially since this is supposed to be done server-side, we were curious to see if we could leak a secret key or find a flaw in the auth mechanism. Ideally, this should not be attacker-controlled. In one of the organizations we were testing, we noticed that the organization generated the user_hash / auth_token equivalent based on a provided user's email from a cookie.
Sending a request to their messaging endpoint with our "target" email address returned an auth token that could then be used to interact with the service providers' API to read all chat messages sent by the user to the support team.
Investigating the service provider (HelpShift) APIs, we could send a request like the following with the target user email and auth_token from the organization to fetch the chat history:
In this case, the Authorization header is simple a base64 encoded value of the platform-id for app authentication. A successfully call then returned the entire chat history of our target user.
We promptly reported this vulnerability to the affected organization, which has patched its instance.
While this is one example of such an occurrence, we believe more organizations are affected by such misconfigurations. In the end, generating a valid auth token securely falls on the organizations implementing these chat systems, not on the service providers.
Watch out for our next blog post to learn about the second vulnerability we identified during this research that effectively gave us access to millions of chat histories without authentication due to a vulnerability in a service provider.
