https://support.plex.tv/articles/201105343-advanced-hidden-server-settings/
To me, reconfiguring Plex Media Server to look for known file names outside of its usual file system space counts as an RCE.
As is somehow apparently using /etc/passwd to build a list of usersā home directories to look through.
(Changed āscanā to ālookā to avoid confusion as to use of PMS media scan facility to look for target files)
Yes, I also thought first on this. But it replaces the PMS log files which makes it harder for Plex Employees to analyze my logs.
Edit 1:
There seems to be also a variable called logDebug. Maybe this overrides the configuration from the webGUI permanently?
Edit 2:
Ok, forget that. It was just the explanation of the Preferences.xml file.
I donāt see this.
When logging is disabled (Enable Plex Media Server debug logging is unchecked, or logDebug="0"), I donāt see any activity in the Plex Media Scanner.log file. Adding a folder to a Library and performing Scan Library Files doesnāt generate any other logging.
But it is possible to reproduce the exact boost::filesystem::status exceptions that youāve reported, even while logging is disabled.
Feb 20, 2022 08:37:10.687 [0x809974200] ERROR - Couldn't check for the existence of file "/tmp/permissions.test/unreadable/foo": boost::filesystem::status: Permission denied: "/tmp/permissions.test/unreadable/foo"
Thatās reproducible by adding a folder path to a Library, where Plex doesnāt have permission to traverse (read+execute) an intermediate parent folder.
So I assume that these folders were added to a Plex Library.
@dane22, PLEX_MEDIA_SERVER_USE_SYSLOG doesnāt exist in the FreeBSD or macOS binaries. Iām betting itās Linux-only.
But a scan of the library can not cause errors of files and folders that do not exist!
It can - thatās what I did in my example.
Feb 20, 2022 08:37:10.687 [0x809974200] ERROR - Couldn't check for the existence of file "/tmp/permissions.test/unreadable/foo": boost::filesystem::status: Permission denied: "/tmp/permissions.test/unreadable/foo"
I added /tmp/permissions.test/unreadable/foo to a Library.
The folder /tmp/permissions.test/unreadable does exist.
The folder /tmp/permissions.test/unreadable/foo does not exist.
Plex has read and execute into /tmp/permissions.test. Plex does not have permission to descend into unreadable.
Out of curiosity I Googled the error message āERROR - Couldn't check for the existence of fileā and all results relate to Plex Media Server failing to scan libraries (and they typically relate to file permissions where PMS can no longer access the relevant folder(s)).
Just mentioning this as it looks more likely that itās the PMS library scanner thatās being abused here. Why else would PMS be logging the error?
The fact that the error logs shown by martinr92 and flow relate to files they both state have never existed on their systems at any time in the past strongly suggests that PMS is being made to look for files by an outside influence, otherwise where would it get the filenames to look for?
I considered an alternate possibility where these two servers may have been compromised in the past and had mining software installed on them which was subsequently āseenā by PMS and indexed. But then why would PMS be looking outside its usual storage areas? Any why would it be looking through the home directories of different users?
Agreed 100%.
As we donāt have access to the Plex Media Server source code, I grepād through the āstringsā output for the main executables and found Couldn't check for the existence of file in the following files:
Plex DLNA Server
Plex Media Scanner
Plex Media Server
Plex Tuner Service
So it could have been any one of those services actually generating the error.
(NB. this was specifically looking at the files in the installer package for Synology on x86-64 on my Mac (as Synology doesnāt have the āstringsā command), the Plex system Iām most familiar with)
This does indeed look like an attacker gained access to one of your authentication tokens and used it to attempt to scan your server for non-Plex-related data.
From your subsequent posts (and the audit logs for your account), it looks like youāve already taken the appropriate action to protect your account from further abuse, but Iāll reiterate them here for anyone who hasnāt seen it:
If you encounter strong signs of unauthorized access to your server, go to Account Settings on app.plex.tv and reset your password, making sure to check the āSign out connected devices after password changeā box. You should use a password manager (thereās one built into most modern web browsers, and third-party options are also available) to generate a random password, rather than creating a memorable (and potentially guessable) one. Always use a unique password; never reuse the same password across several services.
@flow, going by your audit logs, I donāt see any signs of an actual unauthorized login (and if there had been one, you wouldāve received an email about it). Therefore, the compromise likely wasnāt of your password, but instead of an auth token. Unfortunately, PMSās existing logging doesnāt provide enough information to tell us which token was compromised.
These kinds of issues are often a result of insecure third-party tools leaking tokens, but they can also be caused by a compromise of any device signed-in as your user account.
To help audit these kinds of compromises more thoroughly in the future, weāre planning on making some changes to PMSās logging facilities in a future release:
- Logs will be improved by including the name of the device associated with the token used to authenticate each request.
- Additional restrictions will be placed on requests to reduce the serverās log level. This may mean requiring a server restart, only allowing level downgrades if the request came from the local network, and/or other additional controls (TBD). Once weāve decided on how to move forward and made the relevant changes, PMS release notes will include details on the new restrictions.
- Certain low-usage-frequency security-critical requests (preference management, library section creation, filesystem location managementā¦) will be logged at the
INFOlevel (rather thanDEBUG), so that logging of these requests cannot be disabled (by the user or by an attacker).
Thanks for the great summary.
Canāt wait to see the planned improvements related to the logs.
Then we should have more details next time this happens.
While Ridley has confirmed the suspicions that a third-party gained access to the Plex system on these machines using a compromised token, this doesnāt explain how one of the Plex daemons was suborned to a) look outside itās previously configured media locations, and b) look for specific files that were not previously scanned and part of the media library. I honestly think this is more concerning than the hijacked token (which could have happened any number of ways outside of Plexās control).
The proposed changes to logging will help after an attack, but itās not as proactive a stance as Iād like to see.
The access token is equivalent to the ownerās username & password. It was used to disable logging, add folders to a Library, and perform a scan. That part isnāt mysterious.
But why? Was there an end goal beyond reconnaissance?
From an attackerās perspective, why is it useful to add directories with non-media files to Plex? Is it possible to configure Plex to scan additional, arbitrary extensions? Or is it possible to download arbitrary files with known paths from the Library?
Yes, I understand what possession of the auth token confers. Reading back through the thread I see that adding folders to a library is also possible without logging. Iām still confused and concerned as to how one of those Plex services could be made to look for specific files, though, that had never previously existed on the machine or in the library.
The files being looked for are mostly related to cryptocoin wallets. I donāt think itās unreasonable to think the attacker was intending to steal crypto currency.
As to your final point, Iād imagine theyāre trying to take advantage of poorly configured Plex systems where the daemon(s) are either running as root or a user with access to more of the file system than it needs/should have. As the logs indicate the Plex processes looking for specific arbitrary files I think it follows that it could be configured to look for wildcards/pattern matches or regex. Can those arbitrary, non-media files be ingested to the Plex media library? I donāt know. One of the admins (sorry, canāt remember who), stated that files can only be downloaded from Plex if the internal Plex media library ID of the file is known. So exfiltration of arbitrary non-media files via the Plex download functionality would depend on media library ingestion, I think.
Ah, and this is why it was trying to access the browser folders:
You can request to scan a specific path using the API.
http://localhost:32400/library/sections/1/refresh?path=/root/.bitcoin
http://localhost:32400/library/sections/1/refresh?path=/root/.litecoin
Kinda my thinking too.
Iām not sure that follows logically. Being able to add additional directories is known functionality. Iām not aware of it being possible to force ingestion of additional filetypes.
But I agree, there must be some additional ānext stepā here.
⦠after adding the path to a Library. Otherwise it aborts:
Feb 21, 2022 02:06:46.155 [0x809791500] ERROR - '/root/.bitcoin' was not inside any known section location, skipping.
Hey so donāt do this:
http://localhost:32400/library/sections/1/refresh?path=/path/to/library/Show (Year)/../
Thatās a path to a show that exists in the Library, plus a trailing /../.
Strange things happen. I think the /../ is seen as a descendant instead of a parent.
It doesnāt appear to allow escape from the configured Library folder, but it sure does mess up the scanner.
Adding/removing folders is already a given with the token.