Time to Update your Video Conference Software| Blog

Jitsi-Meet Authentication Bypass (CVE-2021-33506)

At SureCloud, one of our most vital services is penetration testing. We exploit the vulnerabilities in devices and software (via means such as authentication bypass) to educate businesses on where weaknesses in their cybersecurity plans might exist. With this information, businesses can confidently invest in IT risk management software and adopt best practices that keep them covered.

One example of our penetration tests is this investigation into the Jitsi-Meet Authentication Bypass.

What is Jitsi?

The way of working remotely changed drastically with COVID. Many products were quickly made available to fill the gap of meeting people face to face via the Internet using a webcam.

But there was a problem: most of these products were centralised, and all communications (chat, video, audio or file share) were travelling to and from the company’s servers.

To negate this issue, one product, in particular, gained a lot of attention: Jitsi, the open-source privacy-focused video chat with easy self-hosting capabilities.

With more than 300 contributors on GitHub, the project is proliferating and being used by many companies for private communications.

In this test, we examined exactly how Jitsi is vulnerable and how cyberattackers can assume moderator privileges in what should be a private call.

TL;DR

The component jitsi-meet-prosody (version <= 1.0.4985-1) was shipped with an insecure default configuration in prosody.cfg.lua that allowed malicious unauthenticated users to gain moderator privileges before the start of a meeting.

The Testing Environment

Ubuntu 20.04.2 LTS
jitsi-meet 2.0.5870-1
jicofo 1.0-747-1
jitsi-meet-web 1.0.4985-1
jitsi-meet-web-config 1.0.4985-1
jitsi-meet-prosody 1.0.4985-1
jitsi-videobridge2 2.1-492-g5edaf7dd-1

The configuration files were amended in accordance with the official documentation to enable authentication, therefore only moderators could start a new meeting.

Attack Scenario

The use case for this authentication bypass is:

1. A new meeting is scheduled, and the host sends out invites to participants.
2. An attacker, part of the participant’s group, would receive a direct link to the meeting without any login details.
3. Before the meeting starts, the attacker connects to the meeting and performs the authentication bypass, obtaining the moderator privileges before the real moderator.
4. The real moderator connects and opens the room to all (other) participants.
5. The attacker will keep having moderator privileges for the entire meeting, allowing complete control over other participants and the real moderator itself. It should be noted that a moderator cannot be “kicked” from a meeting once it has commenced.

The Weak Default Configuration

The main muc component available at “conference.yourdomain.ltd” was missing the ‘restrict_room_creation’ directive, which allowed unauthenticated participants to force the conference to start and gain moderator privileges.

The pull request that fixed this issue can be seen at: https://github.com/jitsi/jitsi-meet/pull/9252/files

Jitsi-Meet Exploitation Walkthrough

When Jitsi is configured to require the host to log in, the following UI message is presented to the participants before the meeting can start:

Figure 1: Participant’s view while waiting for the host to join.

The XMPP BOSH requests and responses, while waiting for the host to open the room, are as follows:

Figure 2: Request made by the client

Figure 3: Response received by the server

The next step to trigger the vulnerability is to make the client (browser) believe that the server accepted its authentication request (which was never sent in the first place). This can be achieved by tampering with one of the “not authorised” responses to insert the following content:

Figure 4: Image showing the intercepted server’s response and what was changed in the body

It is important to change the following elements to make a valid response:

- The iq type must be changed from ‘error’ to ‘result’.
- The current room name must be specified under ‘room’ in the conference structure.

Also, this issue can only be triggered if the response from the server is tampered with in a timely manner. For this reason, it is strongly advised to let Burp Suite change the response via Match and Replace functionality:

Figure 5: Image showing Burp’s Match and Replace configuration

Let’s look at what’s happening in the requests/responses once the client receives the tampered response.

Table 2: Client sends a structure, and Server assigns moderator privileges to the attacker.

At this stage, the attacker is the first one in the room; however, the room is still closed for all other participants. They need to wait for a moderator to log in to be able to see people joining the same space.

It should be noted that the attacker moderator does not have the necessary privileges to start the meeting – only the legitimate moderator can perform that action.

Once a legitimate moderator has joined, this will be the view from the attacker’s perspective:

The attacker, having moderator role, can enable the lobby, set a room password, mute, stop video, chat, and generally perform all moderator actions.

Please note: Moderators cannot kick out another moderator – which will make the attacker’s presence in the room permanent.

What can be done to prevent Jitsi-meet takeover?

The Countermeasure

Updating to the newly released version of Jitsi-meet-prosody will resolve this issue, which at the time of writing is 2.0.5963-1.

Disclosure Timeline

20/05/2021: Bug Identified
21/05/2021: Technical documentation delivered to Jitsi developers privately, and CVE request submitted
21/05/2021: A fix is issued in the commit https://github.com/jitsi/jitsi-meet/pull/9252/commits/5568dacf893116c8056f4aa1fea7baaf414d1947
25/05/2021: Commit pushed into master branch
10/06/2021: New release of jitsi-meet-prosody
18/06/2021: Jitsi release advisory: https://github.com/jitsi/security-advisories/blob/master/advisories/JSA-2021-0001.md
27/07/2021: Publishing this blog post

If you want to uncover vulnerabilities in your software or devices, look at our penetration testing services.