Security Analysis of BigBlueButton and eduMEET

Abstract

Video conferencing systems have become an indispensable part of our world. Using video conferencing systems implies the expectation that online meetings run as smoothly as in-person meetings. Thus, online meetings need to be just as secure and private as in-person meetings, which are secured against disruptive factors and unauthorized persons by physical access control mechanisms.

To show the security dangers of conferencing systems and raise general awareness when using these technologies, we analyze the security of two widely used research and education open-source video conferencing systems: BigBlueButton and eduMEET. Because both systems are very different, we analyzed their architectures, considering the respective components with their main tasks, features, and user roles. In the following systematic security analyses, we found 50 vulnerabilities. These include broken access control, NoSQL injection, and denial of service (DoS). The vulnerabilities have root causes of different natures. While BigBlueButton has a lot of complexity due to many components, eduMEET, which is relatively young, focuses more on features than security. The sheer amount of results and the lack of prior work indicate a research gap that needs to be closed since video conferencing systems continue to play a significant role in research, education, and everyday life.

A Appendix

1.1 A.1 eduMEET

E3: Overwrite Peer Reference. This finding leads to multiple high-impact issues in eduMEET. When a user connects to a room, the server creates a JSON Web Token (JWT) [17], bound to a peer ID generated by the client. The JWT is stored on the server and referenced by a cookie-based session. When a user connects to a room, eduMEET performs two checks. First, the server checks if there is a JWT for the session and if the peer ID is already used by a connected user. The server rejects the connecting peer if the peer ID is already used, but no JWT exists. Otherwise, the server verifies the JWT, i. e., the server checks if the peer ID matches the JWT. In case of a valid JWT, the server treats the user as returning and closes the old connection.

The vulnerability stems from the fact that the server creates a new peer object regardless of whether the JWT matches the peer ID. The peer object (see Sect. 4.3) represents a meeting participant and contains, among other things, a unique peer ID, a room ID, a list of user roles, and a socket for communication. Despite the importance of the JWT validity, in the first step, the server only checks if a peer ID and a JWT exist. Therefore, the peer ID does not have to match the JWT. When an attacker connects to a room with an existing peer ID and a valid session referencing a JWT that does not match the peer ID, the server still creates a new peer object. The server keeps a list of peer objects referenced by their peer IDs. Since the peer ID exists, the server overwrites the existing peer reference. However, the old connection stays open, and the old peer can still participate in the meeting.

To perform an attack, the attacker first joins any meeting. The attacker has a valid peer ID generated by the client and a valid session from the server. The attacker now joins the targeted meeting. Instead of having their client generate a new random peer ID for this connection, the attacker chooses an existing peer ID (see below). To achieve this, they may use the browser developer tools to overwrite the JavaScript variable holding the peer ID their client generated and then join the meeting. The new peer ID does not match the attacker’s JWT anymore. The WebSocket connection of the old peer with the same peer ID is not closed but not referenced anymore. That means the old peer cannot be targeted by moderator actions (E3.2). If the new peer with the same peer ID now leaves the meeting, the UI of all participants changes, and peers with the target peer ID are not visible anymore, but the connection of the old peer is still open. The old peer is invisible in the meeting but can still participate (E3.1), for example, listen to existing streams and read the chat. To exploit the first two scenarios (E3.1 and E3.2), the attacker needs to be the old and new peer at the same time, which they can achieve using two browser instances. In the last scenario (E3.3), the attacker uses the victim’s peer ID to prevent the victim from receiving new media streams. The peer IDs of all participants are known because the server broadcasts them when joining.

1.2 A.2 Status of Fixes in BigBlueButton

Table 3. All findings in BigBlueButton (BXX) with their status as of December 2023. The latest version at this time was BigBlueButton 2.7.3. In total, 37 of the 45 findings were fully fixed and the impact of one additional finding was significantly reduced.