Absolutely. That was my previous comment. How were these arbitrary folders scanned? → First they were (or a parent was) added to the Library.
My stance since the beginning with PMS was to block inbound global access to TCP port 32400 with exclusions for required IPs of Plex.tv servers and those IPs of my remote users. I know this does not help with finding the root cause. However if the bad actor did somehow acquire the token, what good would it be if the source IP is not allowed to send commands with said token…just my 2¢. ![]()
I think I found a way to get Plex Media Server to scan in an arbitrary file (provided it has read permissions) and serve the file as a download.
I was just looking at the same thing. You’re too fast.
The next thing I want to look at is deletion. I think that has to be a media part but I’ve never tried to call it from the api.
Any way to help test with this? I can easily mod a particular function in a PowerShell module I’ve been working on to test/replicate.
Deleting the arbitrary file from disk is also possible after ingesting it into Plex.
So, with a valid auth token, and within the file access permissions of the Plex process, an attacker can:
- do anything expected of a validated user through api calls (notably add media locations and disable logging)
- search for arbitrary files
- download them
- delete them
The auth token can be gained either through a compromised client device, or intercepted in transit from clients configured to use insecure connections, which there will be many of since the expired root cert problems a few months back.
Running Plex in docker is looking very attractive right now ![]()
The technique being discussed for arbitrary file access produces the same exception log messages.
ERROR - Couldn't check for the existence of file "/tmp/permissions/bitcoin.txt": boost::filesystem::status: Permission denied: "/tmp/permissions/bitcoin.txt"
This - and a few other things - makes it plausible that it was the technique being used.
I understand that it’s been escalated within Plex.
From the day I started this thread until now this scares me more and more.
@gary_parker Have technical details been forwarded to the plex employees so that they can implement some prevention?
If I may add here?
I’m following the continued discussions and work being done about this.
They are making a huge amount of progress.
Given the sensitive nature of this topic, I will not speak to any specifics. Specifics are for the team to speak to.
Docker helps enforce that the Plex process only has access to expected files. That’s another layer, and I’m a big fan of defense-in-depth, but it shouldn’t add much to a well-configured system. It’s always a good idea to make sure that the Plex process is running as a dedicated, low-privilege user. I believe that this is the default for all Plex-provided installations.
Same for connection security - don’t disable secure connections.
I’m not minimizing, and Plex is obviously addressing this.
That does prompt another suggestion for consideration by Plex - generate low-privilege tokens, even for Admin users, when connecting from Players. Only generate high-privilege tokens for Web access. A Roku, for instance, doesn’t need to do more than playback.
Thanks for clarification.
Sounds fine for me.
Just wanna be sure, that you are informed and working on this.
Please don’t forget, shared users can’t make server setting changes.
Of course. And the most serious issue is still loss of high-access tokens - that’s the fundamental problem that allows anything else to happen.
Perhaps nobody in this thread, but there are plenty of people creating Managed Users, logging in on their friends’ devices as admin, AND disabling connection security.
I’m glad you guys are on it. I’m sure it’s exciting over (virtually) there.
There is a great deal of discussion and some serious deep-diving happening.
They are all over this like a bad rash.
I have already reported my findings to Plex.
Wait, are they the rash or the doctors? ![]()
Agreed, it’s a lot easier to run Plex safely these days thanks to the package installers.
Sadly I have to allow insecure mode connections to my server since the letsencrypt root certificate expiry problems. My LG TVs won’t connect using SSL any more as a consequence.
I think there’s a good argument for having an admin user that is never used to log into remote clients with. It’s good security practice anyway, and what I do at work.
Are you running plaintext on your LAN only , for those TVs, or for everything?
This is getting off topic now, but I wrote a guide on how to use a ZeroSSL certificate instead of in addition to Let’s Encrypt.