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

[vaise 340]

I have my firewall blocking countries that dont have emby users, and I am seeing attempts to connect from invalid countries to my emby server with uri path /emby/system/info/public.

I am also seeing attempts to connect to my server with uri path /emby/Sync/Items/Ready

Are these sniffing/hacking attempts, or is this something emby themselves are doing for licensing or something ?

I am really locking down the system by blocking user agents, countries, invalid host names, common uri path attacks etc and I want to make sure I am not crippling emby in some way.

What is so important with these two url's - I tried them and this is returned - should this info be allowed to be 'got' ?

emby.mydomain.com/emby/system/info/public

- comes back with {"LocalAddresses":[],"RemoteAddresses":[],"ServerName":"Emby Live Server","Version":"4.8.8.0","Id":"7bfd892c0ae9465298af79545af9812c"} 

emby.mydomain.com/emby/Sync/Items/Ready

- comes back with Access token is invalid or expired.

 

 

[Luke 42078]

Hi, if it’s just those two then that sounds like Emby apps. Could be a user behind a vpn.

[vaise 340]

None of my users would know what a VPN is - I am in Australia - I allow aus only through the cloudflare WAF , and these are connection attempts from United States, Malaysia, Philippines

[Luke 42078]

OK then I would say block them and then keep an eye on things.

[vaise 340]

Not sure if the results of this server url should be open to all and not behind a user/password ? emby.mydomain.com/emby/system/info/public 

A database of known emby servers could be built by a bot scanner if that is open to all - the version, server name and whatever than long number is (Its not an API key luckily or you would have issues bigtime).

 

[Luke 42078]

1 minute ago, vaise said:

Not sure if the results of this server url should be open to all and not behind a user/password ? emby.mydomain.com/emby/system/info/public 

A database of known emby servers could be built by a bot scanner if that is open to all - the version, server name and whatever than long number is (Its not an API key luckily or you would have issues bigtime).

 

But they won't have server addresses, so in order to build such a database you need server urls to begin with.

[vaise 340]

24 minutes ago, Luke said:

But they won't have server addresses, so in order to build such a database you need server urls to begin with.

There are scanners and bots that scan the entire internets IP4 address range consistently for known 'targets' - just see any firewall log for these.

As soon as you open a port, you are scanned consistently.  Some for 'nice' reasons, many for not nice reasons.

 

 

 

[Lessaj 467]

With a proper reverse proxy config the server address would need to be known for the vhost to be used but for a directly exposed emby server this information can be pulled with just the IP address and port. For most users their external IP would change at some point but a database could still be built rather quickly and then probed to try to get in. 

[rbjtech 5284]

On 01/07/2024 at 00:49, vaise said:

None of my users would know what a VPN is - I am in Australia - I allow aus only through the cloudflare WAF , and these are connection attempts from United States, Malaysia, Philippines

I see those URL's too but only from my allowed Geo ranges.   I'll have to dig a little deeper but my log is suggesting it's the Emby for IOS App.

A question I have is why are you seeing those connections from Geo ranges you have explicitely blocked ?   They should be dropped at source on your FW or whatever you are using to do the Geo blocking, thus not even getting to your RP log ?

[vaise 340]

I use a cloudflare tunnel as a first entry point to emby with cloudflare WAF rules to only allow my country, and only allow the host name emby.mydomain.com.  It also blocks all known scanners and bad bots.  I also have a rule for all the bad uri’s too.    I then redirect requests for emby videos direct to my hardened nginx reverse proxy so not going through cloudflare.  The nginx reverse proxy only listens for emby.mydomain.com and does a 444 disconnect for anything else, it also uses geoip country blocking.

So I can see what is attempted, what is blocked etc, hence my post when I saw these.

 

 

 

[vaise 340]

1 minute ago, rbjtech said:

I see those URL's too but only from my allowed Geo ranges.   I'll have to dig a little deeper but my log is suggesting it's the Emby for IOS App.

A question I have is why are you seeing those connections from Geo ranges you have explicitely blocked ?   They should be dropped at source on your FW or whatever you are using to do the Geo blocking, thus not even getting to your RP log ?

They are dropped (blocked) on the cloudflare waf yes.  But obviously if they come from my country, they would be allowed.

So should that info be allowed to go out from the server with security?

[rbjtech 5284]

1 minute ago, vaise said:

I use a cloudflare tunnel as a first entry point to emby with cloudflare WAF rules to only allow my country, and only allow the host name emby.mydomain.com.  It also blocks all known scanners and bad bots.  I also have a rule for all the bad uri’s too.    I then redirect requests for emby videos direct to my hardened nginx reverse proxy so not going through cloudflare.  The nginx reverse proxy only listens for emby.mydomain.com and does a 444 disconnect for anything else, it also uses geoip country blocking.

So I can see what is attempted, what is blocked etc, hence my post when I saw these.

 

 

 

You log the blocked/dropped attempts ?

[rbjtech 5284]

1 minute ago, vaise said:

They are dropped (blocked) on the cloudflare waf yes.  But obviously if they come from my country, they would be allowed.

ok - good - as you also log dropped attempts, your first post now makes sense.

1 minute ago, vaise said:

So should that info be allowed to go out from the server with security?

Agreed 100% - this needs to be investigated for sure.   No un-auth response should be allowed from the Emby http server.

[rbjtech 5284]

Yep - a curl to that URL returns unnecessary info - such as version, emby server 'name' and an Id.

@Luke @ebr @softworkz

Why is this information being returned on an unAuthenticated request ?!

curl "https://emby.domain/emby/system/info/public"
{"LocalAddresses":[],"RemoteAddresses":[],"ServerName":"EMBY_INSTANCE_NAME","Version":"4.8.8.0","Id":"****466f4ecc4319b1d48f55e311****"}

 

Edited July 3, 2024 by rbjtech

[rbjtech 5284]

8 hours ago, vaise said:

There are scanners and bots that scan the entire internets IP4 address range consistently for known 'targets' - just see any firewall log for these.

As soon as you open a port, you are scanned consistently.  Some for 'nice' reasons, many for not nice reasons.

 

 

 

yep - one word - Shodan.  If you are connected to the internet, you are part of their databases.  How much information is 'leaked' is 100% down to the application/device.   Responding with the emby version, name and id is not good..

[rbjtech 5284]

55 minutes ago, rbjtech said:

Yep - a curl to that URL returns unnecessary info - such as version, emby server 'name' and an Id.

@Luke @ebr @softworkz

Why is this information being returned on an unAuthenticated request ?!

curl "https://emby.domain/emby/system/info/public"
{"LocalAddresses":[],"RemoteAddresses":[],"ServerName":"EMBY_INSTANCE_NAME","Version":"4.8.8.0","Id":"****466f4ecc4319b1d48f55e311****"}

 

I've configured my RP to return a 404 for this URL .. lets see if anything breaks .. it 'might' be needed for the Apps before Auth but I'd rather it not return anything at all ..

edit

Yep - it breaks the Apps ...

So it's needed - you cannot block it - but why it needs this potentially sensitive server related information I'm not sure ... @Luke 

Edited July 3, 2024 by rbjtech

[Q-Droid 989]

1 hour ago, rbjtech said:

Yep - a curl to that URL returns unnecessary info - such as version, emby server 'name' and an Id.

@Luke @ebr @softworkz

Why is this information being returned on an unAuthenticated request ?!

curl "https://emby.domain/emby/system/info/public"
{"LocalAddresses":[],"RemoteAddresses":[],"ServerName":"EMBY_INSTANCE_NAME","Version":"4.8.8.0","Id":"****466f4ecc4319b1d48f55e311****"}

 

This used to return all of those details with an unauthenticated call and the dev team changed it a few years ago to require authentication before it returned the missing data. With the exception of the ID value the rest of the information you can also get from the server login page, so nothing sensitive is revealed anymore.

Yes, this was/is the mechanism used by apps and other APIs to get the server LAN and WAN addresses.

 

[rbjtech 5284]

3 minutes ago, Q-Droid said:

This used to return all of those details with an unauthenticated call and the dev team changed it a few years ago to require authentication before it returned the missing data. With the exception of the ID value the rest of the information you can also get from the server login page, so nothing sensitive is revealed anymore.

Yes, this was/is the mechanism used by apps and other APIs to get the server LAN and WAN addresses.

 

ok thanks.   I would say the server version and server name is sensitive info and allows a web scanner to scan for older possibly vulverable versions.   As no doubt you are aware, you never reveal any information unless it's critical to the cause.   Knowing the emby server version and name, should surely be done post Auth ? 

[Q-Droid 989]

Just now, rbjtech said:

ok thanks.   I would say the server version and server name is sensitive info and allows a web scanner to scan for older possibly vulverable versions.   As no doubt you are aware, you never reveal any information unless it's critical to the cause.   Knowing the emby server version and name, should surely be done post Auth ? 

The web login page displays the server name and the page source has the release. If those are considered sensitive then they would have to change as well.

 

[vaise 340]

So this Public URL is used to build the logon page.  OK. 

When I setup my manual server connections to my server and enter the server (https://emby.mydomain.com) and port (443), then it prompts for the user and password, which is keyed in, from then on, surely all connections can be authenticated - so where does this open url come into it ?

If someone hits my basic web logon page remotely - do they really need to know the server name at that point ?

One more thing, I don't use any remote browser access to emby - I force all my family to install and configure an app - even on PC's and Macs.  The browsers tend to transcode stuff.  I would love a tick box in emby that REMOVES the web browser connection page - a much more secure emby system then as there is no web page for anyone to hit - Obviously the admin page still needs to operate but maybe that can be allowed only from local ip address ranges.

I think I said it before but you could also implement a user agent for each client type, then we can block/only allow these in our firewall's.

 

[rbjtech 5284]

Any response from @Luke @ebr?

It's really no issue if this needs to get resolved down the line, but acknowledgement of it being a problem would be nice, or maybe there is a valid reason ?

[adminExitium 355]

On 03/07/2024 at 16:45, rbjtech said:

Knowing the emby server version and name, should surely be done post Auth ?

I would agree on the name part, but I am not sure about hiding the version because that seems to be the only way to negotiate the correct authentication method to be used because of the different client & server versions available. And anyway, relying solely on security through obscurity has never proved sufficient in history.

You can always hardcode the response for that to return whatever you want (as I do to hide the LAN addresses when coming via the WAN and vice-versa) rather than relying on Emby for now.

[adminExitium 355]

13 hours ago, vaise said:

so where does this open url come into it

I believe this is required when coming from the Emby hosted app at https://app.emby.media/ since it needs to try all available URLs to see which one is reachable and working.

[rbjtech 5284]

23 minutes ago, adminExitium said:

I would agree on the name part, but I am not sure about hiding the version because that seems to be the only way to negotiate the correct authentication method to be used because of the different client & server versions available. And anyway, relying solely on security through obscurity has never proved sufficient in history.

Maybe just return the major version - 4.8 for example.

I've always been advised to never expose any info that you do not have to - as an attacker may just use that information to quickly determine a vulnerability on an older version without the need to probe further.

Edited July 4, 2024 by rbjtech

[visproduction 315]

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