Time To Update your Video Conference Software - Jitsi-Meet Authentication Bypass (CVE-2021-33506)

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 prior to the start of a meeting.

What is Jitsi?

The way of working remotely changed drastically with COVID. A lot of products were made quickly available which aimed 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 centralized, and all communications (chat, video, audio or file share) were traveling to and from the company’s servers.

To obviate 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 quickly growing and being used by a lot of companies for private communications.

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 (https://jitsi.github.io/handbook/docs/devops-guide/secure-domain) 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 full duration of the meeting, allowing full control over other participants and 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.

Exploitation Walkthrough

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

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

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 authorized” responses to insert the following content:

<conference ready=’true’ focusjid=’focus@auth.jitsi.local’

    xmlns=’http://jitsi.org/protocol/focus’ room=’0000-poc@conference.jitsi.local’>

    <property name=’authentication’ value=’true’/>

    <property name=’externalAuth’ value=’false’/>

</conference>

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 in the <conference> structure under ‘room’.

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:

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

Table 2: Client sends a <presence> 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 as we need to wait for a moderator to login 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 – that action can only be performed by the legitimate moderator.

Once a legitimate moderator has joined, this will be the view from the attacker 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 presence in the room permanent.

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