Cross-Chat Session Bypass in chat application

[arungaddam-tec]

Hi Live Helper Chat Community,

While checking the chat applications on the demo page, I noticed that the application generates a sidebar chat option for communicating with the operator. This chat feature uses an endpoint called '/index.php/chat/addmsguser/<chat_id>/'. However, by copying and pasting this endpoint from one support chat to another, an attacker can send messages to a different support box, which can compromise the confidentiality of user support interactions.

Steps to reproduce:

1. As a user initiating the chat from the demo widget, I observed that the user endpoint for chat and hashed was called in the network.
2. Copy the curl URL, open an incognito browser, initiate the chat as an attacker, and copy the add user endpoint's curl URL.
3. Next, copy the user's chatid and hashid, paste them into the attacker's curl command and enter the message.
4. If the curl command is executed, the message will be sent from the user widget to the operator. The attacker can view all of the messages sent by the operator by using the syncuser endpoint(/index.php/chat/syncuser//id/).

A security vulnerability allows attackers to impersonate users and send unauthorized messages to different support channels. Using brute-force techniques to obtain the chat ID, attackers can exploit this flaw to intercept and manipulate sensitive support communications. The session or cookie provided during the chat initiation process can be easily bypassed, making it easier for attackers to carry out their malicious activities.

Thanks,
Arun

[remdex]

Hi,

Few things

I agree knowing chat id and hash you can do whatever you want as long chat is in open status. But same is true for any other app which uses JWT token as example...

But how you know these is another story:

1. Hacking application having physical access to it does not count as hacking...
2. Your steps to reproduce missing code which should be used to re-produce the issue. If I have a physicall access to PC does not count. Proper security reports have code attatched to it... Now you talk about theoretical things...
3. Hash is not in URL for that request it's in payload.
4. How can you brute force chat id and hash? They both have to match chat id and hash. They both is valid as long chat is open usually chat takes about 10 minutes. So you are going to send millions of request to server and expect to ques chat id and hash? That just makes no sense.
5. How can you by pass chat initiation process?
6. You are writing that that using brute force you can obtain chat ID. What's the point to know that chat id is valid?

For your reference about hash as it's 40 charcters length...

Assuming that the attacker has a computer that can attempt one billion password guesses per second, it would still take them an estimated > 6.8 x 10^44 years to crack a 40-character password with a combination of lowercase, uppercase letters, and numbers. This is significantly > > longer than the age of the universe, which is estimated to be around 13.8 billion years old.

So please user real world example and sample code. Now it seems you just writing to write without any sufficient value for Live Helper Chat. By your writing any app which usese tokens in payload/url or anywhere else is insecure which is absolutely nonsense...

If you website is compromised you have much bigger problems if anyone can read cookies from your website... :)