non-admin-user can visit admin dashboard

[Oceanus 6]

Non-admin-user can visit the admin dashboard by typing in the url. They can see paths, active device and sent messages to other users.

 

[Carlo 4330]

Doesn't do this on my system.  Do you have a specific URL it does this on?

How did you reproduce this?

[Oceanus 6]

7 minutes ago, cayars said:

Doesn't do this on my system.  Do you have a specific URL it does this on?

How did you reproduce this?

Login as any non-admin-user and go to your.url/web/index.html#!/dashboard

[pwhodges 1521]

You're right, it does go to the dashboard.  But it doesn't show any of the administrative links, so it probably does no harm.

Paul

Edited July 8, 2020 by pwhodges

[Carlo 4330]

Still can't reproduce this.

Edited July 25, 2020 by cayars

[pwhodges 1521]

The user I changed to does not require password for local access - might this make a difference?

EDIT: I also checked there were no cookies, and cleared the browser cache before logging in in a new tab using the non-admin user.

Paul

Edited July 7, 2020 by pwhodges

[Oceanus 6]

But normal user should not be able to see what other user are watching and not be able to sent them messages.

[Carlo 4330]

@pwhodges If you have chrome fire up a new windows using ingognito mode.

Perform the same test and let me know if you can duplicate it.

Thanks,

Carlo

[pwhodges 1521]

Same - here's the screen capture.  "Home" is a non-admin user, and you can see the incognito flag top right:

However, I did notice that when I edit the URL to the dashboard one, it doesn't respond immediately; I have to hit return an extra time, and then the dashboard comes up.

I also wondered if accessing the server by loopback through the router using the external name/address had an effect, but going directly to the local address behaved the same.

Paul

Edited July 8, 2020 by pwhodges

[rbjtech 4218]

pwhodges - you might want to remove your public fqdn from that screen grab ... 

Edited July 8, 2020 by rbjtech

[pwhodges 1521]

Security by obscurity is not really effective; and my domain is widely known, being host to several public web sites.  But still, to set a good example...

Paul

Edited July 8, 2020 by pwhodges

[neik 835]

I can also reproduce this.

@Luke, any intention in fixing this?

[Oceanus 6]

Looks like emby is missing a functional rights management. Elements for non-admin-user are just removed from the gui, they are not restricted from accessing them.

[maximumentropy 23]

I reproduced this in incognito mode.  This is a serious security problem, so please address it quickly.  Thanks!

[Alternative311 1]

I tried to duplicate this, and was not able to duplicate, I get this for multiple users...  All my users have passwords, For my security and theirs. If they forget the password, they text me. I don't ever give out access to users I don't have a question of trust.

 

Edited July 20, 2020 by Alternative311

[neik 835]

 @Luke, any feedback on this? Can you reproduce it? Will you guys fix this?

[Painkiller8818 203]

I also can reproduce this and a non admin user is able to restart/shutdown the emby server or at least he is able to see and click the Buttons

The non-admin User can see active streams, can see the premiere key etc... this should be fixed ASAP and not "in the future"

Thanks

Edited July 25, 2020 by Painkiller8818

[GPlayer 0]

This should be patched as soon as possible. Could you do an interim release with the patch? @Luke

[symphonichorizon 4]

well that's just lovely, can we get a response on this please?

[GPlayer 0]

42 minutes ago, symphonichorizon said:

well that's just lovely, can we get a response on this please?

It is a bit embarrassing to be honest considering this thread has been live for almost 3 weeks.

[Mosuteparo 1]

I can confirm that this vulnerability is present both in the latest stable and the latest beta version of Emby. The worst part about it is that there are no effective mitigations that server administrators can put in place until an official patch is released to fix it. I spent a few hours today trying my best to find a good stopgap solution, but in the end, there were still trivial ways to circumvent any countermeasures I put in place.

The trouble starts with the fact that browsers do not send URL fragments like "#!/dashboard" to the server, so trying to use a reverse proxy to block requests to the URLs of administrative tabs, as they're presented in the browser, is a fruitless endeavor. One has to visit the different administrative tabs one by one and check the reverse proxy's logs to see which resources are actually requested by the browser and then block access to those in the config.

Now, while this approach does work, the big problem is that it only works for requests that actually come in on your own Emby domain. Why is this a problem? Because one of the benefits of Emby is Emby Connect which allows users to seamlessly sign into their accounts without having to know your Emby domain name. At this point, you may be thinking to yourself "Well, that's an easy fix, I'll just disable Emby Connect for my users until a patch is released then." Not so fast! While the vulnerability is particularly serious because it can be exploited both on the domain https://emby.media/ and your own Emby domain, what's particularly worriesome is that disabling Emby Connect won't actually prevent people from signing into your Emby server on https://emby.media/ and exploiting the vulnerability there, it will only require them to manually enter your Emby domain when signing in. The Emby website does not request access to the administrative tabs in a way that is identifiable in the reverse proxy logs, so even selectively blocking requests coming from that origin is not a realistic possibility. There seems to be no built-in way to straight-up prevent people from accessing one's server from a different domain like https://emby.media/ either.

After performing extensive tests on multiple Emby servers earlier today, I can now confidently state that this exploit allows any registered user on an Emby server running the latest stable version to perform the following actions:

• Viewing, pausing and terminating the streams of other users
• Sending arbitrary notifications to other users
• Viewing a list of all Emby users, their permissions and their email addresses
• Viewing and copying (i.e. stealing) the server's Emby Premiere key
• Gaining view-only access to all administrative tabs

It would be an understatement to say that this is a devastating vulnerability and I for one am appalled that there has been no acknowledgement from any Emby developer almost three weeks after it was first reported by OP.

Edited July 25, 2020 by Mosuteparo

[Carlo 4330]

I still can not reproduce this with any user logged in with username/password or emby connect.

Are you guys using accounts without passwords or the need to use them locally?

[TeamB 2352]

What I had to do to reproduce this was log in as a non admin user then enter the dashboard url

<your emby server>/web/index.html#!/dashboard

Hit enter, then hit refresh.

I could see the current active devices and paths.

I could not change the server name or shutdown the server from the menu at the top.

[Carlo 4330]

Still can't duplicate this.

Either my proxy isn't allowing it

Cloudflare isn't allowing it

I'm using a fresh browser (cleaned before using) so it's never seen Emby before and there is nothing cached.

But I can't duplicate this in my environment.

Going to start testing differently and remove layers.

[Carlo 4330]

Ahh figured it out.  If I go through my domain which has SSL I can't reproduce this yet.

Loading as computer:8096 on my local network NOT using SSL can duplicate.

2 hours ago, Mosuteparo said:

• Viewing, pausing and terminating the streams of other users
• Sending arbitrary notifications to other users
• Viewing a list of all Emby users, their permissions and their email addresses
• Viewing and copying (i.e. stealing) the server's Emby Premiere key
• Gaining view-only access to all administrative tabs

You can pause video of people playing back or send them a message

But you can't see lists of users, email addresses (not even part of emby)

Can't access the Premiere key or anything like this

Some minor view-only things show up.

More an annoyance then a major security breach as hopefully your friends and family aren't going to be trying to hack your server and many will have access to the actual server. 

You can easily set up rewrite rules for these admin URLs to block their use from remote IPs with a proxy if paranoid at least as a temp fix.

What needs to be done on the server is a check first thing on any backend page to check for ADMIN privs before sending any data back to the client.  If no admin priv for that userLOG USER OUT (give them some pain),  LOG HACK ATTEMPT in the Activity Log with the username, time, url, etc, and optionally remove access to "Allow remote connections to this Emby Server" cutting off the user until admin turns this back on. This last thing should be an option.