During a customer project, we identified a logic flaw in Jitsi Meet, an open-source video conferencing and messaging platform for secure video conferencing, voice calls, and messaging. The vulnerability affects password protected Jitsi meetings that make use of a lobby. This logic flaw leads to the disclosure of the meeting password when a user is invited to the call after waiting in the lobby.
Jitsi offers two security options to meeting moderators. Firstly, the meeting can be assigned a password that must be entered when joining. Secondly, a lobby mode can be activated, which first adds joining users to a lobby, from where they can then be added to the meeting by a user with moderation permissions.
Technical Background
Jitsi uses the Extensible Messaging and Presence Protocol (XMPP), an open-standard communication protocol designed for instant messaging and real-time communication over the Internet for inter-component communication. Many functionalities are offered directly by the XMPP standard, such as multi-user chats (MUC) via which the chat within a video conference is mapped. Password protected rooms are also implemented directly with XMPP. A preceding lobby, however, is not included within the specification of the protocol. Nevertheless, Jitsi uses XMPP functionality to implement it.
For this purpose, Members-Only Rooms are being used. When the lobby mode is activated, two things happen conceptually:
- First, all conference participants become members of the room, and,
- Second, another MUC (the lobby) is associated with the conference.
If a user is invited from the lobby to the video conference, they become a member of the room.
Proof of Concept (PoC)
In the case of a room with a lobby and password, the room is a MUC with password protection and Members-Only access. When a user is invited to a meeting via the lobby, the user receives the following XMPP message via web sockets from the server stating that the request to join has been approved:
<?xml version="1.0"?>
<message xmlns="jabber:client" to="[email protected]/iSXOTxy3rb-0" from="[email protected]" xml:lang="en" id="50a2a698-4f85-423b-8bd1-949a29f4df64:sendIQ">
<x xmlns="http://jabber.org/protocol/muc#user">
<invite from="[email protected]/vVh9WLXtoMRQ">
<reason/>
</invite>
<password>ernw123</password>
</x>
<body>[email protected]/vVh9WLXtoMRQ invited you to the room [email protected]</body>
<x xmlns="jabber:x:conference" jid="[email protected]"/>
</message>The response discloses the meeting password ernw123. This is in alignment with the XMPP specification for mediated invites in multi-user-chats.
Usually, this would not be a problem as XMPP requires that participants must have both the password and the Member status to join a password-protected Members-Only meeting. But this is where Jitsi deviates from the XMPP standard – it automatically makes users members of the meeting if they join by simply providing the password.
By gaining knowledge of the meeting password, users that have been invited to a password-protected meeting can grant meeting access to other users, even though they lack moderation rights. The vulnerability was assigned CVE-2024-33530.
Affected Version
We identified this vulnerability in Jitsi version 2.0.9364 from March 18, 2024. Though, we could also verify that the issue was present in all Jitsi version since the ever first version supporting lobbies which was Jitsi version 1.0.4289 released on July 12, 2020. In these times, the messages were still transmitted using HTTP POST requests instead of web sockets. The vulnerability was fixed in Version 2.0.9457 release on April 23, 2024.
Disclosure Timeline
- March 21, 2024: ERNW provides vulnerability information to Jitsi. Start of 90-day disclosure period.
- March 23, 2024: Initial response by Jitsi stating that a fix is already implemented and merged.
- March 25, 2024: ERNW confirms fix with Jitsi unstable build.
- April 23, 2024: Release of Jitsi version
2.0.9457 - May 02, 2024: Disclosure of vulnerability details by ERNW.
Thank you very much for the fast response!
Cheers!
Flo