Executive summary (TL;DR)
Jitsi Meet on Docker contained default passwords for important users, which could be abused to run administrative XMPP commands, including shutting down the server, changing the administrative password and loading Prosody modules. We also provide instructions on how to check for this issue if you administer a Jitsi Meet server.
Background story
A few days ago we noticed a tweet by @joernchen mentioning something that sounded familiar, Jitsi. He recommended that people using the docker image for Jitsi meet set secure passwords.
Using `docker-jitsi-meet`?
— joernchen (@joernchen) April 6, 2020
Make sure to set reasonable passwords.https://t.co/M4U8nfwexV
The security update’s ChangeLog explained that:
Previous releases included default passwords for system accounts, and users who didn’t change them are at risk of getting the authentication system circumvented by an attacker using a system account with the default password. Please update and use the provided script (instructions on the README) to generate a strong password for each system account. {.blockquote}
Then Hanno Böck released a script to check for this vulnerability, together with an article (in German) about the vulnerability.
So, basically, these default passwords could be used to login at the XMPP server used by Jitsi Meet, called Prosody. Since many Jitsi Meet servers actually allow you to setup a video conference for free, without credentials (uses anonymous authentication), the dear reader must be thinking, big deal right?
How bad is it?
Well, actually it is a bit of a big deal. Certainly not one to sniff at. Let me attempt to explain.
Jitsi Meet uses Prosody for the signalling part of the video conferencing solution. During setup of the docker images, various internal XMPP accounts are created automatically, allowing the different components of Jitsi Meet to communicate over the XMPP server. Specifically, the following users are created by default:
focus
for Jicofo, which stands for JItsi COnference FOcus, which manages media sessions between each of the participants and the videobridge.jvb
for JVB, which stands for Jitsi Videobridge, the video router.jibri
for Jibri, which is the broadcasting infrastructure. Essentially, a headless chrome for recording and streaming purposes; very interesting from a security perspective but we leave that for another time.recorder
also used by Jibri.jigasi
for Jigasi, which is a SIP gateway for audio calls.
All users, except for the recorder
, are available on the auth domain, which is auth.meet.jitsi
. In the case of the recorder
user, this user is available on the special recorder.meet.jitsi
domain. All of these settings are of course configurable but they all came with the default password of passw0rd
. Additionally, there was an extra secret for the Jicofo focus component, referenced in jitsi-meet.cfg.lua
from within Prosody, which was set to s3cr37
.
The most critical user from all of these is the Jicofo user, which is an administrative user on the Prosody server. This means that the focus
user can do a number of things that a normal XMPP user cannot, including shutting down the server (leading to DoS), changing user passwords (also leading to DoS), loading Prosody modules and joining rooms meant for internal use which are particularly interesting from a security/privacy point of view. Anyway, we decided to show how to shut down the server using Pidgin in a video demo.
The video shows starting Jitsi Meet for Docker and normal usage, then logging in using Pidgin as the focus
user, and finally running the shutdown command on the XMPP server.
If you’d like to do this at home on your vulnerable system, you can follow these steps:
- Create a new account in Pidgin (use menu Accounts > Manage accounts > Add)
- In protocol select XMPP
- Username set to
focus
- Domain set to
auth.meet.jitsi
- Password set to
passw0rd
and select Remember password - Switch to advanced tab
- Connection security set to use encryption if available
- BOSH URL set to
https://localhost:8443/http-bind
(if that is your target server) - Click on save and the enabled checkbox for the new account, if not enabled
- Click on the
Accounts > focus@auth.meet.jitsi
menu and notice all the administrative functions that are available
From there, you can then see some of the lovely things that you can do as a Prosody XMPP administrator by clicking on the Accounts > focus@auth.meet.jitsi/` menu.
Advice to Jitsi Meet administrators
During our past VoIP pentests and WebRTC infrastructure penetration tests, we have seen internal XMPP users (even on Jitsi environments) with default or predictable passwords. So, we think that this problem may affect more than just the official Jitsi docker. It is likely to be found in custom installations and perhaps, solutions that rely on Jitsi or similiar software. So if you are administering such a system based on Prosody (such as Jitsi’s), how do you check your internal user accounts for weak passwords?
In the case of the Jitsi Meet docker, the following command will show the passwords:
docker-compose exec prosody \
/bin/bash -c 'cat /config/data/*/accounts/*'
Example output of a vulnerable system would be:
return {
["password"] = "passw0rd";
};
return {
["password"] = "passw0rd";
};
return {
["password"] = "passw0rd";
};
These instructions apply when Prosody is using internal_plain
authentication, which is what is used in the docker image.
Note
Out of the box, Prosody also supportsinternal_hashed
and cyrus
which, when used, the above commands would not be so useful. While plain text passwords are a bad idea, the people behind Prosody have explained why, by default, they use plain in an article called Plain or hashed password storage?.If the problem is found on Jitsi Meet on Docker, we recommend following the Quick Start instructions in the official README file which suggest running the following commands:
git pull
./gen-passwords.sh
docker-compose down
rm -r ~/.jitsi-meet-cfg/
mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb,jigasi,jibri}
docker-compose up -d
Credits
- @joernchen for reporting it to the Jitsi team
- Jitsi team for fixing the issue
- Hanno Böck for reporting on this on Golem
- Alfred Farrugia for the video demo and assessing the impact
- Sandro Gauci write up