Leaderboard

Does this mean that not only myself, but the developers will no longer have to read this rambling of nonsense and respond to the tantrum being exhibited for all to see. If my server is shut down, the world does not stop spinning. This is a "personal" server for the use of family and (pushing it a bit) friends. If you are getting complaints from your "users" that have probably paid the fees you impose, then you are probably doing something wrong. While I was not affected, I did see the warnings that popped up on my server dashboard. Good job guys. It got me to dig a little deeper to determine what was going on. Seems like that is the role of a good administrator. I agree with comments above that what I purchased when I bought a Lifetime license is that I bought a "Right to Use". I don't own anything except that right. I have yet to purchase any software that ownership of anything more than the media (disks) it was provide on was transferred to me. Considering the fact that I purchased my "lifetime" license in 2016, there was a clause in the agreement that stated the "lifetime" was until such time that a significant change to the software was introduced. In 7 years, I have seen a very significant change to the software and yet my "lifetime" license is still valid. Developers were damned if they do, damned if they don't. I would much rather have a developer, knowing there is a potential "hack" of my system, shut it down. As opposed to receiving an e-mail that may go unseen for a period of time. Even if I don't log into the server for days at a time, I am sure one of my family members would give me a call to let me know I have an issue. I personally would like to send a "GREAT JOB" to those involved in resolving this issue. Not everyone will be happy, but there is one Administrator out there that is extremely happy with the response and my right/privilege license to use" Emby. KEEP UP THE GREAT WORK!!! P.S. After posting this, I pulled up my e-mail receipt from the day I bought my license. I'm am so glad they did what they did as opposed to doing nothing but send an e-mail. Imagine my surprise when I saw this: No warranty of suitability, functionality or support of any kind is offered in relation to this transaction. We hope you find the software useful and worth what you provided for it.

If your issue is with the lack of reaction to the initial vulnerability, that is justified, and Emby have, we hope, learnt their lesson. But if your issue is with the steps they took to prevent this becoming a much, much bigger problem within days or even hours, then you are wrong. I hope they will soon publish their reasoning behind what they did (which I have seen), and then maybe you'll understand where they were coming from. You may still disagree, but they had a justified belief that doing it any other way than what they did would have had worse and more widespread consequences. Paul

It's a bit funny how people are complaining about Emby trying to find a Solution to this situation, and they needed to decide quick this is nothing they had time to plan it over weeks. And now people are complaining about turning off their servers and write a info in the emby server log, because they are not able to notify everyone per mail because free users don't need to provide any contact informations. Think about it had to happen fast, and this is the way they decided to do it. From my perspective as an IT Guy, i know you need to do things really quick sometimes and normally if the emby server is not starting up anymore, i look at the emby logs, server logs or go to their support site, so this is where people will find the information. But as i know there are so many people with that less tech knowledge we even could be happy they are able to turn on their computers every day, they now start to complain about it. I would like to see your posts if all your files has been gone because the emby devs wouldn't have done anything and all your files got deleted. I am pretty sure, if this would happen, it would be more than enough for you to prevent it by stopping your server from starting up. So think about you haven't lost any data and now life goes on instead of you have 0 movies, shows and music at all because they just don't react because "IT IS YOUR SERVER AND THEY HAVE NO RIGHT TO DECIDE WHAT HAPPENS TO YOUR STUFF" I really would see what you guys would have done in this situation and if the first users start to flood your forum because all files are gone Then they can give you the answer you wanna hear from them now: It is your server, we are not responsive for your files and the security on your server.

I understand your position. I can assure you that the decision hasn't been made light-heartedly. It had been clear to us that this kind of intervention will be seen controversial, but there were reasons for why we chose to go that far and shutdown infected servers as the ultimate last resort. I wrote an article which is detailing the decision process, I hope it will be published soon.

Open DSM as usual in a web browser. Once logged in Open Control Panel. Click on the Users & Groups menu on the left. Most likely the admin account will be deactivated. We are going to activate it for our use as well as change the password (if we do not remember it). Click on the admin username to highlight it, then click the edit tab. Click the box above next to "Deactivate this account" if needed so there is not a checkbox. If you do not remember the admin password, click the Change Password button above to get this: Type a secured password in both places and click the Save button. Use lower and uppercase letters, a number or two as well as a special character. Click the Save button on the user screen as well to save our changes and we should now have a valid activated admin account to use for SSH. Next, we need to enable SSH access to the NAS. We do this easily by clicking on the left menu "Terminal and SNMP" Make sure the checkbox is enabled for SSH and set the port to 22 if needed. Click the Apply button to save this info. You will need to know the IP address of your NAS. If you're not sure, click the Network menu item, then the Network tab for a similar screen to this: You might see a "bond" or individual NIC cards which isn't that important as we just need to know the IP address. We are now ready to SSH into our NAS. You can use a terminal from a Mac or Linux or a command shell on Windows 10 & 11. In Windows hold with Windows Key while pressing R Type cmd and click the OK button. From your shell or terminal type you will launch an SSH session with the following command. Change 10.69.0.31 to use the IP of your NAS. SSH admin@10.69.0.31 If this is the first time you have SSHed into your NAS you may be asked to save a secured encryption key or similar so answer by typing yes (3 letters), not just y. You will now be prompted to type your admin password. Type it and hit enter. Go Super User Once logged in type sudo -i Navigate to Emby Server App Location We can now navigate to the top level directory of our Emby Server using: cd /volume1/@appdata/EmbyServer we can view the directory using: ls -l Change Directory If we wanted to change directory to the plugins folder we could do this: cd plugins or cd /volume1/@appdata/EmbyServer/plugins List Directory's Files and Subdirectories To view items we can do ls -l Deleting/Removing File If there was a plugin name that is not wanted you could delete it using the rm name followed by the dll name (case matters). If you had 2 dlls you wanted to remove named helper.dll and EmbyHelper.dll you could remove these using: rm helper.dll rm EmbyHelper.dll If you had a file named EmbyScripterX.xml you wished to remove that was in the config folder you could change directory up to the parent from the plugins directory using: cd .. Then to the config directory with: cd config You could now view this directory contents with ls -l To delete the file mentioned above you would type: rm EmbyScripterX.xml If you had a file in the config directory name ReadyState.xml that you wanted to remove you would use: rm ReadyState.xml Listing the Data Directory and all your Emby Database Files If you wanted to see how big your database files are you could navigate back up to the parent and then to the data directory with: cd .. cd data or cd /volume1/@appdata/EmbyServer/data ls -lh (note we added an h to the above command line to give us human readable file sizes) If you had an Emby Server that starts and immediately stopped and wanted to see what the latest log file contains you could navigate to the logs directory with: cd .. cd logs or cd /volume1/@appdata/EmbyServer/logs ls -lh View the current Log File while Emby is Running You can display the whole file quickly using: tail -f embyserver.txt (ctrl-c to quit) Copy a File to a New Location You could also copy the log file to a location you can access easily in a browser using cp embyserver.txt /volume1/homes/admin Viewing the Admin Password Reset File Knowledge Base: https://emby.media/support/articles/Admin-Password-Reset.html cat /var/lib/emby/passwordreset.txt or cat /volume1/@appdata/EmbyServer/passwordreset.txt Finishing Up When you are finished close your SSH connection. Reverse the first couple steps we did by deactivating the admin account until we need it again. We can also turn off SSH again until we need it! I hope you found the tutorial and examples useful, Carlo

There's no pain involved. It was just the answer he deserved.

Requiring a password to perform administrative activities is simply good security. Having the option to not use a password for the admin account was a bad idea to begin with. I can't imagine you are regularly administrating your server via your streaming devices. I assume you are doing this with a browser. And in the case of a browser, you simply have to check the remember me checkbox after typing in a password one time, and the cookie logs you in for future browser sessions. So, you have to type a password one time. This really doesn't seem very onerous to me.

...and by the APIs and functionality that the malware exposes. It doesn't do anything by itself, but you can do everything with it when you have control, also it hides itself and has functions to hide its activities and clean the logs from it in a targeted way.

The most likely theory I've seen expressed is that this attack was building a botnet for later exploitation, perhaps initially being sold on to more directly malignant actors. This is supported by the lack of any evidence (so far) of effects that reached beyond Emby itself. Paul

Have discovered a workaround to the issue. When adding a library, in the folder path dialogue box: Typing \\localservername\music (for example) does not resolve servername (though as stated above \\localhost\music does) However, by first scrolling to the bottom of the available folders/shares and selecting Network, brings up smb://localservername. Selecting this does resolves to the local host! However, selecting media shares this way adds the path smb://localservername/music which is, I believe, not portable between linux and windows. But manually entering \\localserver\music now works correctly and is resolved.

You can't imagine how much I hated having to do it this way. It regularly upsets me that Chrome, Edge and Firefox are installing Scheduled Tasks on Windows which allow them to execute things with elevation. Same goes for all other updates which install without asking for consent. The problem in this case was that it had to happen all at once for all Emby servers in the world. That was the only way to take that BotNet down - by giving them no time to adapt and take measures. You can disable automatic restart after plugin updates.

It seems like you are more upset with the inconvenience of your server being turned off than your system being compromised. I agree only in that I do not think they went far enough to getting everyone notified about what was happening. I think they acted appropriately in turning off the systems affected. This happens all the time in other compromised situations where you may be temporarily logged out of your account whereby you will need to reset credentials. At the end of the day, you do not own Emby. They do. If you don't like how they do something, of course, you are free to do whatever you want in terms of using their software or not. Many mistakes were made here, but turning off the affected systems wasn't one of them, IMHO.

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!

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.

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.

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

There is a saying that you can't please all of the people all of the time and this is a good example of that. I have had to deal with similar security issues in systems much larger and somewhat more important than a media server and the potential for a witch hunt after the system has been protected is always there. I always found that in the commercial world the customer always wanted a witch hunt and someone to blame but in the sector I dealt with they were much more prosaic as they had much more important sh1t to deal with . I'm sure the Emby team will have a good washup after this and hopefully have an AAR (after action report) with recommendations of how to deal with this sort of situation in the future. I don't expect full disclosure of this report as it should be treated as "commercial in confidence" and kept away from the prying eyes of the hackers who find this sort of thing fun. It would be nice to have an outline policy published which could/should form part of the conditions of use of the software. Considering that 1200 systems were found to be affected and the number of complaints is only 1 - 2% of that figure I would consider this a JOB WELL DONE Some big lessons to be learnt and I'm sure they have been I do have a general question for all. What was the point of this attack? was it just a "I can so I will" by some idiot who thinks it's fun or was there actually any gain to be had?

Hey, I added it to TVDB for you. I didn't go as far as listing the staff and actors, though - you can update it further if you want. Paul

thanks a lot quickmic for you help, everything work now

Giving the IMDB id doesn't help if TVDB is your main series source, because TVDB doesn't have the series. Either follow the instructions given earlier by GrimReaper, or add it to TVDB yourself (there are only four episodes that were aired). Paul

@quickmic I will glady set you up as a user so you could try on one of your kodi instances and see what you get if you were willing to go that length.

The whole feature complex around discriminating local network vs. non-local network is flawed by design. We will probably get away from this. Passwordless login is something that needs to be handled by the clients, not by compromising server security.

solved: update to latest beta 8.1.4 full kodi database resync.

That's okay. You will just have to reload 4.7.12, but using the version compiled for DSM 7.2 the second time After upgrading to DSM 7.2 your NAS will say that Emby package is incompatible with DSM 7.2 and Emby server won''t start. Then just download Emby 4.7.12 for DSM 7.2 and install it over top. Works fine.

DSM 7.2 is rolling out in phases just like always. You can wait, or you download and upgrade now. Release notes: https://www.synology.com/en-us/releaseNote/DSM?model=DS220%2B#7_2 Download: https://www.synology.com/en-us/support/download/DS220+?version=7.2#system Use the Emby server 7.2+ link to upgrade Emby after upgrading to DSM 7.2 or higher. Use the other link until then. It's up to you.

Gotcha. Thanks so much for steering me in the right direction. Is it safe to assume that the default values in Emby changed over the years and that's why the older server has different settings? I don't see either of those options in the gui settings for the server or the library. I'll do a full backup before changing it and will report back with my findings here. Thanks so much.

ok thanks - let me check this tomorrow - it's late here in the UK...

Hello everyone Just thought I'd share what I did and it ended up working. I found this helpful video on YouTube actually. Following this tutorial i was Able to reset the PC AND Keep all my apps and personal files. Pretty amazing actually lol. Didnt have to change anything after it was done. My windows is back and working great again. Thx for everyone's tips.

Well I will be darned! Thank you very much!

Hi, by any chance does this help resolve the issue? https://sourceforge.net/p/vnc-tight/mailman/message/13357114/

Thank you, you magnificent Emby team! It works! Beautious!

Take a look at the link in red at the top of the page. You may be affected by that.

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.

Thanks, seems normal again.

Happy to help out, if I can. One last tip. If you want to see which recordings failed, go to the log folder in Windows explorer. Under advanced options, make sure File Contents is checked. In the search area put OPERATION NOT PERMITTED. You will get a list of all the log files where the recording failed. I do this regularly to clean up my library and throw away recordings that didnt complete. Nothing worse than watching something with the end missing! I also noticed that many streaming providers specifically say they do NOT support recording (including the one I use, sadly). This is probably because they dont want to deal with the complaints of their streams dropping out. So Im looking forwarded to these changes happening and perhaps recordings will stay "alive" longer.

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.

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.

This is normal though right ? The browser is saving the emby password (if you ask it to) like it does with any website out there ? Jeez - if I had to type in my passwords then I'd be there all day - infact I do not KNOW my Admin passwords at all - I have no idea, they come from a passwrd manager are are 20 chars at the very least .. On a device where the password is not saved (locked to that 'user session/browser/hardware), then of course you'll need to enter it again.

You can still set it, but it will reset itself again shortly (with the same notice in the alerts), and even while set it will refuse to auth with a pin/without a pass. (did a bunch of testing last night)

So your saying re-broadcasting copyrighted content without a license to do so is legal in your country? I'm sure the big studios/tv networks would disagree about that! Downloading is one thing.. maybe a small fine/slap on the wrist but re-broadcasting copyrighted content without a license is a different story and can lead to a huge fine or some time in jail in most countries. You've got to be intelligent for 5 minutes...

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

Si entras como Administrador sí que te aparece la ruta de la película, pero si entras como un usuario normal creo que no se ve. En mi caso con un usuario que no tiene derechos de administrador se ve así:

I love this thread. "Hi, I am trying to commit crimes. Please allow me to commit crimes."

Who cares what I like or don't like? We are talking about respect for the user. See Netflix which is losing thousands of users in France since yesterday following their stupid rule forbidding the connection on multi-site, I really feel that the people who manage Emby are from the same schools. The respect of the user, it is to bring him a solution when he is blocked and that he does what he can to respect an arbitrary rule which does not make any sense. I RESPECT THE RULE. I expect my license to be reactivated immediately.

No additional changes required. Maybe reset artwork, but not mandatory. Some devices may have problems with path substitution, if so keep it disabled.

You can try latest plugins beta and enable "Use path subsitution". This is a workaround for an actual Kodi limitation.

how long exactly do we have to wait for that?

The purpose of these "splinters" is precisely to allow the emby team to realize that their economic model is no longer adapted to the use that the users make of it. A project that doesn't listen to its community (and your message proves that I'm not the only one to complain) is doomed to disappear in the short or long term. I'm not a fan of changing creamery every 4 mornings. I prefer to trust a tool that I use and that I am satisfied with most of its features. But when something goes wrong, I say it clearly. Having only happy people in front of you doesn't allow you to know the true thinking of the majority of your audience towards you. Accepting criticism and confronting opposing opinions is much healthier than locking yourself in your bubble of benevolence. To conclude, I confirm you that I migrated on Jellyfin, which is maybe not as successful as Emby, but which has the merit to be clear about its license: it is free. And the mere fact that this fork exists shows that I am far from being the only one to think that this licensing system is pure theft. I will be able to contribute to the project by integrating some features from Emby to make it more complete. It seems that this is also the strength of capitalism: having to adapt to a competitor who can become better than you. Good luck for the future of your project, as far as I'm concerned, it will stop here (well in 1 year for some devices since I paid the license like a fool for the year, I might as well use it to the maximum of what it allows me...).

I think you would find the demand is quite high. And frankly, I am surprised that is not already on the road map for this feature set. I have seen many requests on the forum for the extras of a tv show to appear in a distinctly separate location in the UI, like it is for movies. A common suggestion being underneath the cast section.

But why? That makes everything worse? Can you explain the benefit of throwing every single form of extra into one folder? Especially one that would have separate files that grab metadata from other sites like tvdb? This seems like a very unorganized way to group it.