At CSA, 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.
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.
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.
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.
The use case for this authentication bypass is:
1. A new meeting is scheduled, and the host sends out invites to participants.
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
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:
iq type must be changed from ‘error’ to ‘result’.‘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.
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.
If you want to uncover vulnerabilities in your software or devices, look at our penetration testing services.