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.
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://220.127.116.11: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.104.22.168.
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
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.
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.
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:
- CVE-2020–5741: Authenticated Python Deserialization Vulnerability (RCE)
- 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.
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 22.214.171.12478 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 126.96.36.1991. 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.