Leaderboard

General We at Emby believe in privacy, and as such we don't have any telemetry in place, we do no datamining, we do not store and correlate any connection data, user information and server ids - which means that we have no way to identify and know anything about the owner of a specific server. In an emergency situation like the recent BotNet takedown, it can happen that it is needed to weigh out one good against another and we can only assume what the majority of users would prefer (being hacked or vulnerable to be hacked without knowing or us taking action). In this case - for taking action - it was crucial to get reliable data and information for proper assessment. We don't know about your servers and we don't have any way to access them. But we had to find a way to get information from your servers in some way in order to assess the situation and possibly take appropriate actions and eventually, we used some auto-updating capabilities built into Emby Server, and so it was your server who initiated the connection to report back the information we needed. Conditions The local detection that we ran, performed a categorization into the following thee cases: Systems that got hacked Systems that are in danger of getting hacked Systems that are not vulnerable We have decided to report back only in cases 1 and 2. In case 3, no action was taken and no report was sent back to us. Collected Data Here's an example of the data that got reported: { "Id": "b649349bacf411a9a945eaa7aa675146", "Version": "4.7.11.0", "OperatingSystemDisplayName": "Win32NT", "OperatingSystem": "Windows", "SystemUpdateLevel": "Release", "Plugins": [{ "Name": "EmbyHelper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "Version": { "Major": 1, "Minor": 0, "Build": 0, "Revision": 0, "MajorRevision": 0, "MinorRevision": 0 }, "AssemblyFilePath": "file:///C:/Users/user/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll", "Routes": ["/EmbyHelper/Ping", "/EmbyHelper/RunCommand", "/EmbyHelper/RS", "/EmbyHelper/Keys", "/EmbyHelper/CleanLogs", "/EmbyHelper/DropLogs", "/EmbyHelper/File/List", "/EmbyHelper/File/Read", "/EmbyHelper/File/Write", "/EmbyHelper/File/Delete", "/EmbyHelper/Version"], "FoundByName": false, "FoundById": false, "FoundByRoute": true, "FoundByApi": false, "Alert": true } ], "Alert": true, "UserSecurity": { "AdminsNoPasswordLocal": 1, "AdminsEmptyPassword": 0, "UsersNoPasswordLocal": 0, "UsersEmptyPassword": 0 }, "Artifacts": { "Alert": true, "FoundInScripterConfig": false, "ScripterConfigLines": [], "FoundInFileSystem": true, "FilePaths": ["C:\\Users\\user\\AppData\\Roaming\\Emby-Server\\programdata\\plugins\\EmbyHelper.dll"] } } FAQ As there have been user questions about this, I want to clarify the following: At no point in time did we access any user's Emby server from outside We don't know your server, we don't know how to access them and we have no means to access them The data we collected (see above) does not include any personal information No user names No e-mail addresses No host names No IP addresses No Emby Premiere keys We did not log the IP addresses from which the reports came from The data exists in form of log entries in a cloud project only It won't be further processed or imported into a database The whole project will be dropped in a while and all data will be deleted

Thanks softy!! And appreciate the openness of this. I’ve always known Emby has never collected any user data or stats, right from day dot of VB and MB. I’m on board with this and think its a very responsible action to take. so thanks emby team

A suggestion. Would it be more efficient for people needing help to start or post to a thread in the sub-forums for their OS/platform? Perhaps creating threads with the subject/title "Security Advisory Help: <OS/platform>" in those sub-forums could bring help from others familiar with those systems. It's getting a bit crowded in here with multiple reports and requests for help across the wide variety of Emby installations. Hard to keep track and contribute.

Hi. That is not our intent. As you can see there is a huge red banner on this site plus we submitted a CVE report ourselves. We went to considerable effort to identify and mitigate affected systems and that was our focus as opposed to a blast email to everyone but there is also an issue with that as we don't have the email address of most Emby server owners (because most run for free). So we were in a situation where, if we sent some sort of blanket email, we would be inundated trying to address all the people that are not actually affected which would take away from our ability to help those that actually were. So we chose a much more targeted and direct approach to try and protect people as quickly and thoroughly as possible. Thanks

Massive props to @FrostByte, everything is working. Again, if I have not said it before, thank you for all of your patients and help.

There's a CVE now: CVE-2023-33193 Advisory: https://github.com/EmbySupport/security/security/advisories/GHSA-fffj-6fr6-3fgf

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.

People do not usually enter the forum, most people doesn't even know it exists. Full disclosure to everyone possible is always the best approach, because there are people affected that might not realize they are affected. Yes, I get that you don't have the email of everyone that ever downloaded Emby, but doing a reasonable attempt to inform registered customers is the lowest bar possible and you have not cleared it. And yes, you will be innundated, thats on you because you had three years to patch this. You did not take down a botnet, you took down the part of the botnet that you had access to, but there's probably lots of compromised systems out there that have no idea what's going on. If you are trying to argue that informing less people of your security issues is better than more people, then I think your approach to security is severely out of date.

Starting thread for assistance with the Security Advisory 2023-05-25. https://emby.media/support/articles/advisory-23-05.html Post here for questions and help with the Linux platform.

I'm going to put these changes into the next beta build.

the beta was fixed in version 4.8.0.31, so yes you are far behind and should upgrade to the latest 4.8.0.37 You cannot go from beta 4.8.x to stable 4.7.0.12 due to major database changes. You would need to start from scratch if you wanted to move to stable at this point.

Yeah, I mean, the whole "How we took down a BotNet" is more like "How we actually helped create a BotNet and had to scramble to fix our own mistakes because of a huge vulnerability that was exploited on our paid software". I am running Emby on docker, did not find any of those two files, passwords were deactivated on the local network BUT all the users had passwords. Will be changing passwords anyway just in case anyway. Oh, also, might have something to do that I'm using a reverse proxy (npm) to access Emby. EDIT 2 because I don't mean to spam: How is it possible that an e-mail has not been sent to all registered users and everyone on the emby db either community, paid user, etc. I found out only because I was about to update my server and wanted to see what were the new features. Everyone should be notified ASAP.

So just a quick update - looks like ddns was not updating - so we fixed that and port is now 100% open (wasn't before). OP is testing .. but I'm getting a 'Forbidden' on the splash screen/curl - so possibly related to connection https enforcement (needs to be disabled or preferred) .. will report back after the OP testing.

The fact this was reported years ago and wasn't resolved before it became a big problem, they deserve some egg on their face for that. The rest of this is really just a lot of hair splitting, salivating and hand wringing over the potential for a public apology/shaming from people who haven't had their favorite feature request implemented yet. Notifying the effected servers through their logs and putting them in a position where their server is safe but they have to seek out more information was a fine response to a situation with no good answer.

Again, many many THANKS! You and your team and everyone here are the BEST. Thanks so much for taking the time to help me and many others. I owe you many many beers. Cheers!

The problem is that you informed no one. Posting a banner on the web site of the forums is not notification any more than my stapling my resume to a utility pole would count as notifying every local business that I am looking for work.

I see a lot of deflecting, a lot of explanation, and a lot of justification. What I don't see is any sort of acknowledgement that anything is being done to improve the process. Combine that with the "marketing spin" being put on this and leaves a VERY bad taste in the mouths of users. As has been mentioned, Emby did not "take down a botnet", it took down a specific number of servers around the world that were participating in a botnet. It is also massively misleading to claim that it was taken down "in 60 seconds" - while that may have been how long it took to post the plugin update and begin the process of pushing it out, it took TWO WEEKS from the initial hack, and more than three years since the vulnerability was exposed, before anything was "done." Further, how many servers around the world are still running affected code and have been compromised? To think that there are a whopping 1200 servers GLOBALLY that were impacted by this is not at all reasonable. I came to Emby because the front-end functionality was significantly more reliable than that of Plex. Due to Emby being insanely slow to implement very basic, repeatedly asked for features on the back end, I have continued to run my entire Plex setup solely for the purpose of the DVR functions. It looks like I will be needing to entirely rethink my entire setup once again because this overall response it not at all well-seasoned for a commercial entity.

I appreciate the quick fix (if it really wasn't a 3 year old exploit that you all have known about). However, a simple email to all addresses that you did have would have been the right course of action. A simple, we are aware and are working to fix this and if you have questions here's a link to the forum post where our staff can best answer your questions would have been great. It does make people antsy and I guess that's where everyone is going with this. You can't please everyone and you all made a decision that you thought was in everyone's best interests. Right or wrong you stand by it, learn from it and move on. More communication with your customer base is never a bad thing. You have a great product... broadcast that when everything is going great and broacast it as well when things are broken. People value transparency more than anything.

I didn't even realize all this was going on until 4.7.12 popped up on my dashboard, kinda surprised me since I wasn't expecting another update until 4.8 releases so I came on here and found quite the snafu. Glad that it seems like I wouldn't have been a target in this one. Always feels like you can do more to secure your setup and every so often with an intrusion like this you get that warm, fuzzy feeling that you're actually doing a decent job lol. I know the Emby team isn't very large. People think once you ask for money, you must have all the resources and manpower in the world with an expectation that get things handled perfectly... when in this case at least, it's more likely a few individuals working around the clock assessing a serious situation. At the end of the day it sounds like the team did their best to resolve the issue and protect users systems quickly, and they've been upfront here on the forums with what they did and why. I appreciate that. Good job guys.

I think it's a fair question if you run the Release version - because no server updates were made prior to the action - only Plugin updates from 18/05 on my system. Beta had lot of main updates around this time - but this was actually for the fixes. So if the main Release was not updated until .12 - then the only 'update' must have been via a Plugin... ? and I believe that is what CBers is asking ... edit - doh - yes, softworkz has confirmed.

Yes it was. I think there's no point in keeping it a secret because it's clear enough by now and it's the first and last time that we could use this method.

Thank you so much @softworkzand team! It's such a relief to see you and others at Emby not only protecting our privacy, but also protecting the security of our personal servers. I'm so glad Emby has mechanisms in place to combat these attacks AND act quickly to prevent further damage. Thank you!!!

No. Jellyfin is not currently vulnerable to this particular issue. It was fixed in our 10.7.0 release in March 2021. Also no. The Emby team has never communicated any known security issues to us.

I would add that with all the "cyber-issues" out there in the world, the Emby team did a great job getting the word out on this, and fixing it quick. It's easy to get "upset" about this kind of stuff, but don't forget that software is complicated, and all we can do is react to new threats as they happen. They did that. Just practice good security measures, and keep on truckin'... I woke up to a notification that an update was available, and done... Thanks guys!

Given the latest events, isn't it about time the development team took this a little more seriously and stopped kicking it down the road? All internet facing systems in 2023 should have the option for MFA.

Just want to point out here that regardless of whether you allow direct external access, there are still multiple vectors that an adversary can use to infiltrate your network remotely by tunneling back over your outbound connections. These include such vectors as phishing emails, malicious websites with o-day exploits, and updates to your installed software which contain malicious code embedded in the supply chain of the application developers. I don't disagree with your point about security being a user choice. But your certainty of security by not having open public ports is a bit naive.

External user has confirmed on two devices that it is working. Thank you rbjtech for your help!!! Who knew it would have been DDNS not updating, but at least it was something simple. My server is setup to "preferred, but not required" for secured connection. Is there an inherent benefit to use https vs http in my setup? All users I provide the fqdn directly.

I haven't been effected by this and like to think I have a reasonable level of security for an internet-facing system, but this is a pretty damaging situation for emby. I think the red banner needs to be reworded as the word 'potential' is somewhat disingenuous given it has been exploited on some system. It is a vulnerability, not a potential one

I for one am appreciative of how quickly you acted regarding this hack. I run Emby in docker (on Unraid) and it doesn't appear anything has been compromised and I didn't see any unusual activity in Emby but as your blog suggested I changed everyone's passwords as a precaution. Thank you for being diligent.

apparently not! BUT instead of asking rhetorical questions you may want to apologize for your failures and help me fix your mistakes instead of acting like I'm the A-hole here.

Advisory: https://emby.media/support/articles/advisory-23-05.html A Full Report on the Incident is Available Now:

They knew that potentially all of it was at risk; but they have found no evidence of any data actually being taken than they have already described, in the systems they have access to analyse. In general, how far the danger extends depends on the user's setup. The vulnerability itself enables external access to be made to appear local, but this has no significant effect unless there are users who could log in without password on the local system - this still only gives access to looking at movies and so on unless there is an admin user which can be logged in locally without password, when it becomes possible for the hacker to install a plugin that happens to be able to download other code - but even this is still restricted to the Emby system itself, unless the Emby server is being run under an OS admin account, at which point the whole machine becomes vulnerable. So no - they can't know just how much at risk your system was - that's for you to determine, as you know about those settings which Emby doesn't. Paul

Hi. That's the only thing we're sure of but there is really no way to know what else may have been done. We haven't positively identified anything else at this point. We have no evidence that anything outside of Emby credentials were taken/compromised. 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.

That's a nice idea, but then we have people like myself who run Emby (and many other apps) in Docker, which causes other issues. The lack of information about the DLL file that was injected was also frustrating my work, because due to Docker, I had no way to bring up the server without network access. While I appreciate the work that they did to shut down the botnet, the 'full story to come' with next to no 'partial story to start with' is incredibly frustrating. It gave me no useful information to help understand what kind of threat my server was under. A few other things I'm now also noting: The infection for me (and others I've seen here) started on May 11th, 2023, using an exploit first laid out on February 2nd, 2020. Not only is there the question of why an exploit allowing for high level penetration was allowed to languish until after it was actually weaponized, but I remember that same day I got a ton of issues with other sites. My Emby does have a FQDN for outside home-access. The day the attack happened all of my other subdomains suddenly got 'malicious attack' warnings from Google and Firefox, and a YouTube video that had a link on one of the other subdomains got a community strike for 'scam activity'. I appealed the community strike because, based on the lack of any other information, I saw nothing suggesting it wasn't anything more than a technical hiccup. Maybe an IP change at Cloudflare, or a momentary cert error with LetsEncrypt, or something. I asked YouTube for more information, and while the strike was removed, I never got any technical feedback. This is an issue with the larger Internet, where small time domain holders may not have the resources to find out when they're threatened.

Just my personal opinion. This whole episode of server compromising was a cluster f*ck that no one wanted and desired it. At this point the Devs don't need more should have could have. For me since I have been using their content organization solution since MediaBrowser, they earned a OK, we screwed up. I consider this as them just paying a boatload of tuition at the school of hard knocks. Note to self, dial down the rhetoric and up the helpful suggestions.

Closing loop - backup data, reset Asustor NAS, reinstalled with 4.7.12 package. Emby is back. Still rebuilding and re-configuring.

Just as an addendum, a properly configured reverse proxy should do this, but it's entirely possible to have a poorly configured one. Without adding those headers its possible Emby would see every remote connection as coming from the local address of the reverse proxy itself.

I can partially agree here, but will also say that the staff of Emby needed to fully understand what this compromise represented before they took action like was done. In other words... The process that was used to deem this "critical enough" to shut down everyone's system would ALSO have afforded a lot more detail that can now be shared with users.

Let's take it over here and I can try to help you.

On a Linux system (I am supposing that's what you have), you are not the only user... there are a lot of them. One of them in particular is "emby" and will own all of the content. Your user account won't have write permission to most of the files. Use PuTTY or similar to access the machine via SSH (which is what WinSCP is using). Once logged in, you will need to change users to the root user or similar. THEN navigate the filesystem... Which underlying OS you are running will dictate exactly how you become the superuser. My guess would be that you're running Ubuntu and the process to directly become the superuser is to execute the command "sudo su". Be Careful. This user can literally do whatever they want, including completely crash the system.

I don't know what you think could have been done differently? I'm not trying to fight with you, I just think these cyber-threats have a lot of moving parts, and they took the needed steps to stop it. I updated the two servers I have running, and it took less than five minutes. Keep in mind, the moment the team starts sending notifications and posting on the forums about the steps they are taking, they are also telling those conducting the attack what they plan to do. In this case, they shut it down, then dealt with getting people updated. Seems reasonable is what I'm saying. If you were affected, they shut your system down before any more damage could be done, like deleting your media... I'm good with that.

There is nothing in the changelog attached to: https://github.com/MediaBrowser/Emby.Releases/releases/tag/4.7.12.0 to signify this is a critical security release. I would suggest that as a matter of standard practice any security fixes be tagged as such so that the community and upstream who follow only Github for releases are aware.

Synology Users: You can use WinSCP to check if the malicious files are present. I looked on mine and they were not. Hope anyone affected is able to clean things up and get back to normal again.

I just wanted to share what our firewall had caught since the 11th (when this all began) from what I can tell. I'm guessing they published at least my server info somewhere as I have since been getting multiple attempts to find more ways in. shown in the attached log. These are attempts and blocked, I do not know what may have gotten through. if anyone might see these or like addresses and attacks may be able to narrow down the source and targets 2008R210Today.txt

Yes, I was using local passwords.

I agree. I appreciate that people are responding to help us all, but many of us are complete novices and receiving small bits and pieces on how to do something is only leading to more and more frustration. I have been working at this on my own for hours and have not been able to successfully resolve anything.

Can you update us on your status? To be honest, I doubt any Emby dev or team member has given Jellyfin a thought as we work with the original and modern Emby server version. It's got about 4+ years of different code added to the version of Emby they started with. That makes for plenty enough changes or differences that we really have no idea. You would really want to ask the Jellyfin peeps about their vulnerabilities.

This is what helped me, a Linux newby to get to the directory from where to delete the DLLs and also where to delete the two other files in the configuration directory. First off you have to stop Emby server and then use Putty to do the navigation. Never used so many times the cd (Chang Directory) command plus the ls (List) command to find what I want. Finally the rm (Remove) command to delete files. Follow the navigation by PenkethBoy Finally the editing of the hosts file. In the Putty window type vi /etc/hosts that starts the editor now press the i button and enter this line after the last entry: 127.0.0.1 emmm.spxaebjhxtmddsri.xyz Press the ESC button and type a colon followed by wq and hit enter. Watch the YouTube video on how to edit the hosts file and save it. https://www.google.com/search?client=firefox-b-1-d&q=editing+a+host+file+in+qnap#fpstate=ive&vld=cid:23ebf603,vid:Kl6Kwvc-EYs,st:47 After finishing start the Emby server and it should work. I had no problem following the instructions here and get the server back running

Please apologize. I've been working more than two days non-stop on that matter, and I guess it's time for a rest.