Multiple vulnerabilities in Plex Media Server

SEC Consult Vulnerability Lab Security Advisory < 20140411-0 >

=======================================================================

title: Multiple vulnerabilities

product: Plex Media Server

vulnerable version: confirmed in 0.9.9.10

fixed version: none

impact: High

homepage: www.plex.tv

found: 2014-02-06

by: Stefan Viehböck

SEC Consult Vulnerability Lab

www.sec-consult.com

=======================================================================

Vendor/product description:

-----------------------------

"Plex is a media player system consisting of a player application with a

10-foot user interface and an associated media server. It is available for

Mac OS X, Linux, and Microsoft Windows."

URL: en.wikipedia.org/wiki/Plex_(software)

Vulnerability overview/description:

-----------------------------------

1. Use of plain text protocols

Plain text protocols are used in various places.

The Plex App Store fetches App listings and App code via HTTP. This enables

active attackers (MITM) to run code in the context of the Plex Media Server.

The Plex "Remote" functionality uses HTTP as well. This enables passive

attackers to gain access to the session token in order to access the Plex Media

Server web interface.

2. Insecure use of SSL/TLS

The Plex Media Server offers HTTPS access via TCP port 32443. The certificate

that is used is issued by "DigiCert Secure Server CA" which is a commonly

trusted certificate authority. The certificate is issued to "*.hub.plex.tv".

The private key for this certificate is included in the Plex software and can

be extracted easily.

The DNS server behind "hub.plex.tv" is configured to resolve subdomains

relative to the IP indicated in the name. Eg. 1-2-3-4.hub.plex.tv resolves

to the IP 1.2.3.4. This enables all Plex Media Servers to offer SSL/TLS

services out of the box without prior configuration and using a valid

certificate.

For this to work the corresponding private key has to be included in the

software. This enables active attackers to execute SSL MITM attacks as the

private key is effectively public.

This mechanism can be abused by malicious entities to provide services on

arbitrary IPs via SSL/TLS as well. One example would be to run a

watering-hole-style attack by abusing the reputation of the Plex domain as

well as the valid certificate.

As this mechanism requires the private key to be compromised it should not be

used in the first place. The certificate should be revoked.

Note:

The Plex Media Server seems to offer DHE ciphers (DHE_RSA). The perfect forward

secrecy (PFS) properties of these KEX ciphers would prevent passive attackers

from decrypting communication.

3. Unauthenticated information disclosure through stack traces

Python stack traces are included in the responses for some requests. This

allows an attacker to gain information about the target operating system,

local file paths etc. which can be used in further attacks.

4. Cross Site Request Forgery

The application does not implement any kind of CSRF protection. Quite the

contrary, security mechanisms that would minimize the extent of CSRF attacks

are deliberately disabled. The Plex Media Server explicitly allows all

sources (wildcard) in cross-server resource sharing (CORS) as well as in

cross-domain policy restrictions (Flash and Silverlight). This enables

attackers to retrieve arbitrary content (eg. the master token) from the

server.

Proof of concept:

-----------------

1. Use of plain text protocols

No proof of concept needed.

The Plex App store is located at: nine.plugins.plexapp.com

2. Insecure use of SSL/TLS

The private key for the "*.hub.plex.tv" certificate:

3. Unauthenticated information disclosure through stack traces

The following request causes an exception in the application logic.

GET /system/proxy HTTP/1.1

Host: <HOST>

X-Plex-Url: http:// my.plexapp.com/NONEXISTANT

A stack trace is included in the server's response:

HTTP/1.0 500 Internal Server Error
Content-Length: 3437
Content-Type: application/xml
Cache-Control: no-cache
X-Plex-Protocol: 1.0

<?xml version='1.0' encoding='utf-8'?>
<Response code="2000" status="HTTPError: ">
  <Traceback>Traceback (most recent call last):
  File "C:\Users\user\AppData\Local\Plex Media Server\Plug-ins\Framework.bundle\Contents\Resources\Versions\2\Python\Framework\components\runtime.py", line 845, in handle_request
    result = f(**d)
[...]
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 629, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 410, in open
    response = meth(req, response)
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 448, in error
    return self._call_chain(*args)
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "C:\Program Files (x86)\Plex\Plex Media Server\python27.zip\urllib2.py", line 531, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 404: Not Found
</Traceback>

4. Cross Site Request Forgery

No CSRF tokens are implemented.

The files crossdomain.xml and clientaccesspolicy.xml in the webroot allow

both Silverlight and Flash to send arbitrary requests to the server and

receive responses.

Some pages respond with the "Access-Control-Allow-Origin: *" headers.

Vulnerable / tested versions:

-----------------------------

The vulnerabilities have been verified to exist in Plex Media Server version

0.9.9.10.

Vendor contact timeline:

------------------------

2014-02-09: Contacting vendor through elan@plexapp.com and requesting

encryption keys.

2014-02-10: Vendor provides encryption keys.

2014-02-10: Sending advisory and proof of concept exploit.

2014-02-10: Vendor acknowledges receipt of advisory.

2014-02-17: Requesting status update.

2014-02-21: Requesting clarification regarding fixed version.

2014-02-21: Vendors provides further information about reported vulnerabilities.

2014-02-24: Requesting clarification regarding patching status and setting

deadline (2014-03-24).

2014-02-25: Vendor announces that the certificate will be revoked soon.

2014-04-04: Requesting status update.

2014-04-05: Vendor confirms that certificate has been revoked. No other fixes

have been implemented.

2014-04-11: SEC Consult releases security advisory.

Solution:

---------

No solution is available.

Workaround:

-----------

No workaround available.

Advisory URL:

-------------

www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab

SEC Consult

Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius

Headquarter:

Mooslackengasse 17, 1190 Vienna, Austria

Phone: +43 1 8903043 0

Fax: +43 1 8903043 15

Mail: research at sec-consult dot com

Web: www.sec-consult.com

Blog: blog.sec-consult.com

Twitter: twitter.com/sec_consult

Interested in working with the experts of SEC Consult?

Write to career@sec-consult.com

EOF Stefan Viehböck / @2014

Back

Multiple vulnerabilities in Plex Media Server

We use Cookies

Technically required

Analysis / statistics

Matomo