How secure are webinar platforms? In-house research.
In the search for a webinar platform that would suit ourselves, we tested the security of 14 of them. Half of them were found to contain high or critical vulnerabilities.
How secure are webinar platforms? In-house research.
Background
In the COVID era, everyone speaks about remote work security. People wonder which VPN is the most secure and how serious are security issues in web conference platforms such as Zoom. However, webinar software platforms have also grown in popularity and it seems like nobody talks about their security.
While looking for a platform that would suit ourselves, we tested the security of 14 of them. It turned out that:
- Half of them contain high or critical risk vulnerabilities related to access control.
- For two of the tested platforms, an attacker could easily become a host.
- In three others, they could perform privileged operations.
- For seven platforms, generic vulnerabilities related to confidentiality were identified.
How bad is the webinar security situation?
As most of the communication with the client, presentations, and training has been transferred to the remote world, our company also started looking for a suitable platform which would enable us to provide knowledge to our clients.
One of our colleagues prepared for us a webinar using a third-party platform to test its possibilities. After 5 minutes of the webinar, strange things started to happen. Firstly, the colleague who was host and presenter wrote indecent words on the webinar’s whiteboard, then he was kicked out of the meeting. Instead of him, another of my colleagues became a host. As I thought, since we are “hackers for hire”, my colleagues started to hack the webinar platform and one of them managed to find and exploit vulnerabilities in just a few minutes.
Since the platform was not secure enough, we decided to find another one. However, the problem happened again. The second platform also had crucial vulnerabilities and thus company owners asked me and my colleague Jakub Korepta to verify the security of other platforms to get a view of how safe available solutions are.
Assumptions of the research:
- We’ve selected the popular webinar platforms based on the Majestic Million and spent about an hour per platform.
- The tests were performed from only one account on a platform and only data related to the test account was accessed.
- The main purpose of the tests was to gain the host/presenter privileges as an anonymous attacker or an attendee of a meeting.
How do webinar platforms work?
Webinar platforms are regular web applications and use HTTP(S) protocol for communication between client and server-side. Additionally, to keep every webinar participant up-to-date with the meeting data, the WebSockets protocol is used for performing actions on meetings and their attendees.
Participants of a webinar perform actions in their browsers, then a proper message is sent to the application server, the application decides if a user has proper rights, performs the action, and sends messages back to proper users. Based on this response UI of the application in a browser is created.
What can go wrong?
Before performing the tests, we always do threat modeling to identify key assets, threats, and objectives. You can watch the Instant Threat Modeling video by Jakub Kałużny to see how it works:
The main threats for webinar platforms are:
- Host/presenter account takeover,
- Privilege escalation,
- Accessing a webinar without privileges,
- Denial of Service attack,
- Accessing sensitive data of other attendees.
What attacks did we perform on webinar platforms?
During our test, we encountered a whole range of vulnerabilities. We focused mainly on three aspects:
- Privilege escalation by role modification.
- Privilege escalation by access control issues.
- Sensitive information in the browser.
Why those? Remember our assumptions “The tests were performed from only one account on a platform and only data related to the test account was accessed”. We didn’t want to touch other users’ webinars or their data, only our own.
Role modification in webinar platforms
The simplest way for gaining host (presenter) privileges is to modify the value of one parameter that is sent when an attendee joins a meeting, a parameter related to the role of a user.
For example, when the user clicks the button, the following message is sent to the server:
["e":"joined","d":{"user":{"id":21467916,"banned":false,"role":"attendee","email":"test@t.securing.pl","name":"Test1"}}]
However, the attendee can change the role from attendee to host and take full control over the webinar:
["e":"joined","d":{"user":{"id":21467916,"banned":false,"role":"host","email":"test@t.securing.pl","name":"Test1"}}]
The attack can be performed in two ways: either by modifying messages to, or from the application server. The clue is that every single attendee can modify the parameter and in such a trivial way become the host of a webinar.
Access Control to functions
Even if the application does not allow users to modify their roles, it still can have access control issues which result in performing privileged operations. It is because the application server does not restrict access to resources from an unprivileged attendee. For example, there is a functionality that is available only for the host of the webinar – making another user a presenter.
Since it is an admin function, attendees cannot perform the operation by clicking a button in the browser, yet, it is still possible to make a connection to the application server and send a prepared WebSocket message as follows:
["confMsg",{"room":"1234567","from":"host","to":"12668543","permissions":{"screen":true,"cam":true,"mic":true},"type":"add-new-presenter"}]
Simply after sending such a request a user with id 12668543 becomes a presenter of the webinar. Note that, all values can be easily obtained by any attendee because they occur in many WebSocket messages.
What next? Well, the attacker can use other access control issues and for example kick the host out of the meeting to avoid stopping the attack:
["block-user",{"user_id":"0","user_email":"host@t.securing.pl ","user_name":"Host","id":"2385746"}]
The host is blocked, the attacker has host or presenter privileges and the result is the same – any attendee can become the host of a meeting.
Sensitive information (PII) in the browser
Every application defines who can access what data. However, it is crucial to verify it server-side. If an application performs access control only client-side (in the browser), a user who inspects communication can access sensitive data.
For example in a User Interface, only the admin sees details about the attendees. However, a message containing the data is broadcasted to every participant of the webinar.
The decision if one user can access the data is made by the browser, nonetheless, attendees have access to received messages traffic and thus can bypass this security mechanism and read data.
Another example is sending private messages during the webinar. Host sends a private message to User1 and User2 cannot see it. However the browser of User2 receives the message and by inspecting it User2 can get to know its content.
Other Vulnerabilities
A lot of things can go wrong in the context of webinar platform security. As an attacker can modify messages generated from the browser, they can try not only to execute privileged methods but also to access sensitive data related to other webinars. Sometimes, identifiers of users or webinars are not random which makes exploiting these vulnerabilities much easier. Even if there are no access control issues, attackers still can play with a whole range of parameters and try to spoof messages or to bypass client-side validation.
So, how safe are webinars?
We did not verify the security of entire platforms and we were focused on the communication during the webinar and obtaining host privileges.
We tested a total of 14 webinar platforms and found half of them vulnerable to attacks
Two of the tested platforms enabled standard attendees becoming a host simply by modifying the value of one parameter. Three others allowed performing privileged operations by exploiting access control issues. Seven platforms overall had vulnerabilities related to confidentiality either by exposing excessive data with messages sent to the browser or by server-side access control issues.
How did the companies respond to our findings?
To not make our research art for art’s sake, we tried to convey details of vulnerabilities to the appropriate people responsible for security of these solutions. As it turned out, it was not that easy. Since there was no security dedicated contact on any website, our first shot was technical support. Obviously, details of vulnerabilities could not be passed to a random person from the support or marketing team so we pushed for giving us a contact to a person responsible for the security. Even after many explanation attempts, non-technical people were not able to understand the problem:
And certainly, they do not understand what is an access control issue:
Our other approach was to find a competent person on our own. We tried to find people responsible for the security or at least technical ones who help us escalate the problem in LinkedIn. It was also useful to verify what our contact is responsible for.
In the end, we managed to report vulnerabilities to 4 companies. Two of them fixed vulnerabilities in a week, the third one fixed them partially in a month. The last one has not fixed vulnerabilities yet.
After receiving notes about vulnerabilities it did not take companies a lot of time to fix them. The true problem was to break through the first line of support who usually do not understand the security and do not inform the company that the problem exists.
None of the inspected webinar platforms has security contact on their web page.
Talking with technical support is most of the time useless as they are not prepared to handle vulnerability reporting.
The best solution is to find potentially competent people using Linkedin and contact them directly.
Conclusions
We got caught in a mental trap that if something is popular and publicly available it is well-tested and secure. Our research showed that it is not true and within one hour a person who understands the security of web applications can find vulnerabilities that enable them to take control over webinars.
Thus, it is important to remember that:
- Similarly to other SaaS applications, webinar platforms have vulnerabilities.
- Security tests should involve all applications, including those provided by external vendors.
- It is important how SaaS software support reacts to information about detected vulnerabilities.
Technical staff should note that most of the vulnerabilities which we found were related to access control and it is extremely important to verify server-side if a user has privileges to access data or perform an operation.
Nothing is secure by default, so if you are a vendor, train your developers and perform security tests of your software.
