Emby Blog

On 5/28/2023 at 2:21 PM, justinrh said:

Now that's really bad when the competitor is, uh, monitoring the forum and it fixes the vulnerability for its own software.  I'm glad both products have it patched, but I'm sad that Emby had to experience this.

 

Except they say the vulnerability was patched in March 2021. The vulnerability was first reported on the forums here in February of 2020 (when there was likely a spike in new users). So either they never had that vulnerability known, or they were watching when the flag was first raised and fixed it internally

22 minutes ago, sera_denoir said:

Except they say the vulnerability was patched in March 2021. The vulnerability was first reported on the forums here in February of 2020 (when there was likely a spike in new users). So either they never had that vulnerability known, or they were watching when the flag was first raised and fixed it internally

The issue was discovered independently (and fixed) by a member of the Jellyfin team. To the best of my knowledge they were completely unaware of the previous report here. 

Can someone explain the elevated admin account terminology. On a linux machine if emby is running as a service under the emby username then that is not an admin user correct?

I also would like more info on how the attack occurred.  The notice says that a "correctly setup" reverse proxy wouldn't have had this issue but what does that really mean? From my understanding, my reverse proxy is working as designed and no other internal resource has been compromised... So is that statement correct or does it not matter what we had setup before emby, aka if emby was open to have logins from the internet and an admin account had local access = no password, then it became a problem? 

1 hour ago, pr3dict said:

if emby is running as a service under the emby username then that is not an admin user correct?

Correct. Not an admin for the OS, but it might be an Emby admin which could the then whatever the emby account it allowed to do. 

55 minutes ago, softworkz said:

Correct. Not an admin for the OS, but it might be an Emby admin which could the then whatever the emby account it allowed to do. 

Ok - What about the "how this happened thing?". Why was the statement of a correctly configured reverse proxy added as a safeguard to this issue? It doesn't see that is true, correct?

A "correctly setup" reverse proxy shouldn't have passed along the proxy header the attacker used to claim they were on a local address to the Emby server.  

I'm not aware of any web scan tool that tests for that vulnerability though.  

For Nginx which is what I use, the "proxy_set_header X-Real-IP" header setting (not the full command, look up how to setup a reverse proxy elsewhere) will pass along the remote IP to Emby.  Without that, Emby will see every remote connection as coming from the local IP address of your reverse proxy.  I am assuming that header command will override the attacker's fraudulent header info they used and would have kept the Emby server safe from this attack.  

You also need to be sure that the reverse proxy is the only way to access your Emby server from the web.  If you had a port forward directly to Emby in addition to the reverse proxy the attacker could have gotten in that way.  

10 hours ago, KMBanana said:

A "correctly setup" reverse proxy shouldn't have passed along the proxy header the attacker used to claim they were on a local address to the Emby server.  

I'm not aware of any web scan tool that tests for that vulnerability though.  

For Nginx which is what I use, the "proxy_set_header X-Real-IP" header setting (not the full command, look up how to setup a reverse proxy elsewhere) will pass along the remote IP to Emby.  Without that, Emby will see every remote connection as coming from the local IP address of your reverse proxy.  I am assuming that header command will override the attacker's fraudulent header info they used and would have kept the Emby server safe from this attack.  

You also need to be sure that the reverse proxy is the only way to access your Emby server from the web.  If you had a port forward directly to Emby in addition to the reverse proxy the attacker could have gotten in that way.  

Exactly - you will note that on compromised systems, the IP logged was 127.0.0.1 - ie localhost.   NGINX as a REVERSE PROXY (and any other reverse proxy ) will by design drop the HTTP connection and re-create their own to the backend server.  That is the key advantage of them - the proxy creates the connection, not the original client.    A transparent proxy WILL forward contents without modifying as an example of what we don't want...

So yes, we do actually want the remote IP details, but we don't want it from the header, we want it from the IP layer connection - and this is what X-Real-IP does.  This then gets added by NGINX to it's newly created header as the X-Real-IP - otherwise we would just get the reverse proxy source IP address as you say.

Edited June 12, 2023 by rbjtech

Our Report on the Incident is Available Now: 

 

Welll..... Google is telling my site is dangerous again when I try to visit my emby server domain. Last time that happened - This happened... So do we have another security vulnerability we should be aware of?

1 hour ago, pr3dict said:

Welll..... Google is telling my site is dangerous again when I try to visit my emby server domain. Last time that happened - This happened... So do we have another security vulnerability we should be aware of?

Hi, we'll respond in your topic. Thanks.