WAN Access treated like LAN when "X-Forwarded-For" header is set, allowing login w/o password

[moviefan 184]

52 minutes ago, thornbill said:

How do you submit a fix for a vulnerability in a closed source application though?

I was making a joke.  I don't have an answer for this one since the people in charge of fixing this I assume are already being paid.

[andrewds 93]

2 hours ago, rbjtech said:

Emby has long grown out of it's support toolset imo.. 

And the reality of modern network security needs has outgrown Emby Server. This is not a solution that should ever be directly exposed to the Internet. Poking a hole in a consumer firewall and port forwarding through a consumer router to publish this service for anyone to see is at best naive and worst negligent. I appreciate why the ability to distinguish local and remote connections exists, and how that lends itself easily to implementing an ip based ACL, but Emby Server is not a security solution. Combine the ease of deployment with them illusion of security and here we are.

[justinrh 174]

I'd like to hear from the Emby team as to why it decided not to act on this reported vulnerability a long time ago.  I suspect, though, we will never be told.

Kudos to @psefor taking the time to report.

[andrewds 93]

10 hours ago, softworkz said:

There's a CVE now: CVE-2023-33193

Advisory: https://github.com/EmbySupport/security/security/advisories/GHSA-fffj-6fr6-3fgf

Hate to pile on with @pse's nitpicking but I'm rereading the advisory.

Quote

Emby Server systems configured to allow optional remote Internet access that are also configured to allow local admin account usage without a required password that also do not employ a properly configured reverse proxy server or CDN could be exploited to gain remote admin access without a password.

I think this needs to be reworded. It implies that the optional IP-based ACL features of Emby would work as expected but this exploit specifically relies on them not working as expected. Even with the setting "Allow remote connections to this Emby Server." unticked this exploit would still work. All that was required was for Emby Server to be exposed directly to the internet, for example if someone had it installed on a Windows device with the firewall disabled and a consumer router set to treat it as a DMZ device. Alternatively, if someone had previously set up a forwarding rule on their consumer router and the rule were in place, but the server was still listening for connections on the local network on the port to which traffic was being forwarded, again even if Emby server were configured to deny remote connections with specific IP-based ACL rules.

Edited May 27, 2023 by andrewds
clarification

[softworkz 3335]

43 minutes ago, andrewds said:

I think this needs to be reworded. It implies that the optional IP-based ACL features of Emby would work as expected but this exploit specifically relies on them not working as expected. Even with the setting "Allow remote connections to this Emby Server." unticked this exploit would still work. All that was required was for Emby Server to be exposed directly to the internet, for example if someone had it installed on a Windows device with the firewall disabled and a consumer router set to treat it as a DMZ device. Alternatively, if someone had previously set up a forwarding rule on their consumer router and the rule were in place, but the server was still listening for connections on the local network on the port to which traffic was being forwarded, again even if Emby server were configured to deny remote connections with specific IP-based ACL rules.

Can you please re-read? I have reverted this section to my original wording.

[andrewds 93]

1 minute ago, softworkz said:

Can you please re-read? I have reverted this section to my original wording.

I think this change looks good.

[softworkz 3335]

Thanks!

[justinrh 174]

So the attacker could not do any harm to the server machine or expand the attack to other machines in the target's LAN?  That is what the CVE implies, but I want to be sure.

[andrewds 93]

2 minutes ago, justinrh said:

So the attacker could not do any harm to the server machine or expand the attack to other machines in the target's LAN?  That is what the CVE implies, but I want to be sure.

If the Emby Server process was running in an administrative security context the attacker could potentially leverage the exploit to compromise the entire device operating system.

[justinrh 174]

Did Emby find any evidence that the attack went beyond the Emby server app on any servers?

[andrewds 93]

2 minutes ago, justinrh said:

Did Emby find any evidence that the attack went beyond the Emby server app on any servers?

None that they've yet shared but read between the lines. They are calling it a 1200 bot network. That means these devices were fully compromised and at the command of a remote actor.

[softworkz 3335]

18 minutes ago, justinrh said:

Did Emby find any evidence that the attack went beyond the Emby server app on any servers?

No. But we did not look for anything like that.

Also this would all have been none of our business. Scanning file systems or collecting data anywhere beyond of the Emby installation would have been completely inappropriate and inacceptable - to say the least. Please also note that we never "looked into" any Emby server actively, we never established a connection to any customer server.

Those investigations need to be done by the admin/owner of the system and nobody else - definitely not us.
That's one of the many reasons for the shutdowns: Nobody can know what happened on the system so it must be carefully investigated before running it normally again.

Further: What can be found on one system doesn't mean that it's the same on other systems.

So: When you see somebody telling that nothing malicious was found on HIS server - it doesn't mean that the same applies to YOUR server!

[andrewds 93]

3 minutes ago, softworkz said:

No. But we did not look for anything like that.

Also this would all have been none of our business. Scanning file systems or collecting data anywhere beyond of the Emby installation would have been completely inappropriate and inacceptable - to say the least. Please also note that we never "looked into" any Emby server actively, we never established a connection to any customer server.

Those investigations need to be done by the admin/owner of the system and nobody else - definitely not us.
That's one of the many reasons for the shutdowns: Nobody can know what happened on the system so it must be carefully investigated before running it normally again.

Further: What can be found on one system doesn't mean that it's the same on other systems.

So: When you see somebody telling that nothing malicious was found on HIS server - it doesn't mean that the same applies to YOUR server!

I don't tend to 'speak as an IT professional' because you who are reading this do not have any relationship with me financially or otherwise but were I impacted by this exploit, regardless of whether the Emby Server process were running in an administrative security context, I would be at a minimum reinstalling the operating system.

[justinrh 174]

I guess it would have been to ask if Emby was aware of any malicious activity outside of the app. 

5 minutes ago, softworkz said:

we never established a connection to any customer server.

Well, Emby may have not have initiated the connection to the user's server, but obviously Emby did establish a connection in order to read the server settings and take actions on it.  Just a fine point there. 

[pwhodges 1531]

Even finer point, Emby did not "read" information from the servers, they provided an update for the servers which enabled the servers to send it to them...

Paul

[justinrh 174]

11 minutes ago, pwhodges said:

Emby did not "read" information from the servers

I don't get it.  See this post, section "Collected Data".  They had to read something to know whether or not to shut down the server, no?

 

[softworkz 3335]

5 minutes ago, justinrh said:

I don't get it.  See this post, section "Collected Data".  They had to read something to know whether or not to shut down the server, no?

No. A software update included code which determined the situation and then accessed an URL to which it posted exactly the data described in the first post. Nothing more nothing less.

[pwhodges 1531]

As I understand it, they provided an update to all servers (not just ones they knew to be compromised, because they didn't know that) in such a way that at a specific time (so they all did it at once) the servers checked whether they were compromised, and shut themselves down if they were.

Paul

Edited May 27, 2023 by pwhodges

[TeamB 2352]

2 hours ago, andrewds said:

I don't tend to 'speak as an IT professional' because you who are reading this do not have any relationship with me financially or otherwise but were I impacted by this exploit, regardless of whether the Emby Server process were running in an administrative security context, I would be at a minimum reinstalling the operating system.

^^^ this, its toast, burn it down

[jl5437 1]

As far as why Emby chose NOT to notify users of their actions first, and not let the user admin take action first...they feared giving notice would also notify the hackers controlling the bot network that the users sever was allegedly part of.   So, Emby swooped in to save the day and now claim they "took down a bot net"
A action taken, 3 years later.....wow.

 

[cptlores 23]

On 5/26/2023 at 12:47 PM, xe` said:

I would suggest that this is just a symptom of non standard practices such as using a forum for bug reporting rather than a proper ticketing system. I reaslise github still exists for Emby but it is not a prime resource.

I don't see how a ticker system would have helped when a a public exposure where devs even contributed in the thread, is ignored for 3 years..

[rbjtech 4265]

31 minutes ago, cptlores said:

I don't see how a ticker system would have helped when a a public exposure where devs even contributed in the thread, is ignored for 3 years..

A professional change management platform such as Github would have simply highlighted the 'Issue' as it would be given a formal Issue number, tagged as high priority/security and tracked as such.

Logging a security issue, bug or any other important detail in a forum is just hit and miss if you get a response - I'd imagine it certainly isn't tracked beyond best efforts.

I appreciate everyone is not going to have or want a Github account - but the Mods can raise issues they deem worthy if necessary - and then provide a link in the forum.  Github then takes over the management of the issue raised, with all tracking, reporting, comments etc coming from a tool designed to do just that.

 

Edited June 6, 2023 by rbjtech

[ebr 14913]

4 hours ago, rbjtech said:

A professional change management platform such as Github would have simply highlighted the 'Issue' as it would be given a formal Issue number, tagged as high priority/security and tracked as such.

Logging a security issue, bug or any other important detail in a forum is just hit and miss if you get a response - I'd imagine it certainly isn't tracked beyond best efforts.

I appreciate everyone is not going to have or want a Github account - but the Mods can raise issues they deem worthy if necessary - and then provide a link in the forum.  Github then takes over the management of the issue raised, with all tracking, reporting, comments etc coming from a tool designed to do just that.

 

FYI We use GitHub issues internally.

[pwhodges 1531]

Was this issue added to it when first reported?

Paul

[ebr 14913]

12 minutes ago, pwhodges said:

Was this issue added to it when first reported?

Paul

That is kind of irrelevant at this point.  Not sure how many more ways we want to say the ball was dropped on this one.