Emby Blog

3 hours ago, ebr said:

Many people use the same credentials on multiple sites.  The supposition would be that the Emby credentials might be duplicated elsewhere where there would be more value to them.

 

And which sites would those be? Or, is the expectation that the hackers will just randomly try my user/password combo on every site on the Internet? I don't have an email address tied to my accounts, so even trying the option of requesting a PW reset to try and at least know if I have an account on any site on the Internet is simply incomprehensible.

If your Emby Server instance was compromised and the application was also running in an elevated security context and you also happened to use the device hosting that instance to do other things, for example online shopping, banking, etc. then anything touched while the system was compromised should be considered at risk. They could have captured screen output, intercepted keyboard/mouse input, etc.

9 hours ago, One2Go said:

I get it where you are coming from. I was a total knewby when it came to Linux, but because I run QNAPs I had to bite the bullet and get a minimum education on how to deal with Linux. That included installing Putty, learning how to work in a command prompt window, plus get to know a few commands. Minimum is cd (Change directory), ls (List Directory), rm (Remove Files), vi (Visual Editor to modify files like the hosts one). All this is available with Google searches and the forum for you Linux device.

Didn't want to do this but since I run media servers on UnRaid and QNAP NAS devices it was a must. This is part and parcel of being in the digital world and it will not go away.

Now to your problem Synology is no different then my QNAP and if you follow the "Action to Take" instructions from the Alert you will be fine since it corrected my problem.
1. Install Putty (Windows device)
2. Navigate to the Plugin Directory (remember the directory ,qpkg may not show up, but if you type .q and then hit the TAB key it will auto complete the entry)
3. delete the DLLs
4. Edit the hosts file
5. Delete the two files in the plugin configuration directory.

Before you start stop the Emby server from your Synology App section where you manually installed it. REMEMBER in Linux all names are case sensitive. Emby is different then emby and will not be recognized as the same.

All the best to get back to normal as it sucks to have ones routines interrupted.

the full path to the plugin directory is
/share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata/plugins/

I have SSH enabled on my NAS. I downloaded Putty. I can access NAS but when i use ls it doesn't get me volume1 which i know is where emby is so i cant access the files i need to delete. I checked and i have permissions turned on for that directory but can't get there. 

36 minutes ago, ember1205 said:

And which sites would those be? Or, is the expectation that the hackers will just randomly try my user/password combo on every site on the Internet? I don't have an email address tied to my accounts, so even trying the option of requesting a PW reset to try and at least know if I have an account on any site on the Internet is simply incomprehensible.

Your credentials will be distributed amongst many hackers and Ne'er-do-wells, who through bots will try your credentials on many thousands of sites, the frequency of which depending on the potential value they can extract from said site.  

8 minutes ago, hotwheels26180 said:

I have SSH enabled on my NAS. I downloaded Putty. I can access NAS but when i use ls it doesn't get me volume1 which i know is where emby is so i cant access the files i need to delete. I checked and i have permissions turned on for that directory but can't get there. 

There's a Synology sub-forum with multiple threads discussing how to complete the action plan from the Security Advisory. The guidance you need should be in those threads.

https://emby.media/community/index.php?/forum/153-synology/

 

55 minutes ago, ember1205 said:

And which sites would those be? Or, is the expectation that the hackers will just randomly try my user/password combo on every site on the Internet? I don't have an email address tied to my accounts, so even trying the option of requesting a PW reset to try and at least know if I have an account on any site on the Internet is simply incomprehensible.

That's pretty much on-point.

That theory about passwords being used elsewhere is nonsense. Like @ember1205said: when there's no e-mail address associated, then there's no point in trying those credentials elsewhere.

The way how they are forwarding those credentials tells more: This is including all other login details like device id, device name, internal and external IP addresses etc.

That's all information that is needed to gain access to the same  server again at a later time, also for example after the vulnerability has been fixed and the original way doesn't work anymore, or security has been tightened, passwords changed, etc. 

It's their re-entry ticket to the server. 

(but maybe they are trying whether these are identical with OS credentials, that's realistic)

Edited May 27, 2023 by softworkz

13 minutes ago, softworkz said:

That's pretty much on-point.

That theory about passwords being used elsewhere is nonsense. Like @ember1205said: when there's no e-mail address associated, then there's no point in trying those credentials elsewhere.

The way how they are forwarding those credentials tells more: This is including all other login details like device id, device name, internal and external IP addresses etc.

That's all information that is needed to gain access to the same  server again at a later time, also for example after the vulnerability has been fixed and the original way doesn't work anymore, or security has been tightened, passwords changed, etc. 

It's their re-entry ticket to the server. 

(but maybe they are trying whether these are identical with OS credentials, that's realistic)

Passwords being used elsewhere is not nonsense.  

They will try these credentials on sites which accept usernames OR emails

Bots are going to try these credentials adding @gmail, @yahoo, @aol. 

Bots are going to try to fuzzily match these credentials to known email addresses, for example trying the leaked credentials of userXYZ to accounts associated with the email userXYZ99@gmail.com 

My server hasn't been compromised but I'm stuck running 4.6.7.0. I can't update to 4.7.12.0 because of hardware transcoding issues.

All my accounts requires a password on LAN authentication. Would my server stays at risk if I stay on 4.6.7.0 if it's still being exposed to the internet behind a reverse proxy?

 

Thanks!

@Touz604on versions before 4.7.12.0 you will need to make absolutely certain that your configuration is not allowing the X-Forwarded-For exploit from Internet traffic as described here.

A reverse proxy should protect you if properly configured, but if the exploit is executed successfully then all of the rules you have configured for local accounts will apply to the remote connection. Accounts hidden remote won't be hidden, accounts without remote access will be available remotely, accounts without a password on local networks won't require a password remotely.

If your Emby Server process is running in an administrative user context on the device hosting it the exploit can be leveraged to compromise the entire system.

11 hours ago, ember1205 said:

When vulnerabilities are divulged, details about the items that are/were at risk are disclosed with them. NONE of the actual risks have been provided. The only statement that has been made is "Analysis of the plug-in has revealed that it is forwarding the private Emby Server login credentials including the password for every successful login to an external server under control of the hackers." 

 

Why was Scripter-X / ScripterX not mentioned as the actual custom plugin that they loaded to create the backdoor? Why was 5/11/2023, approximately noon EDT / 9AM PDT not mentioned as when the hack initially occurred? If not data was "stolen" (aside from login credentials), why was there so much data leaving my network from my Emby server? Why was the vast majority of that data being sent to GitHub, Princeton University, and AWS? What would the so-called botnet possibly want with server login credentials outside of looking to pull content off of the servers?

 

After significant analysis and research Emby determined that this was a critical vulnerability that required shutting down my server but they don't know what data is/was actually at risk? If there's no understanding of what data is being pulled off of the machines, how was it determined that this was so critical? There's a LOT more to this story that isn't being shared with the community. And for those like myself that have invested into the community with extensive amount of time and have purchased the Premiere license, being treated this way is disgraceful.

While I do agree that the specifics of the attack chain could have been made more clear, I don't agree with you that this is typical of the industry in vulnerability disclosures.  As the level of infiltration in this attack did require a multi-chain process involving first exploiting Emby and then leveraging the scripting plugin to escalate privileges and potentially carry out more damaging attacks, the level of disclosure here, and the steps taken to taken to actually shut down the offending service are some of the most high-handed tactics I've ever seen.  The fact that the actual vulnerability was reported and ignored for over three years is both embarrassing and quite upsetting; but the response since the team realized it was being exploited in the wild has actually been okay.

Emby is never going to know the extent of the damage caused by this particular attack.  But I have been trying to get across in my previous responses that this is the worst type of vulnerability that can exist.  I haven't looked up the CVE they reported for this, but this should be reported as a 9.9 or 10.0.  This is the WORST thing that can happen.  It is a full RCE that can be scanned for and is likely being scanned for on the internet.  The entire attack chain can be automated at this point.  Meaning someone can run a program without interacting with it that can detect a vulnerable Emby instance, and then run commands in succession to gain control of your system and automatically add it to an ever growing botnet of systems fully under control of one user.

Again, EVERYTHING is at risk here.  Emby will never have the full scope of impacted assets.  And, even if they do, they aren't going to share it because it doesn't serve any purpose.  If your server was impacted, reset every password that the system had access to and rebuild the system where it was installed.  That is the only way you can be mostly confident that you have addressed this.

14 minutes ago, moviefan said:

I haven't looked up the CVE they reported for this, but this should be reported as a 9.9 or 10.0. 

It's reported at  9.1. I suspect that the scope of Unchanged is the mitigating factor. It may be challenged since the exploit can be leveraged to compromise the underlying system, but if that requires that the process be run as an administrator to achieve rather than privilege escalation on the underlying system being achieved via Emby Server running in a non-privileged security context for the process then 9.1 may be correct.

26 minutes ago, andrewds said:

47 minutes ago, moviefan said:

I haven't looked up the CVE they reported for this, but this should be reported as a 9.9 or 10.0. 

It's reported at  9.1. I suspect that the scope of Unchanged is the mitigating factor. It may be challenged since the exploit can be leveraged to compromise the underlying system, but if that requires that the process be run as an administrator to achieve rather than privilege escalation on the underlying system being achieved via Emby Server running in a non-privileged security context for the process then 9.1 may be correct.

I didn't pick a number by taste. I just followed the instructions here: https://www.first.org/cvss/v3.1/user-guide - Section 5
When somebody thinks I made a mistake, please create an issue in this repo: https://github.com/EmbySupport/security/issues and explain.

Thanks

1 minute ago, softworkz said:

I didn't pick a number by taste. I just followed the instructions here: https://www.first.org/cvss/v3.1/user-guide - Section 5
When somebody thinks I made a mistake, please create an issue in this repo: https://github.com/EmbySupport/security/issues and explain.

Thanks

Oh yes, I am not suggesting you picked a number yourself. I'm familiar with the reporting process. I just mean that it may change as the investigation process continues, but possibly 9.1 will be the final score.

GENERAL NOTE - PLEASE READ

Guys, I know that there are a lot of things still unexplained. 

This has been an incredibly tough effort for all of us, I had no sleep for days until Thursday and still pretty damaged.
I'll try to answer all questions over the next days, the responses need to prioritized in a way that we are helping affected users first to get going again. But there are answers to all questions you have, and some might be surprising and might make things that some are criticizing appear in a different light.

Thanks for your understanding.

14 hours ago, hotwheels26180 said:

I've never had that happen. Like I said if an update fixes it I'm fine with that. So far it hasn't and I have to change system files on my own to fix it. If you are referring to shutting down and restarting to install update, that's fine. This is not the same. My Emby is shut down and will not restart even with an update.

The Emby update prevents this happening again; it does not fix your system - that requires your manual intervention.  If your Emby still doesn't restart, then check the action list through again.

Paul

Edited May 27, 2023 by pwhodges

Unfortunately my original advisory text has been softened as it would have scared people. I said it MUST scare people because it's a serious and scary situation that needs to be understood in full length:

In case Emby Server has been shutdown the system is COMPROMISED! 

What's most important in this situation is to understand what it means and which consequences it has and which steps are required.
Getting Emby Server to start again is the very last and least problem in that case.

Unfortunately it now appears as if we would just want to bother people by letting them go through a complicated procedure for starting Emby again while the really important steps appear just like an optional bonus task that may be omitted and can be overread like the typical security bla bla in those instruction manuals for kitchen gadgets.

So once again clearly:

When your system is COMPROMISED, your task is not about getting Emby starting again

You have a lot of big things to do and consider. Restarting Emby is just a tiny little bit at the very end, and only when you decide not to re-install the system.

Edited May 27, 2023 by softworkz

7 hours ago, softworkz said:

I didn't pick a number by taste. I just followed the instructions here: https://www.first.org/cvss/v3.1/user-guide - Section 5
When somebody thinks I made a mistake, please create an issue in this repo: https://github.com/EmbySupport/security/issues and explain.

Thanks

I just went through the calculator and I got a 10.0:

7 minutes ago, moviefan said:

I just went through the calculator and I got a 10.0:

 

Scope

 

The vulnerable component is Emby Server. The malware runs inside the process of Emby Server with the same privileges as Emby Server - so: Unchanged

 

Availability

 

I don't see any impact on the availability of a resource. Can you explain?

 

Yah I noticed these were the two differences here.

The vulnerable component runs inside of Emby server but the exploit chain allows for full compromise of the system Emby server is running within.  In addition to this expanded scope, full compromise of the server implicates the ability of an adversary to harvest any other credentials on that system and we have seen users on these forums discussing other unrelated accounts being compromised as a result of this hack.  I absolutely believe the scope should be considered changed and this alone makes the score a 10.0.

In regards to availability, once the system is compromised an attacker could very easily infect the host with ransomware and disrupt complete availability of not only Emby server, but everything else running on the system.  This is just one example.  But availability could certainly be impacted here.  And honestly it doesn't even matter.  As soon as the scope is set to changed, this is a 10.0.

5 minutes ago, moviefan said:

but the exploit chain allows for full compromise of the system Emby server is running within. 

How does that go?

Just now, softworkz said:

How does that go?

1) Attacker uses x-forwarded-for header to gain Emby Admin privileges

2) Attacker installs scripting plugin

3) Attacker configures scripting plugin to download hacking toolkit (e.g. Cobalt Strike) and runs it

That's one basic example.

31 minutes ago, moviefan said:

Attacker configures scripting plugin to download hacking toolkit (e.g. Cobalt Strike) and runs it

When a secondary toolkit uses any other exploits to achieve elevation from the security context of the Emby process, then this elevation cannot be accounted for the Emby vulnerability. Such things account to those exploits only which actually allow the elevation. Also, the success of those secondary exploits depends on different conditions and prerequisites. You can't just sum this up.

Edited May 27, 2023 by softworkz

1 minute ago, softworkz said:

When a secondary toolkit uses any other exploits to achieve elevation from the security context of the Emby process, then this elevation cannot be accounted for the Emby vulnerability. Such things account to those exploits only which actually allow the elevation. Also, the success of those secondary exploits depends on different conditions and prerequisites. You can't just sum this up.

I wholeheartedly disagree with this characterization.  The only prerequisite required for this attack chain to be successful is the Emby process running under an account with admin level privileges on the system.  I provided an example of a hacking toolkit, but the way ScripterX works allows for ANYTHING to happen on the system.   It simply takes a command and runs it under the context of the Emby user.  The ability to run a hacking toolkit is simply one example of how this exploit chain allows for an attacker to gain complete control of the system.  There are infinite other mechanisms that can be done with a scripting plugin that runs any command.  And ALL OF THIS can be fully automated.

You're welcome to characterize the CVSS score however you want.  But I think you are being disingenuous by marking this down anything below a 10.0 given the implications of the attack chain.

I don't care which number will stand there at the end. I just want it to be done properly. 

There's probably no point when the two of us are discussing that. When we can find an expert in these things, I'll gladly adjust that to whatever he will determine.

Thanks for far.

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.