Examining a Phishing Vector in Plex Media Server

Chris Lyne
Tenable TechBlog
Published in
5 min readJun 16, 2020

Intro

I recently disclosed CVE-2020–5740 and CVE-2020–5741 in Plex Media Server for Windows that could be leveraged together to remotely execute code as SYSTEM. The catch is that you need an admin session token (X-Plex-Token) to gain the initial foothold in the application. For this reason, my research led to an intriguing way to execute authenticated application requests with a little phishing effort. Don’t worry, Plex has provided patches and mitigations for these bugs.

Login Process

An admin can log into Plex by visiting their Plex Media Server in a web browser. Interestingly, the server can be accessed using an IP (e.g. http://18.234.58.243:32400/web) or via a *.plex.direct address (e.g. http://18-234-58-243.a50c86c403dd48899997d02db4c7aace.plex.direct:32400/web). Notice how this subdomain resolves to 18.234.58.243.

When one browses to their Plex Media Server, they are immediately redirected to https://app.plex.tv/auth to enter their Plex credentials.

If login is successful, plex.tv returns an authentication token to be used in subsequent communications with the user’s Plex Media Server. The user is then redirected back to their media server. When an authenticated request is made to the media server, this token is specified as the “X-Plex-Token” in either a request header or as a request parameter. The token value is stored in window.localStorage.

A Server Can Be a Client

What I found intriguing is that you can sign into Plex via a Plex Media Server that you don’t own. We’ll call this the “evil” server. Even though you don’t own it, the evil server origin is allowed to communicate with your media server (“victim”). The evil client-side JavaScript can access the authentication token stored in window.localStorage.myPlexAccessToken and send a cross-origin XMLHttpRequest to your server.

In the example below, the evil server is located at 18–234–58–243.0b8b28be804944fb93c9097338617b9c.plex.direct:32400, and the victim server is 34–207–124–74.0b8b28be804944fb93c9097338617b9c.plex.direct:32400. Those addresses look similar! After browsing to the evil server and signing in as the victim admin user, I observed the following requests fire off. I’ve removed some of the irrelevant parameters and headers to better highlight the issue.

Here we have a preflighted request, since the browser noticed the request is cross-origin and potentially unsafe. Note that the Access-Control-Allow-Origin response header specifies any origin is allowed to send this request.

Again, the evil client-side JavaScript can access the authentication token.

As you can see in the image, the current document domain (origin) differs from the victim media server connection URI. With the authentication token and the permissive access control policy, the evil origin can send whatever requests it wants to the victim server. This means malicious JavaScript served by the evil Plex Media Server would have full reign of the victim Plex Media Server.

Gone Phishing

In order to exploit this trust relationship between a Plex Media Server and a client, a phishing attack would need to be carried out. The attacker would have to convince a “victim” user (admin of a Plex Media Server) to sign into Plex through the attacker’s “evil” Plex Media Server. I believe this sounds more difficult than it is in practice. Let’s look at an example.

Plex Media Server admins are able to invite other Plex users to access their media. There are even websites dedicated to Plex Media shares where users can join free or paid Plex shares (Note: this does violate the Plex Media Terms of Service). If a user were to be invited, they would receive an email like this:

Here we have an email template that is ripe for exploitation. This is an email that a user might legitimately receive while using Plex. If the attacker were to craft a similar email with the hyperlink pointing to their own evil Plex Media Server, the victim would then log in, and that would be end-of-story (assuming the victim is admin of a media server).

This becomes more feasible if the victim user has previously logged in to their own server at some point because the victim wouldn’t need their password to log in.

Below is a video to demonstrate a phishing attack. In this example, I modified the evil JavaScript to send the X-Plex-Token to be used outside of the browser. Notice the use of the Plex direct URL.

Complete Server Takeover

As you can see in the video, an attacker could exploit this issue to gain access to your private photos (or any media). Without patches, an attacker could completely take over a victim’s Plex Media Server and the underlying operating system. This would be accomplished by exploiting the following vulnerabilities in a chain.

As I mentioned earlier, I disclosed two other vulnerabilities in Plex Media Server that can be leveraged to gain code execution with SYSTEM privileges:

  1. CVE-2020–5741: Authenticated Python Deserialization Vulnerability (RCE)
  2. CVE-2020–5740: Local Privilege Escalation in Plex Update Service

After a successful phishing attack, using the acquired X-Plex-Token, CVE-2020–5741 could be exploited to execute code with the privileges of the media server process. The level of access could then be escalated to SYSTEM by exploiting CVE-2020–5740 in the Plex Update Service. At this point, the media server would be completely compromised.

Popping Calc with CVE-2020–5741

For more technical information on these code execution vulnerabilities, please check out our research advisories: TRA-2020–25 and TRA-2020–32.

Closing Thoughts

Plex patched the privilege escalation in such a way that only versions older than 1.18.2 are still vulnerable. This is impressive to me because I reported version 1.18.9.2578 as vulnerable, but their patch covers versions prior to that. What makes these patches even stronger is that the camera upload functionality required to exploit the RCE was introduced in version 1.18.2.2041. Basically, the LPE and RCE are now mutually exclusive, and these bugs cannot be exploited in a chain. Finally, Plex provided a mitigation on the server-side that will alert users if they are logging into a media server not hosted by Plex. Check out our research advisory for more information.

--

--

Chris Lyne
Tenable TechBlog

Chris is a security researcher. He is a former developer and aims to make the cyber world more secure.