Plex Server scans for wallets?

Plex Media Server
99

https://support.plex.tv/articles/201105343-advanced-hidden-server-settings/

100

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)

101

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.

102

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.

103

But a scan of the library can not cause errors of files and folders that do not exist!

104

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.

105

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?

106

Agreed 100%.

107

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)

108

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 INFO level (rather than DEBUG), so that logging of these requests cannot be disabled (by the user or by an attacker).
109

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.

110

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.

111

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?

112

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.

113

Ah, and this is why it was trying to access the browser folders:

114

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
115

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.

116


 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.
117

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.

118

Adding/removing folders is already a given with the token.