+1 for TLS
I don't really get what people are worried about with this personally. It's a personal media server, it would be highly unlikely for someone sitting on an intermediary network between your client and the server to spend the time capturing and decrypting the network traffic in order to try and get your plex password.
Has anyone just tried putting an SSL terminator in front of their plex server? Simple example install pound or stunnel on a linux vm, buy a cheap domain and certificate to use and tell it to forward all connections on port 443 to port 32400 (or whatever plex web's port is in your case) on the internal IP.
As far as plex is concerned it's still operating as plain HTTP. This won't work with the various clients available I guess with code updates to allow you to choose a protocol but you could test it with plex web.
Ideally you would want to keep the actual video streams in plain HTTP as well to avoid the additional overhead of encrypting the video stream which is completely pointless.
it would be highly unlikely for someone sitting on an intermediary network between your client and the server to spend the time capturing and decrypting the network traffic in order to try and get your plex password.
It has already happened. There are reports of this being exploited in the wild.
Has anyone just tried putting an SSL terminator in front of their plex server?
HTTPS reverse proxies have been tried, but do not work fully on all clients, and do not fully secure communications without disabling many features of Plex.
Ideally you would want to keep the actual video streams in plain HTTP as well
The "overhead" of TLS is minimal, and securing everything simplifies client interactions (stream seeking, image caching, etc.). Thoroughly read through this thread. Fmstrat and I go over the issues in detail later in the thread.
The question I like answered is why are plex devs prioritizing improving features/widgets and profits rather than security.
What good would plex be if everyone stops using it because of its security issues/holes?
How can the community put pressure on plex doing the security fixes?
The question I like answered is why are plex devs prioritizing improving features/widgets and profits rather than security.
Plex is working on this issue. Not as fast as some of us would like, but they are working on it.
There are actually people on the net selling access to other people's Plex servers. So I guess the business case is there.I don't really get what people are worried about with this personally. It's a personal media server, it would be highly unlikely for someone sitting on an intermediary network between your client and the server to spend the time capturing and decrypting the network traffic in order to try and get your plex password.
Getting in between a laptop/tablet/phone and the internet is a piece of cake. The easiest way to do this is buy a pineapple for about $99, position yourself in a hotel lobby or airport terminal and just capture all the passwords. The hardest part is actually keeping up with harvesting the passwords and filtering the useless ones from the usefull ones. Then again, a huge disk is small and cheap these days. This also has been done on a commercial scale already for managers staying in certain hotels. The only thing surprising was that it took so long to discover.
I also think you grossly underestimate the number of NAS-servers out there that have a "Multimedia function" and a "File server" function. Hacking into the Plex server is a large step into breaching the full server. The ReadyNas solution is the worst, since it runs with full root privilidges (nobody knows why). So hacking such a machine, gives you access to the NAS. This will allow for data theft or Bitcoin mining. Please note that Plex servers generally are optimized for transcoding, which also makes them perfect for Bitcoin mining. This already has been done on a huge scale with Synology devices just days after a security flaw in the remote access code was exposed.
So please, for your own security, don't underestimate the creativity of the bad guys to make money out of your machine or think that your machine is safe.
Jaap
There are actually people on the net selling access to other people's servers. So I guess the business case is there.
Getting in between a laptop/tablet/phone and the internet is a piece of cake. The easiest way to do this is buy a pineapple for about $99, position yourself in a hotel lobby or airport terminal and just capture all the passwords. The hardest part is actually keeping up with harvesting the passwords and filtering the useless ones from the usefull ones. Then again, a huge disk is small and cheap these days. This also has been done on a commercial scale already for managers staying in certain hotels. The only thing surprising was that it took so long to discover.
I also think you grossly underestimate the number of NAS-servers out there that have a "Multimedia function" and a "File server" function. Hacking into the Plex server is a large step into breaching the full server. The ReadyNas solution is the worst, since it runs with full root privilidges (nobody knows why). So hacking such a machine, gives you access to the NAS. This will allow for data theft or Bitcoin mining. The later already has been done on a huge scale with Synology devices. Please note that Plex servers generally are optimized for transcoding, which also makes them perfect for that kind of jobs.
So please, don't underestimate the creativity of the bad guys to make money out of your machine or think that your machine is safe.
Jaap
This is why i hate the new layout of the myPlex user interface. The old method, it would show the newest user right at the bottom and be super easy to monitor if anyone is added without my knowledge. Luckily I have not had an issue with this yet, but never know.
Yep. I currently have monitoring scripts installed on my NAS, checking if the server-behaviour makes sense. Anything that puts the CPU above 12% gets reported, any traffic that is unexpected (both destination and/or time) will get reported, any unknown processes will get terminated and reported. And that is with a Plex server within a VPN. Sounds paranoia, but at least I sleep a lot better.This is why i hate the new layout of the myPlex user interface. The old method, it would show the newest user right at the bottom and be super easy to monitor if anyone is added without my knowledge. Luckily I have not had an issue with this yet, but never know.
I don't trust the server until they fixed this.
Jaap
overkill ... but if it helps your OCD ... go with it.
+1 for SSL
I'm sorry but I don't get what's so hard to at least put something in the pipeline until a real solution is worked out. We are going on almost a year of these security breaches (that we know of).
1) Use a wildcard cert owned by Plex
2) Have each plex server generate a unique key that only it and plex.tv knows how to use
3) All communication between plex server and plex.tv (directly between these two only) is done over https and also using plex server key that only these two end points understand
So this is an encrypted message with only 2 parties knowing the keys that is then sent over https.
4) Put a new option on Plex server that only allows invites to happen from known IP addresses. Better yet no configuration data URL should be accessed unless you are from a trusted IP range per the setup of the plex server. So for example I can only do an invite from my local LAN or from my work IP/subnet (configurable by the operator).
5) Optional: On acceptance of invite of user plex.tv then sends a final confirmation email to plex operator email address for a final confirm. This could even be as elaborate as a 6 digit (whatever) PIN code that then has to be entered on the plex server itself and not just clicked in the email.
The confirms in step 5 could/should include the actual email address of the person who received the invite and at a minimum the IP address they last showed up on with a reverse DNS info.
These steps should be pretty easy to implement as a whole and would all but stop the "fake" accounts from being created.
This of course isn't a "fix" for the security issues and token leaks but would at least keep leachers from gaining access to our plex servers and would harden things up tremendously.
Carlo
+1
5) Optional: On acceptance of invite of user plex.tv then sends a final confirmation email to plex operator email address for a final confirm. This could even be as elaborate as a 6 digit (whatever) PIN code that then has to be
All of your points are good, and valid in my eyes. For part 5 in particular, MFA would probably work out quite nicely; support for Google Authenticator / Authy / Yubikey would be a big win.
+1 - this needs to get fixed ASAP.
1) Use a wildcard cert owned by Plex
Plex tried this a while back, and quickly learned that it was a bad idea. If you use a wild card cert on the PMS server, every PMS server ends up having the keys for every other PMS server. It gets you nowhere.
On points 2 and 3; All communications between PMS and plex.tv is currently secure.
4, 5; The invite situation is a mess, but it actually happens on plex.tv, not PMS. The best solution is to put all effort into fully secure client<->PMS communication, so the tokens aren't leaked.
Plex is working on this. There are many variable that complicate things more than it appears on the surface.
But I’m not assuming this IS THE FIX, but only one part of “helping” to make it harder to hack.
I disagree. If certs were that bad there would be no point in using any web cert because it’s the same thing. One of the major problems is the use of “get” instead of “post” commands which leak tokens and other information. If it’s a post done via https is much harder.Plex tried this a while back, and quickly learned that it was a bad idea. If you use a wild card cert on the PMS server, every PMS server ends up having the keys for every other PMS server. It gets you nowhere.
Also notice that I didn’t say step one would fix the problem but it was only a PART of it.
I don’t think so.On points 2 and 3; All communications between PMS and plex.tv is currently secure.
Doesn’t matter where it happens. If the local plex server is part of the transaction and talks securely to plex.tv AND if the plex server only allows this type of change from an authorized IP then much of the spoofing is mute because it could not happen.4, 5; The invite situation is a mess, but it actually happens on plex.tv, not PMS. The best solution is to put all effort into fully secure client<->PMS communication, so the tokens aren’t leaked.
Plex is working on this. There are many variable that complicate things more than it appears on the surface.
Also regardless of who sends a confirmation email on acceptance of an invite, if the plex server operator doesn’t approve it via email then again it’s mute because the “spoofer” will not get access.
None of these on there own will solve the problem but the combination of things is what is needed. This isn’t the ideal way to solve the problem but each of these things could be used as a “band-aid” right now.
Anything like the above is better than nothing (last year).
cayars, I think that you could condense your entire solution to simply implementing a firewall on the Plex port. If you know the IP addresses that you will share with, then that's all you need. No need to have all the other baggage. Still doesn't solve the main problem.
I disagree. If certs were that bad there would be no point in using any web cert because it's the same thing. One of the major problems is the use of "get" instead of "post" commands which leak tokens and other information. If it's a post done via https is much harder.
Get vs post really doesn't matter (unless your web client is displaying the token in a browser's address bar -- but Plex doesn't do this). Any request (get, put, post, delete ...) is fully secured using HTTPS. An attacker cannot see the request, unless they have successfully established a MITM attack (transparent HTTPS proxy).
HTTPS does matter, and is the end goal, but not by using a wildcard cert. Each and every PMS server needs its own certificate. If each PMS server shares a wildcard certificate then all you need to do is download PMS and extract the certificate, allowing you to create a transparent HTTPS proxy for any PMS server -- bringing us back to square one: no security.
I don't think [All communications between PMS and plex.tv is currently secure].
Trust me. It is. PMS talks to plex.tv over HTTPS. Clients also communicate securely with plex.tv. It is as secure as any HTTPS site can be.
It's communication between clients and PMS that is the issue.
Doesn't matter where it happens. If the local plex server is part of the transaction and talks securely to plex.tv AND if the plex server only allows this type of change from an authorized IP then much of the spoofing is mute because it could not happen.
If the connection between the client and PMS is not secured, you have solved nothing. If the client is already on an untrusted network (eg; hotel/airport/coffee shop/what-have-you wifi), then IP address spoofing is not only easy, it's inherent. If an attacker gains a token for a PMS account that also admins a PMS server, the attacker can then (after jumping through a few hoops) share that server with anyone, since they are now effectively the admin.
One relatively simple step that could (should be anyway, as it's just good practice) be put in place to block attackers from being able to share servers is for plex.tv to require a PMS admin to re-enter their account password before sending an invitation (or making any other dramatic account changes), since the attacker should only have been able to gain the account token, not the account password. Plex Home with a PIN kinda implements this. Regardless, attackers could still use the tokens to access your media library without authorization.
(edited for clarity)
+1
(edited post)
