ClickMeeting minor privacy weakness (fixed)


Just a short reminder to anonymize data on the server-side and not in the browser, illustrated by a small privacy vulnerability I've found during, well, a security talk I've attended that took place on the ClickMeeting platform (it was still 10 minutes before the talk began you understand).

Props to ClickMeeting for a fast reaction time and good communication - this bug is long fixed (reported on April 7th 2021).

Original report (though redacted a bit) follows:

Hey folks, I've joined a webinar hosted on clickmeeting platform today, and noticed one thing which I found curious. The webinar I attended had chat enabled, however there seem to be some "privacy mode" enabled for attendees - i.e. the chat didn't display the list of people (which is pretty standard nowadays I guess), nor one's name when writing a message - but only initials, e.g. (picture inline): A screenshot of a chat message with only initials of the sender visible, but not the full sender name. This sounds like a pretty cool feature and I believe is described in this article on your blog. "When it comes to running webinars, other attendees will no longer see other attendees’ names. Due to security reasons, it will be impossible to identify any attendees in the event room." That being said, the actual WebSocket communication contained both: 1) The full name of the person: Chrome DevTools screenshot from a WebSocket message showing a chat message packet that includes the full name of the user. The name is redacted on the screenshot. 2) And the full list of people attending the webinar: Chrome DevTools screenshot from another WebSocket message showing the full attendee list, including full names of everyone. Names are redacted on the screenshot. JSON packet sniffed from the WebSocket traffic for the picture above: [ "chat.newMessages", "CC", [ { "id": 804911256869, "uid": UID REMOVED FROM BLOG POST, "type": "message", "content": "CONTENT REMOVED FROM BLOG POST", "userName": "FULL NAME REMOVED FROM BLOG POST", "timestamp": 1617704463000, "time": "Tue, 06 Apr 2021 10:21:03 GMT", "moderationStatus": -1, "isDiscussed": false, "to": -1, "role": 1, "conferenceId": 4875343, "replyData": {}, "sharedFiles": [] } ] ] The obvious suggestion for a fix is to do the name-to-initials conversion on the server side instead, and perhaps additionally hide/obfuscate the "uid" if it's persistent between different webinars (I'm guessing it's not, but you know the system better). Important: Please assume this is reported under the industry-standard 90-day policy (like this one), i.e. information about this vulnerability will be shared with the defensive community 90 days from now (7th July 2021). P.S. Regardless of the above, please consider adding some information about how to contact your security team on your website. The usual way is: 1. Add the contact details at https://clickmeeting.com/.well-known/security.txt (see this, this and this for details). 2. Add a way to report vulnerabilities at https://knowledge.clickmeeting.com/privacy-security/ (e.g. this e-mail address). 3. Add a way to report vulnerabilities to https://disclose.io/programs/ database. Kind regards, -- Gynvael Coldwind

Add a comment:

URL (optional):
Math captcha: 5 ∗ 5 + 1 =