In July 2024, we identified a vulnerability that resulted in access to millions of live customer support messages for organizations using Cisco Webex Connect.
In July 2024, we identified a vulnerability that allowed unauthenticated users to access chat histories of all organizations using Cisco’s Webex Chat (previously IMI Chat) widgets. This affected hundreds to thousands of organizations deploying the product in internal environments, such as IT help desk, and external environments, such as customer-facing help desk environments.
When building offensive capabilities with Orion, we actively monitor for new SaaS assets on customers, bug bounty targets, and government organizations. During this, we learned about Cisco Webex Chat. Cisco provided this product through the acquisition of IMI Engage (IMI Chat) (provided by IMImobile PLC) in 2021. The product is designed for customer support through live agents and automated FAQ bot.
Live chat systems are interesting attack vectors for attackers because chat histories contain a trivial amount of sensitive customer data. The data that could be extracted from any live chat system could range from customer PII, answers to security questionnaires, credentials to internal systems, and more.
We decided to dig deeper and see if we could identify a vulnerability in Cisco’s live chat product.
Like other live chat instances, developers can quickly deploy a Cisco Webex Chat by embedding its JS file and the app_id. The application and its API endpoints handle all the “magic,” including authentication, storage, and communication calls, reducing engineering efforts for customers.
When a user visits a page that has the chat embedded, it makes a series of call (steps) to initialize the chat window and prepare it for the user to communicate with an agent:
/settings endpoint at https://chat-widget.imi.chat/livechats/APP_ID/settings?host=ALLOWED_DOMAIN&$callback=? with the APP ID which returns the configuration for the chat window for example window color, title, etc. Included on this response is a clientKey .clientKey to make a series of calls to list features available to chat, what settings it has, and so on.During this process, we noticed that the clientKey is also used as a secretKey to make some sensitive API calls.
Whenever a user starts the chat session with a customer agent, the application makes an API call to a /threads endpoint to create a new chat session. The request would include a title for the thread, the status, and the type.
POST /rtmsAPI/api/v3/apps/CLIENT_ID/threads HTTP/2
Host: CUSTOMERNAME-usor.apps-imiconnect.io
Content-Length: 165
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.120 Safari/537.36
Content-Type: application/json
Accept: */*
Secretkey: CLIENT_KEY
Priority: u=1, i
{"title":"da0f3fca-5f21-4b8b-b76d-1bf5baf5813c_APP_ID_ALLOWED_ORIGIN_1727372312156","type":"Conversation","status":"Active"}
During this, we noticed that the clientKey was being passed onto the header as a Secret Key. This was interesting and weird at the same time. Why would a clientKey that is supposed to be public also be used for in a secretKey parameter?
Additionally, the title of the thread had a pattern:
When a successful request was sent, it would respond with the thread UUID:
{"code":"0","description":"success","thread":{"created_on":"2024-09-26T17:38:55.896Z","id":"9d35e17e-b165-4d61-90b7-aac76dfa6f5e"}}
Since we can create threads, we wondered if we could also list all threads in the application for the particular customer. To test our theory, we sent the same request that creates a thread but as a GET request instead. Since we already know the client_id and client_key, this request was allowed and returned the first 100 threads sorted by descending order (most recent first). Additionally, passing start and limit query parameters allowed paginating through the resources to retrieve metadata on all past and present chat threads.
The response for the API endpoint included:
title for the threadid value containing the thread UUID.This had still not returned us the actual chat content. We then started to read the documentation Webex Chat has available.
After researching for some time, we could not find any documentation using thread ID, App UUID, App ID, User UUID, and client key combinations to read the chat. However, when we dug through the JS file at https://media.imi.chat/widget/js/imichatwidgetv2.js?id=26092024_1 we identified an API call:
IMIGeneral.profileUrl()+"profile/GetPreviousChatHistory?"+t;$.ajax({url:a,type:"GET",data:{},headers:IMILiveChat.Sendheaders(),success:function(n){if(IMILiveChat.setWidgetbuttonStyle(),null!=n&&0<n.length){localStorage.setItem("all-attach-size-{0}".format(IMILiveChat.getCurrentThreadId()),0),IMIGeneral.storeLocal(localStorage.getItem("browserfingerprint") +"_"+IMILiveChat.getCurrentThreadId()+"_unreadcount",0);var r="0";
Reading further, we identified this call could be made to https://chat-widget.imi.chat/profile/GetPreviousChatHistory with the following query parameters:
Overall, we had all the information needed. Even though the parameter email sounds like it is expecting a user email, the user UUID from the first bit of the thread’s Title worked fine.
Sending a call to https://chat-widget.imi.chat/profile/GetPreviousChatHistory?teamappid=APP_UUID&email=USER_ID&browserfingerprint=USER_ID&appid=CLIENT_ID&threadid=THREAD_ID&proactive_id=0, then returned the entire chat session history for that particular thread including but not limited to chat messages.
After finding the vulnerability, we wrote a quick PoC script to run the entire chain end-to-end, only knowing the app_uuid and the domain origin (chat.example.com). When tested against a real organization, we could access all the chat histories for an internal helpdesk designed for employees to communicate with the internal IT team.
The vulnerability was reported to Cisco on July 30, 2024 and the first patch was pushed out by Cisco on October 23, 2024 however it was bypassable. A more complete version of patch was then deployed on December 18, 2024. A final patch was then introduced on January 29, 2025.
This vulnerability and more is exactly what Orion focuses on identifying and reporting. 0 False positives, High Signal and More impact. Secure your attack surface today by running our automated hacker against it.
