Jump to content

non-admin-user can visit admin dashboard


Oceanus

Recommended Posts

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.

 

Link to comment
Share on other sites

cayars

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

How did you reproduce this?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

homedash.thumb.jpg.51aeb7a011a9934e9c46c120c1af830c.jpg.d4efdc780d76293f780d4a1dece94030.jpg

Paul

Edited by pwhodges
Link to comment
Share on other sites

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 by pwhodges
Link to comment
Share on other sites

cayars

@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

Link to comment
Share on other sites

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

incog.thumb.jpg.9c9fe36ff8184f3670e526361e137a1d.jpg

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 by pwhodges
Link to comment
Share on other sites

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 by pwhodges
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

 

image.thumb.png.33575e3891a71e9717f2dd2d4775f64f.png

Edited by Alternative311
Link to comment
Share on other sites

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 by Painkiller8818
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Mosuteparo
  • Thanks 1
Link to comment
Share on other sites

cayars

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

cayars

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.

Link to comment
Share on other sites

cayars

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...