Jump to content

Where do I report a security vulnerability?


Pignuuu
Go to solution Solved by rbjtech,

Recommended Posts

Hi, I believe I have found something allowing users with a restricted account to a server to see all content on a server. I don't want to post how to recreate it publicly as then people might take advantage of it so preferably I would want to take this privately. But if not then I am more than happy to post about it here. Since the exploit is still working on the newest version available I am going to assume it has not been discovered before.

Link to comment
Share on other sites

  • Solution
8 minutes ago, Pignuuu said:

Hi, I believe I have found something allowing users with a restricted account to a server to see all content on a server. I don't want to post how to recreate it publicly as then people might take advantage of it so preferably I would want to take this privately. But if not then I am more than happy to post about it here. Since the exploit is still working on the newest version available I am going to assume it has not been discovered before.

PM @Luke and @ebr

They are the Admins - check their profiles.

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, rbjtech said:

PM @Luke and @ebr

They are the Admins - check their profiles.

Thanks, I sent Luke a dm now. Wasn't aware they had messaging on here, pretty neat.

  • Thanks 1
Link to comment
Share on other sites

This vulnerability might be more grave when combined with this:

TL;DR: When exposing Emby to the Internet, any security feature that depends on the distinction between "public" and "local" IP is broken because you can trick Emby into thinking you are "local" by just by setting "X-Forwarded-For: 127.0.0.1".

  • Like 1
Link to comment
Share on other sites

8 hours ago, pse said:

This vulnerability might be more grave when combined with this:

TL;DR: When exposing Emby to the Internet, any security feature that depends on the distinction between "public" and "local" IP is broken because you can trick Emby into thinking you are "local" by just by setting "X-Forwarded-For: 127.0.0.1".

Yeah I can see that being a problem. Gaining access to a general user account then using my exploit you have access to everything stored on the server.

Link to comment
Share on other sites

Gilgamesh_48
40 minutes ago, Pignuuu said:

Yeah I can see that being a problem. Gaining access to a general user account then using my exploit you have access to everything stored on the server.

Yet another good argument against using/allowing remote access.

  • Like 1
Link to comment
Share on other sites

Just now, Gilgamesh_48 said:

Yet another good argument against using/allowing remote access.

Until it is safer I have actually gone as far to add a IP whitelist. So when I am away from home I just connect to my private VPN hosted with OpenVPN.

Link to comment
Share on other sites

A properly set up reverse proxy should replace such a header from outside the network with a correct one.

Paul

Link to comment
Share on other sites

8 hours ago, pwhodges said:

A properly set up reverse proxy should replace such a header from outside the network with a correct one.

9 hours ago, Pignuuu said:

Until it is safer I have actually gone as far to add a IP whitelist. So when I am away from home I just connect to my private VPN hosted with OpenVPN.

I have been doing both to have a minimum of confidence in exposing Emby on the Internet. There is a reverse proxy (nginx) removing the problematic headers (hoping I got all of them), and I whitelisted the proxy in emby.

I'm using TLS as well -- what about adding support for verifying a client certificates? All emby needs for this is a way to configure a CA for remote connections. When set, this would require clients to provide a client certificate that is (possibly transitively) signed by the CA. This is another thing that can also be done in the reverse proxy.

So there is ways to work around this -- but emby relys on the distinction between local and remote clients. The most important place is the checkbox to allow users "remote connection" to the emby server. Relying on this is dangerous.

At least, the documentation should state the for public exposure, emby needs to be secured by a reverse proxy.

 

Link to comment
Share on other sites

So has anything been acknowledged by the Admins ?

Is this effectively a Zero Day that can compromise any remote system ?

If yes, then depending how much is already public knowledge - users should be made aware on the Blog and via any other communication methods asap so the users can turn off remote access while an emergency fix is developed.

Security Bugs/Coding errors happen - it how you deal with them that is important to maintain user trust.

 

  • Like 1
Link to comment
Share on other sites

horstepipe
13 hours ago, pwhodges said:

A properly set up reverse proxy should replace such a header from outside the network with a correct one.

Paul

Does @pir8radios example config include that?

Edited by horstepipe
Link to comment
Share on other sites

1 hour ago, horstepipe said:

Does @pir8radios example config include that?

Another way to look at this is an RP/WAF should not passthrough the client header - it should always recreate it's own.

 

Link to comment
Share on other sites

9 hours ago, rbjtech said:

So has anything been acknowledged by the Admins ?

Is this effectively a Zero Day that can compromise any remote system ?

I wouldn't go that far, it doesn't always give you unauthenticated remote access to any system, only under the circumstances I mentioned here last year. But I don't think they are  uncommon. At the very least, it is a privilege escalation for authenticated users, tricking the server into thinking you're local. Worst case, if you can guess a user that is "local only" and doesn't have a password, you're in.

The admins seem to rely in parts on "security through obscurity", as there is an option to "Hide user from the login screen on devices that they've never signed into". Still, if you manage to guess a user's name without "allow remote access"...

Edited by pse
  • Like 1
Link to comment
Share on other sites

14 hours ago, pse said:

I wouldn't go that far, it doesn't always give you unauthenticated remote access to any system, only under the circumstances I mentioned here last year. But I don't think they are  uncommon. At the very least, it is a privilege escalation for authenticated users, tricking the server into thinking you're local. Worst case, if you can guess a user that is "local only" and doesn't have a password, you're in.

The admins seem to rely in parts on "security through obscurity", as there is an option to "Hide user from the login screen on devices that they've never signed into". Still, if you manage to guess a user's name without "allow remote access"...

Yep - and this is my concern.

A lot of users are going to simply create local accounts with no passwords because they have not enabled remote access for that user.   If one of them is Admin, then it's a more serious problem obviously.

I'd like to see some comms on this from the Emby Team - with clear instructions on what they are doing about it, and ways to minimise the risk.  

Password complexity enforcement is of course 'on the list' but in Q3 2022, this is frankly unforgiveable on an internet facing application ....  TLS enforcement is of course required to make any of this secure .. but that's another story.

Link to comment
Share on other sites

1 hour ago, rbjtech said:

Yep - and this is my concern.

A lot of users are going to simply create local accounts with no passwords because they have not enabled remote access for that user.   If one of them is Admin, then it's a more serious problem obviously.

I'd like to see some comms on this from the Emby Team - with clear instructions on what they are doing about it, and ways to minimise the risk.  

Password complexity enforcement is of course 'on the list' but in Q3 2022, this is frankly unforgiveable on an internet facing application ....  TLS enforcement is of course required to make any of this secure .. but that's another story.

To add salt to the wound, using my exploit you would be able to download everything on the server even if you don't have permissions to view those files.

Link to comment
Share on other sites

ok - entirely your call of course, but with the ethics of responsible disclosure (which you appear to have followed) - I would give them a reasonable amount of time to investigate and respond.  After which, posting to the public emby forum that there is a exploit available and users should do X to mitigate it - but NOT posting specific details would personally be my next move.

Uploading the exploit and how to use it is obviously not where we want this to go ... 🤪

@Luke @ebr

 

  • Agree 1
Link to comment
Share on other sites

Truth is that Emby is not an overly secure product. The only reason why there aren't more exploits is that the count of public Emby servers is too small to be a really attractive target for attacking.
Once there is an exploit, an attacker still needs to find Emby servers to target. For that reason, I have the following

#1 Advice: Never use ports 8096, 8920 for public Emby Servers. Use 80 and 443 instead!

Explained here:

Link to comment
Share on other sites

The question is how many of those entries are from within the last 24h. All older dynamic IPs will be of no value.
Your point is valid for static IPs, though!

Link to comment
Share on other sites

  • All my accounts have complex passwords, 15 characters or more.
  • Only accounts I want to allow remote access have it 
  • Account names are not obvious like "Admin" or "Administrator"
  • Only one admin Emby account, the rest have limited rights
  • I have reverse proxy with nginx on Synology DSM7
  • NGINX is set to UK access only
  • TLS 1.2 paid certs are used with 2048 minimum length cipher key
  • I hide all user logins so none are presented on login screens
  • DSM7 itself has 2FA for its main admin account which is renamed
  • The default root password from Synology for DSM7 was changed to a complex one.
  • I do not use default Emby port and only one port is forwarded to NGINX
  • External access is via a sub-domain that is not listed on Google or has other traffic
  • It is patched and up to date

Am I affected?

Edited by unisoft
Link to comment
Share on other sites

5 hours ago, unisoft said:
  • All my accounts have complex passwords, 15 characters or more.
  • Only accounts I want to allow remote access have it 
  • Account names are not obvious like "Admin" or "Administrator"
  • Only one admin Emby account, the rest have limited rights
  • I have reverse proxy with nginx on Synology DSM7
  • NGINX is set to UK access only
  • TLS 1.2 paid certs are used with 2048 minimum length cipher key
  • I hide all user logins so none are presented on login screens
  • DSM7 itself has 2FA for its main admin account which is renamed
  • The default root password from Synology for DSM7 was changed to a complex one.
  • I do not use default Emby port and only one port is forwarded to NGINX
  • External access is via a sub-domain that is not listed on Google or has other traffic
  • It is patched and up to date

Am I affected?

How would you know if you were ?

Link to comment
Share on other sites

27 minutes ago, rbjtech said:

How would you know if you were ?

well that's my question :) I've done what I can this end as a web server doing the normal things.

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...