Internet Connections on uri path /emby/system/info/public

[adminExitium 355]

15 minutes ago, rbjtech said:

Maybe just return the major version - 4.8 for example.

 

That would be useful if Emby followed semantic versioning rules for breaking changes, but I don't think they do that.

[adminExitium 355]

3 minutes ago, visproduction said:

What about throwing a login form for anyone arriving at the Emby address

Easily done via any reverse proxy with HTTP Basic Auth. But I am not sure Emby should be doing that itself because that has its own issues like password resets, user-specific passwords, etc. And if it is made any more complex, then it is no different than the existing Auth mechanism with all its caveats of API versioning, etc.

[Q-Droid 989]

By the way, the name is the Emby server name, not the hostname where Emby runs if that matters.

[vaise 340]

4 hours ago, visproduction said:

What about throwing a login form for anyone arriving at the Emby address?  So bots and anyone else can't get past the form without a username / password.  Maybe this would still allow Emby users to breeze past with cached passwords.  This way no one would ever suspect an Emby server is running at your domain / IP.  Seems like this would be an easier fix.

React example: https://dev.to/jeremyling/how-to-build-a-loginsignup-form-with-validation-in-2-minutes-in-react-1a27

This would break the app devices though I believe (as I could do this at the reverse proxy stage).  So unless they seperate the web only from the app access url, I don’t think this can be done.

[visproduction 315]

You just use the form to get access, then do not limit any traffic.  It would be just a gatekeeper that would foil any attempt from bots.  They would just never get past the form.  I wonder if this is possible.  Initial traffic to the choosen port, say :8096 first hits the custom login form.  Once username and password is made, then open up all traffic from that IP to go directly in to Emby.  The user then pulls Emby login from browser cache.  So then the question is when and how does the session time out so the custom form starts up again.  I don't know.  Can traffic be sensed or just set it to work fine for a day, 3 days or a week.  If the user is real and they login, then their IP should be accepted and they are not a bot.

I have not coded such a form like this.  It just seemed like it might be easier to add it, then trying to get it all setup and have Emby code do it.  Does anyone reading this have more experience with such a custom login?  Does this sound possible?

[vaise 340]

5 minutes ago, visproduction said:

You just use the form to get access, then do not limit any traffic.  It would be just a gatekeeper that would foil any attempt from bots.  They would just never get past the form.  I wonder if this is possible.  Initial traffic to the choosen port, say :8096 first hits the custom login form.  Once username and password is made, then open up all traffic from that IP to go directly in to Emby.  The user then pulls Emby login from browser cache.  So then the question is when and how does the session time out so the custom form starts up again.  I don't know.  Can traffic be sensed or just set it to work fine for a day, 3 days or a week.  If the user is real and they login, then their IP should be accepted and they are not a bot.

I have not coded such a form like this.  It just seemed like it might be easier to add it, then trying to get it all setup and have Emby code do it.  Does anyone reading this have more experience with such a custom login?  Does this sound possible?

The form can’t be used on the emby apps though so this would not work.

[vaise 340]

Further to my request for a custom user agent for the emby apps (then we can ONLY allow these through firewall and hence no allow any web traffic at all and have a secure front end), I notice that the latest dot version of immich has just rolled out custom proxy headers, configurable for each install of their app - which means a very secure setup is possible - Some this for the future for emby perhaps ?

[Luke 42078]

14 hours ago, vaise said:

Further to my request for a custom user agent for the emby apps (then we can ONLY allow these through firewall and hence no allow any web traffic at all and have a secure front end), I notice that the latest dot version of immich has just rolled out custom proxy headers, configurable for each install of their app - which means a very secure setup is possible - Some this for the future for emby perhaps ?

This isn't a good approach for identification. A custom user agent isn't possible in the web app.

In other cases it will be possible in some cases but it's hard to guarantee it will be possible in all cases.  For example, on most platforms, the mechanisms that pull data from Emby Server, display images, and play audio/video are three (sometimes four) different things. And often times the image rendering and audio/video player are handled by the system where a custom user agent might not be possible.

And then there's external things like apps that support launching external players, device notifications that display images, etc. How are you going to get a custom user agent into those things? (You can't).

You could probably sort of achieve this now without any settings in Emby though - just monitor the logging in your reverse proxy of the apps you use and whitelist. Just be aware that some things will break until you've figured out the complete list for the apps that you use.

[softworkz 5066]

I had a concept for preventing detection by shodan et al., just need to find it again, but the key points I remember:

• They are not using this API endpoint for detection in the first place
  So I wouldn't bother with trying to disable/hide that endpoint
• An HTTP request is expensive in time, so they'll surely avoid making any requests just for testing
  (much more expensive than an open-port check)
• Primary detection indicators are
  • Port numbers (is it an "Emby Port")
  • The returned default html document's content

Miitigation methods:

• If the web ui is disabled for remote access, provide the exact same response like a freshly installed Apache web server
  Maybe allow to specify a name for the page (that you need to know in order to access the web ui)
• Delay the response for an API request from an unknown (not seen before) source by something like 5-8 seconds
  Time is precious when scanning the whole web, so they need to keep their timeouts tight and can't wait such a long time for a response

It's a bit more complex, but those are the basic ideas.

[softworkz 5066]

Regarding "sensitive information": We are not considering the server name nor the server version as such. 

• Server Name
  If you think that your server name would be revealing anything in any way, please rename it (e.g. "Emby" or if you have multiple for example "Emby1", "Emby2")
• Server Version
  This is crucial for clients to log in, it can't be hidden. But it really doesn't change much for an attacker, because
  • One could instead just find out the API differences between specific versions of Emby Server and make a request to a new or removed endpoint in order to know the server version (at least approximately)
  • In most cases, one would try the exploit right away instead of querying the version before (one request less for each server)