Jump to content

Where do I report a security vulnerability?


Pignuuu
Go to solution Solved by rbjtech,

Recommended Posts

rbjtech
55 minutes ago, unisoft said:

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

It was a loaded question ;) 

Monitoring is a key part of active security - so while all the above is great - would you be actively alerted if lets say a repeat attempt was made to use your disabled Admin accounts ?

Link to comment
Share on other sites

Q-Droid
On 9/3/2022 at 7:39 AM, pse said:

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

I wasn't aware of this one and I'm surprised this hole is still there.

Link to comment
Share on other sites

unisoft
2 hours ago, rbjtech said:

It was a loaded question ;) 

Monitoring is a key part of active security - so while all the above is great - would you be actively alerted if lets say a repeat attempt was made to use your disabled Admin accounts ?

Yes, I didn't cover that bit off originally though.

Link to comment
Share on other sites

justinrh
17 hours ago, softworkz said:

within the last 24h. All older dynamic IPs will be of no value.

Not true.  I've had the same IP address for over a year, and my ISP would not give me a static.  I had the same address with my previous ISP for years also.  As long as I'm not disconnected for longer than the lease time I won't get a new address.  But, I understand your point  😀

Link to comment
Share on other sites

1 minute ago, justinrh said:

Not true.  I've had the same IP address for over a year, and my ISP would not give me a static.  I had the same address with my previous ISP for years also.  As long as I'm not disconnected for longer than the lease time I won't get a new address.  But, I understand your point  😀

Yes - I had such "non-changing dynamic IP" for a while myself, and I had first written "Most dynamic IPs", but then changed to All as I was too lazy to explain "most" 😉 

Link to comment
Share on other sites

Browsing through some of the Shodan results reveals that the non-standard authentication mechanism which Emby is using is not just a weakness in itself, but it is also what makes Emby Servers discoverable. And that's really unfortunate.

It's the Access-Control-Allow-Headers header 

image.png.966fe92ad017a42aafd7df8ed68700e7.png

Link to comment
Share on other sites

TeamB

Yes, any none standard response header can be used to identify the service, also response content like html login screens have a huge wealth of identifiable info like page title etc

Link to comment
Share on other sites

From my assessment so far, it appears that HTML/HEAD/TITLE and favicon (yet not searchable) is the only other information they are storing for HTTP protocol connections (besides the response headers and the certificate).
Does that align with your experience?

Link to comment
Share on other sites

TeamB
15 minutes ago, softworkz said:

From my assessment so far, it appears that HTML/HEAD/TITLE and favicon (yet not searchable) is the only other information they are storing for HTTP protocol connections (besides the response headers and the certificate).
Does that align with your experience?

yes, but there are also other scanners out there doing different things. This is just one example. There are also none public projects doing this sort of thing and selling lists for $, same people that collect and sell botnet info and cc card info.

Basically if you expose it, it is recorded.

Link to comment
Share on other sites

25 minutes ago, TeamB said:

yes, but there are also other scanners out there doing different things. This is just one example. There are also none public projects doing this sort of thing and selling lists for $

That's right, but that brings us back to my original point: Emby is not big enough for those people to perform extra effort for detection. This is mass data processing, and when the first http request doesn't bring evidence, it's unlikely these people would do a second one (I mean - not for Emby), because such operational behaviors are multipliers to their processing load.
What their "clients" want and pay for are things like vulnerable word press instances for which a whole bunch of exploits exists or similar. Emby is not big enough to be an attractive scanning target.
Yet, when instances are so easy to discover like with Shodan, then that's something that we can avoid to happen. We won't be able to provide high security, probably not even in the long run, as that will always depend on each individual user. But what we should and can do at least, is to avoid such cheap and obvious ways of discovery. 
For any attacker, it's always about the relation between the required effort and the expected success rate, hence I think we should do everything we can to keep that relation as unattractive as possible.

Edited by softworkz
  • Agree 1
Link to comment
Share on other sites

seanbuff
1 hour ago, softworkz said:

So we'll have something to compare after the next release.. 🙂 

This is all valuable and useful information, but I think people are getting detracted from the OP's original post.

It wasn't about Emby's discoverability on public networks, etc. It was more about a user who already has access to your server (albeit restricted access) being able to see more than they should.

So I don't expect anything to change with how Emby Servers advertise themselves, but happy to be corrected 🙂

Link to comment
Share on other sites

27 minutes ago, seanbuff said:

It wasn't about Emby's discoverability on public networks, etc. It was more about a user who already has access to your server (albeit restricted access) being able to see more than they should.

And then another user mentioned another exploit and the discussion went about the risk of elevation vulnerability. The wider-level door-opener would be the ability to gain restricted access which would in turn increase the risk of the elevation vulnerability. Once there would be a working chain of attack, the remaining question will be how to find suitable targets.
Such chains of attack are way more dangerous (=valuable for an attacker) than every single step alone. 

These things are closely related and cannot be evaluated in an isolated way only.

37 minutes ago, seanbuff said:

So I don't expect anything to change with how Emby Servers advertise themselves, but happy to be corrected 🙂

Feel happy and corrected!

  • Haha 1
Link to comment
Share on other sites

50 minutes ago, seanbuff said:

So I don't expect anything to change with how Emby Servers advertise themselves

What do you think, why I posted that screenshot "for reference"? 🙂 

After the next release I don't want to see a 5k list on shodan anymore.

Link to comment
Share on other sites

seanbuff
3 minutes ago, softworkz said:

After the next release I don't want to see a 5k list on shodan anymore.

I think we'd all like to see the same, but i'm sure you've been around here long enough to know how fast things really move.

Here's to hoping though 🤞🏽

Link to comment
Share on other sites

I'm not around here just for chatting. But before a change can happen, the circumstances and risks need to be explained and understood.

When it's important, though, things can go pretty fast. Luke has changed the html title and I have suppressed the transmission of headers.

Hence I said: "Feel happy and corrected!"

  • Like 3
Link to comment
Share on other sites

pwhodges
4 hours ago, softworkz said:

For any attacker, it's always about the relation between the required effort and the expected success rate, hence I think we should do everything we can to keep that relation as unattractive as possible.

It's more than just getting through a layer of security, it's also a matter of what they can do beyond that once they have.  If access to Emby enables them to enter other parts of the system, that's far more interesting to them than merely getting access to a load of video files. (EDIT: as you noted in a later post)

Paul

Edited by pwhodges
  • Agree 1
Link to comment
Share on other sites

12 minutes ago, Pignuuu said:

This took a quick turn lol.

Yeah, you are right. Your question might have been answered, but the subject isn't fixed yet (probably).

I'm not involved, so this will require @Luke or @ebr to respond to.

Link to comment
Share on other sites

8 hours ago, seanbuff said:

It was more about a user who already has access to your server (albeit restricted access) being able to see more than they should.

Correct.  Just to be crystal clear for the casual reader - what was reported here is of absolutely no use to someone who simply discovers your server.

Link to comment
Share on other sites

Q-Droid
7 hours ago, ebr said:

Correct.  Just to be crystal clear for the casual reader - what was reported here is of absolutely no use to someone who simply discovers your server.

That might be the case. But this reported potential vulnerability combined with the verified one posted by @pse pushed me to spin up a reverse proxy for my server. I should have done it a long time ago and this combo scared me into action.

Though the OP isn't clear about what "all content on the server" means. Whether all content within Emby or all content on the system.

Edited by Q-Droid
Link to comment
Share on other sites

TeamB
2 hours ago, Q-Droid said:

That might be the case. But this reported potential vulnerability combined with the verified one posted by @pse pushed me to spin up a reverse proxy for my server. I should have done it a long time ago and this combo scared me into action.

Though the OP isn't clear about what "all content on the server" means. Whether all content within Emby or all content on the system.

agree, it is never a single attach vector alone, combinations are the key and if you could gain "local" access to an unsecured (no password) local account using the header injection and then this one to gain elevated access, install a plugin that lets you run scripts (Emby Scripter-X or something) and trigger some events or just outright delete the library and all media.

I agree Emby is not widely used enough to warrant a mass campaign of attach however that is not always the aim.

So lets say you wanted to tarnish the Emby brand name and you were not a very nice person. All you would have to do is compromise a few dozen machines, not enough to kill the machines but enough to piss the user off, like deleting their library etc and all of a sudden you have the forum flooded with OMG my library has been deleted. Word gets out and boom Emby is no longer secure, avoid, dont connect to the internet etc etc and people will switch back to other alternatives (Plex, Jellyfin etc)

This can happen and I think it might have already at one point (just speculation based on what I have seen over the last few years).

  • Like 1
Link to comment
Share on other sites

moviefan
On 9/6/2022 at 12:56 AM, 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?

I think the answer here is most likely not affected.  There are two issues being described, but they seem like the same one.

Users which have admin rights but have been configured to allow in locally without password can set a flag in their HTTP headers tricking Emby into thinking those users are local.  So if a remote user identifies this setting is enabled for a particular account they can immediately gain administrative access on an exposed server remotely and do whatever else they want.  But since you have NGINX installed as a reverse proxy, it should overwrite the field used in this trick, and Emby will never be fooled by it.

Since you have 15 char pws or more, and don't list logins, someone would need to correctly guess an admin username and then brute force the password.  Which was a risk that already existed before this was announced.

Edited by moviefan
grammar
Link to comment
Share on other sites

14 hours ago, Q-Droid said:

isn't clear about what "all content on the server" means. Whether all content within Emby or all content on the system.

Only items in your Emby libraries.

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