Plex Media Server.log:Mar 06, 2022 03:25:02.327 [0x7f06c7bfab38] DEBUG - Request: [my.obfuscated.client:58631 (WAN)] GET /library/metadata/4370?checkFiles=1 (7 live) TLS Signed-in Token (gary_parker)
Plex Media Server.log:Mar 06, 2022 03:25:02.347 [0x7f06c7bfab38] DEBUG - Audio Stream: 23948, Subtitle Stream: 0
Plex Media Server.log:Mar 06, 2022 03:25:02.351 [0x7f06cabe8b38] DEBUG - Completed: [my.obfuscated.client:58631] 200 GET /library/metadata/4370?checkFiles=1 (7 live) TLS 23ms 17437 bytes
Plex Media Server.log:Mar 06, 2022 03:25:15.795 [0x7f06cac0bb38] DEBUG - Request: [170.106.115.55:37818 (WAN)] GET / (8 live) TLS Signed-in
Plex Media Server.log:Mar 06, 2022 03:25:15.796 [0x7f06cac0bb38] DEBUG - Completed: [170.106.115.55:37818] 401 GET / (8 live) TLS 0ms 371 bytes
Plex Media Server.log:Mar 06, 2022 03:25:16.120 [0x7f06cac0bb38] DEBUG - CERT: incomplete TLS handshake from 170.106.115.55:37170: Connection reset by peer
Plex Media Server.log:Mar 06, 2022 03:25:23.303 [0x7f06cabe8b38] DEBUG - Request: [8.31.2.45:57408 (WAN)] GET / (8 live) TLS GZIP Signed-in
Plex Media Server.log:Mar 06, 2022 03:25:23.303 [0x7f06cabe8b38] DEBUG - Completed: [8.31.2.45:57408] 401 GET / (8 live) TLS GZIP 0ms 435 bytes
Plex Media Server.log:Mar 06, 2022 03:25:27.646 [0x7f06cabe8b38] DEBUG - Request: [111.7.100.17:16154 (WAN)] GET / (8 live) TLS GZIP Signed-in
Plex Media Server.log:Mar 06, 2022 03:25:27.647 [0x7f06cabe8b38] DEBUG - Completed: [111.7.100.17:16154] 401 GET / (8 live) TLS GZIP 0ms 435 bytes
Plex Media Server.log:Mar 06, 2022 03:25:28.495 [0x7f06cac0bb38] WARN - [CERT] TLS connection from 209.141.51.222:18394 came in with unrecognized non-plex.direct SNI name 'my.obfuscated.server'; using installed user cert anyway
Plex Media Server.log:Mar 06, 2022 03:25:28.744 [0x7f06c7bfab38] DEBUG - Request: [111.7.100.16:15479 (WAN)] GET /web/index.html (9 live) TLS GZIP Signed-in
âmy.obfuscated.clientâ is my home broadband IP address (which, as I say, also has another Plex server NATâd behind this IP address).
âmy.obfuscated.serverâ is the hostname of the server these logs are from.
Also, I just had a look in the âAuthorised Devicesâ section of the web interface and there is no Chrome client listed as having connected in the timeframe. In fact the last Chrome client connection was 6 days ago.
FYI, there is no valid reason for any of the IPs listed in those logs to be accessing my server legitimately (170.106.115.55, 8.31.2.45 or 111.7.100.16, in Singapore, USA and China, respectively).
FWIW, you can setup Plex behind a nginx reverse proxy and have it only respond to requests sent via a domain name instead of your raw IP address. In other words the server wont respond unless resources are requested via the domain name and if they are requested via IP then youâll get the default nginx landing page.
This is how I have mine setup and never get any requests to my server because nobody knows the domain it sits behind⊠even if theyâre bombarding my IP with hack attempts.
This requres some extra configuration inside Plex but is fairly straight forward.
There is definitely a problem with the Plex.tv authorization. Iâm still waiting for some reaction of a Plex employee here. Because it happed on my server again, after I changed the password and signed out from all devices.
If it were a problem with the Plex API then this would certainly be a more widespread problem than a few isolated cases.
And having a ârobust server systemâ and not being a beginner has no relevance on being compromised. You realize youâre basically calling out Plex saying their API is being hacked but you arenât hacked yourself?
You do realize this is a typical symptom of being compromised?
I think the level of response so far from the Plex team would indicate that they believe it is an issue with their product. The level of logging necessary, and the attention needed by the admin user, means that the vast majority of Plex users wouldnât notice the things observed in this thread so far.
I absolutely believe 100% their product is a security liability which is why I run it behind a nginx proxy on a domain so it canât be bombarded by attacks at the bare minimum. But to dismiss the idea of him being compromised itself is careless wether itâs compromised by some other program running or in fact PMS (which I believe to be the case) especially if it keeps happening.
Thereâs more than one way to get the keys to this castle.
What I also meant was I didnât think it was the actual authentication API hosted by the Plex infrastructure. I may have read his statement wrong if he meant the server API. I do believe their server software that everyone runs is not secure in any of the sense.
I also thought about putting it behind a nginx proxy or re-configure the firewall rule to limit IP-addresses.
But this makes it hard, to access from hotels or public WIFIs what is one of my key features why I use Plex: to access to all media files from everywhere.
Also sharing media with friends is much more complicated.
Thatâs why I want to make clear here, that the root cause for this logons with admin token must be found. But I can only check my servers and infrastructure. I cannot check, the authentication and security part of PMS.
This are my current questions regarding this case:
When is a new token generated?
How works token generation?
Can we see anywhere the active tokens? (we can currently see only the authorized devices, but the problematic device is not listed there)
Are there any âadminâ/background tokens used, e.g. so that PMS can communicate with the Plex.tv Domain(s) (like for EPG refresh)?
How does PMS validate the token? Is it online checked against some API on Plex.tv? Or is it more some kind of JWT based system where no live API for validation is required?
For all who are posting in this thread: Please take this serious. I do. And you should too.
Since itâs no open source software, we canât analyze and fix it on our own.
Support from the Plex employees is here the key to success And they are here and reading our posts.
So if you notice something unexpected/unexplainable in your logs, please post them here (like @gary_parker did some posts before).
It seems the overseerr requests app can cause behaviour like that, any of you guys running it? Every few weeks it would give 3 or 4 new âchromeâ connections in a row without them showing in plex devices.
I donât use Chrome (only Safari on my Mac). Thatâs why the notification (that named also Chrome as browser) made me alert.
Also donât know/use âoverseerrâ.
I know that if you use Roku and happen to setup a new device and link it to an existing Roku account that when you start Plex up on the new device it will share the auth token and automatically login and you will get an email saying a new device logged in. This was happening to me when family was setting up additional Roku devices without having me input the 4 digit code.
Does this have anything to do with whats happening? I dunno but it will trigger that login email and may be a way to get the auth tokens.
If you setup wireguard on your edge, you can give yourself 100% secure access from anywhere and be âlocalâ when connected. I have switched to wireguard on my router over using other VPN solutions.
Sharing with others is a little problematic. Have then get a free DDNS. Use that DDNS in your firewall pass rule to control access. Itâs your server and theyâll comply with your request if they want to continue streaming from it.
Is it the email notification about a new login? Or the mobile app notification about a new device?
The email indicates your password was used to login and a new token was generated.
The mobile app notification indicates one of your tokens was used with a different âClient Identifierâ.
I hope youâre talking about the latter and your password isnât compromised.
Assuming you are talking about the latter, I wouldnât put much weight on the device being âChromeâ, specifically. That value can be set to anything and doesnât necessarily indicate the actual device. Itâs up to the application using the token to correctly identify itself. Here I accessed my server API and identified myself as âPotatoâ to demonstrate.
All Plex clients identify themselves correctly, but 3rd party apps or a malicious attacker may just be using a âdefaultâ value of âChromeâ. I would do an audit of any 3rd party applications and check that they are identifying themselves properly.
I was able to get Access Tokens from other users (not my own user). Details has been submitted a few minutes ago to Plex using the security e-Mail address.
For security reason I will not share any details here until Plex employees had a chance to fix this or respond to my e-Mail.
Itâs the push notification to mobile client about a new device. I figured that the identity could be spoofed as easily as a browser user agent string.
There was some talk of âoverseerâ upthread; the only third party app that has access to one of my Plex servers is Tautulli, and it doesnât have access to the particular server I got the alert from.
PMS calls the API âhttps://plex.tv/api/v2/server/access_tokens?auth_token=xxxâ (you can find them in the logs). The auth_token is not the typical user token. It is the âPlexOnlineTokenâ stored in the Preferences.xml file of the server (on Linux; might be different on other systems). You can try calling them on your own (and check, what information is returned).
This endpoint shows multiple issues at once:
Tokens are stored in cleartext Situation
The endpoint returns all tokens in clear text. Not salted in anyway. Problem
Everyone with database access (Plex Employees or also a possible database breach) offers a list of valid tokens that can be used to easily access my server without me knowing. Also since the tokens are not short living (my oldest token is 9 years old) itâs a good point for attackers. I change my password, but the tokens never does. Possible Solution
Store tokens only salted AND expire old tokens. Since more and more tokens are leaking (you can see this in the forum that more and more users are affected; Anti-Virus systems are alerting, âŠ) this should be implemented with high priority. Response from Plex Security Team
âThese are authentication tokens not passwords. The reasons for hashing and salting stored passwords do not make sense for authentication tokens.[âŠ]â
and one email later
âWeâll consider adding token hashing in some situations in the future as an exploit-mitigation measure, but due to the limited scope of escalation the current system provides, we consider its current absence to be an area where further hardening would be possible, rather than a serious vulnerability that must be addressed immediately.â
Old tokens, even after password reset Situation
I did a password reset and choosed the option to disconnect all devices because I might have a leaked token. Problem
The list contains still some old tokens (one from 2013, another from 2021, âŠ). Not all of them have been deleted. So a possibly leaked token can still be used. Possible Solution
Delete all tokens. It seems to be buggy in some way. Response from Plex Security Team
no final statement until now; Iâm waiting for a response now since 3 days
The endpoint itself Situation
The endpoint returns all possible tokens (mine and tokens from friends). Problem
I can use tokens of others to act as a different person on my server (plex.tv is not affected). Possible Solution
The server should send also (as a second parameter) the actual user token. Then Plex.tv validates this token and returns only information relevant for this token. This avoids a full list of all tokens. Response from Plex Security Team
ânote that a shared-user token only allows read-only access to servers owned by user A and shared with user B.[âŠ]â
âThis is how the authentication system works.[âŠ]â
All this information have been sent to Plex via the âReporting Security Issuesâ email address. The initial response was not acceptable to me so I provided more information and explained more my concerns. They tried to explain me, why everything is as it is but not that they will fix or change something right now.
Security is very important and Plex is (currently) not willing to do anything related to the points above. Also since it is not possible to use our own authentication system (like a setting to use a custom oauth endpoint instead of Plex.tv) we must be able to trust Plex.tv. Currently I donât trust them anymore.
How is your opinion to the points above? Do you have other suggestions as a solution for a point?
Hopefully they take other reports to this security mail address more seriousâŠ
And they are here and reading our posts.
