Jump to content

non-admin-user can visit admin dashboard


Oceanus

Recommended Posts

neik
6 hours ago, cayars said:

But you can't see lists of users

You kinda can: If you use the "Playback Reporting" plugin it is accessible if you use the direct link and there users are visible.

€dit: The Metadata Manager is also accessible using the direct link.

Edited by neik
Link to comment
Share on other sites

8 hours ago, Mosuteparo said:

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.

I added this block rule in Cloudflare:

(http.referer contains "emby.media")

And it seems to be preventing access from https://emby.media/

Can anyone confirm whether this is the proper way to do this? (I had no idea logging in like this was possible until this thread. Yikes.)

Link to comment
Share on other sites

crusher11
12 hours ago, GPlayer said:

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

This bug has been reported multiple times going back months if not years.

Link to comment
Share on other sites

crusher11
12 hours ago, GPlayer said:

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

This bug has been reported multiple times going back months if not years.

Link to comment
Share on other sites

3 hours ago, crusher11 said:

This bug has been reported multiple times going back months if not years.

Source other than this thread?

Link to comment
Share on other sites

Thanks crusher11

5 hours ago, C.S. said:

I added this block rule in Cloudflare:


(http.referer contains "emby.media")

And it seems to be preventing access from https://emby.media/

Can anyone confirm whether this is the proper way to do this? (I had no idea logging in like this was possible until this thread. Yikes.)

No that just checks where the person was previous when coming to your site.

What you need to do is page rewrites at the proxy level. Something similar to this https://support.cloudflare.com/hc/en-us/articles/200172286-Configuring-URL-forwarding-or-redirects-with-Cloudflare-Page-Rules

Problem is that with a free Cloudflare account you only get 3 page rules and most likely you already use 2.

 

What would be helpful is instead of

https://domain/web/index.html#!/dashboard

use

https://domian/web/admin.html#!/dashboard

in Emby Server.  So all non admin use the "index.html" while anything admin goes through "admin.html".  That would the admin check quite easy to do AND would make filtering all admin functionality quite easy with a proxy of any type using ONE SIMPLE redirect rule. A change like this might be pretty difficult, but would make life easier for filtering purposes and security.

 

 

Link to comment
Share on other sites

2 hours ago, cayars said:

No that just checks where the person was previous when coming to your site.

What you need to do is page rewrites at the proxy level. Something similar to this https://support.cloudflare.com/hc/en-us/articles/200172286-Configuring-URL-forwarding-or-redirects-with-Cloudflare-Page-Rules

Problem is that with a free Cloudflare account you only get 3 page rules and most likely you already use 2.

Also in the same rule I've got this:

(not http.request.uri.path contains "/emby")

..which seems to block access to the web interface which was my goal from the beginning. (I didn't know until reading this thread that the web interface was still accessible through https://emby.media/ )

So if Emby Connect is not enabled for my users, and I've got these blocks in Cloudflare:

(not http.request.uri.path contains "/emby") or (http.referer contains "emby.media")

..is there another way into the web interface that I'm missing? They can't use my ip directly since I've got the port whitelisted for Cloudflare only, of course. At this point I don't know how I would log in to the web interface remotely, but there's a lot I don't know.

Link to comment
Share on other sites

I might be dense but how is this going to work?

You're block "/emby" but is that used at all?

Why block users coming from emby.media?

 

But assuming you get filtering working you have two options if you need to remote admin the server.  One setup VPN to your local network so you don't go through Cloudflare OR login to Cloudflare and turn off the rule while doing admin then turn it back on again.

Link to comment
Share on other sites

36 minutes ago, cayars said:

You're block "/emby" but is that used at all?

Why block users coming from emby.media?

 

But assuming you get filtering working you have two options if you need to remote admin the server.  One setup VPN to your local network so you don't go through Cloudflare OR login to Cloudflare and turn off the rule while doing admin then turn it back on again.

I'm blocking Not "/emby" which seems to block "/web"

My goal is block all my users from the web interface, because they don't need it. I thought I had effectively done that, but then I read this thread, and so now I need to block emby.media. I've already got my VPN set up if I need to log in to the web interface.

Edit:

Sorry, before when I said "At this point I don't know how I would log in to the web interface remotely", I meant I don't know how I would do it as a regular user. I see now the way I said it could be interpreted as a request for help. No need for help in that regard - I would just like to know if my current method should be effective in blocking my users (and the world) from the web interface.

Edited by C.S.
clarity
  • Like 1
Link to comment
Share on other sites

chef
On 7/25/2020 at 9:52 PM, cayars said:

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.

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.

Still, accessing the messaging system endpoints and mild playback control isn't great. 😳

It'll most likely be fixed in a future release.

 

 

Edited by chef
Link to comment
Share on other sites

3 minutes ago, chef said:

Still accessing the messaging system endpoints and mild playback control isn't great. 

 You say it only happens internally? On port 8096? What about people who have opened 8920, or the equivalent of the public port and address?

I'm not making light of this.  It's a security problem that needs fixing.

I tried to throw out a couple of idea to help reduce exposure but also to point out the reality of what can be done. It's more annoyance then destructive.   

This isn't an exploit that can be ran from anyone on the Internet as it takes a person with an account on your system already. If you only share with friends and family the chance of them trying to hack you is what?

I'm not saying anything about external or for ports 8096 & 8920.  I was just saying that I had not been able to reproduce this going through my SSL domain and Cloudflare. I was able to do it locally which is all I needed to reproduce, so not saying anything more than I too can reproduce it but had to do it inside my LAN. Others can likely do it remotely as well.  I have some rewriting taking place so that likely blocked it for me.

  • Like 1
Link to comment
Share on other sites

chef
1 minute ago, cayars said:

I'm not making light of this.  It's a security problem that needs fixing.

I tried to throw out a couple of idea to help reduce exposure but also to point out the reality of what can be done. It's more annoyance then destructive.   

This isn't an exploit that can be ran from anyone on the Internet as it takes a person with an account on your system already. If you only share with friends and family the chance of them trying to hack you is what?

I'm not saying anything about external or for ports 8096 & 8920.  I was just saying that I had not been able to reproduce this going through my SSL domain and Cloudflare. I was able to do it locally which is all I needed to reproduce, so not saying anything more than I too can reproduce it but had to do it inside my LAN. Others can likely do it remotely as well.  I have some rewriting taking place so that likely blocked it for me.

Absolutely 😄

Most likely anyone with their shared server to friends and family won't have to worry, and if they are running a larger server... Well... Emby is about friend and family.

 

 

  • Like 1
Link to comment
Share on other sites

TeamB
On 7/26/2020 at 5:27 PM, neik said:

You kinda can: If you use the "Playback Reporting" plugin it is accessible if you use the direct link and there users are visible.

€dit: The Metadata Manager is also accessible using the direct link.

these are community plugins and will need to be fixed in the plugin code.

post over on the plugins forum to bring attention to this there.

  • Like 1
Link to comment
Share on other sites

Painkiller8818

So does this mean it won't be fixed because it is just for friends and family?

And whats about every user can add, change or delete Collections? Even if i disallow it for the User? Is this also a thing we should ignore because it is only for friends and family?

Edited by Painkiller8818
Link to comment
Share on other sites

chef
10 minutes ago, Painkiller8818 said:

So does this mean it won't be fixed because it is just for friends and family?

And whats about every user can add, change or delete Collections? Even if i disallow it for the User? Is this also a thing we should ignore because it is only for friends and family?

Sorry, I shouldn't have said that. They'll fix it. 

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

This bug is still present in the latest stable version 4.5.4. I can also confirm that you can visit the premiere key page as non-admin-user by visiting yourdomain/web/index.html#!/embypremiere, but the key itself won't show up. So you will not be able to steal the premiere key as non-admin-user. You are also able to visit the users page, but won't see any users.

 

Nevertheless this should be fixed soon, but i don't think it will. The issue with collections and playlist being editable even though the user is denied access to them is present for more than five years now and nothing happened. 

Link to comment
Share on other sites

19 hours ago, Oceanus said:

So you will not be able to steal the premiere key as non-admin-user. You are also able to visit the users page, but won't see any users.

So there is actually no problem there, correct?

Link to comment
Share on other sites

Non-admin-user can still see and cancel the streams of other users, can send them messages, can see all installed plugins and mabye install new plugins(at least i see the install button as non-admin-user).

A major security breach in my eyes, but most likely just an inconvenience in yours.  

Edited by Oceanus
Link to comment
Share on other sites

On 12/24/2020 at 12:19 PM, Oceanus said:

Non-admin-user can still see and cancel the streams of other users, can send them messages, can see all installed plugins and mabye install new plugins(at least i see the install button as non-admin-user).

A major security breach in my eyes, but most likely just an inconvenience in yours.  

I was specifically responding to the Premiere page and User's page.  There is no vulnerability there, correct?

Link to comment
Share on other sites

The "vulnerability" in itself is that a non-admin can get to any admin section (regardless of what they can see or change).

  • Like 2
  • Thanks 1
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...