I have been addressing some minor vulnerability scan findings on my public-facing network, and there are a couple of issues reported with PMS that I would like to mention for resolution.
The scanner is doing a “forced crawling” scan of “known” or commonly-used web URIs to see if a response is provided. PMS is returning an http200 on these requests.
Each of these hits PMS, which returns an http200 response, and also the following XML tree:
The returned response data for the unauthenticated visitor seems benign, but shouldn’t PMS return a http404, http401, or some other non-OK response in these circumstances ?? The symptom is the same with an authenticated user as well when manually executed from the browser.
The vulnerability compliance scanner is assigning a CVSS Base Score of 6.3 to this finding.
The /security and /webmail endpoints seem funny indeed.
As for /web – I think Plex needs to expose that, so you have access to the web client (html files, js, css), so you (or your users) can run the web app in their browser. This doesn’t give them any access to server or media. Authentication happens between the web app and plex.tv backend, identifying an account. With that ID/token you’ll then connect to servers which share media with you (incl. your own).
Yes, “web” is used within in the URIs, but if you navigate to it directly you get the result described above. I’m not so much concerned about it being exposed, but rather the response behavior when it’s improperly accessed. That is the crux of the CVSS.
It’s clear there is no obvious exposure of data or unauthorized access. It’s really just a technicality on the response.
Final follow up then I’ll wait patiently for additional feedback and hopefully a fix.
This happens on any URI on Plex Web. Basically there appears to be no http404 returned for addresses that are non existent. For example, https://yourdnsname.com:32400/whatever exhibits the issue - http200 returned to client along with that minimal xml tree as content.
My problem is it’s keeping me from getting a clean PCI score on my network. Scanners view this as a vulnerability.
What’s likely preventing you from receiving a conformant PCI DSS score is the fact that you have a web server (PMS) running on a registered TCP port (32400) exposed on an FQDN which routes to a network that is supposed to be PCI-compliant.
I’m not suggesting that the server shouldn’t return meaningful HTTP responses; however, a 4xx series response is still an indication to an attacker (or vulnerability scanner) that a (potentially) vulnerable web server is running.
The solution should (in my opinion) be to move services not directly related to your payment solution away from said network. Or at least place it behind a reverse proxy/web application firewall (and handle accesses to unused endpoints by dropping them with no response). And use an ephemeral/dynamic port to expose it.
Regarding using port 32400 for all the other activity,
I concur to move those to other ports.
Using port 32400 might as well be port 22 or 80
In my configuration, I perform the processing in CloudFlare before being sent to the appropriate host & port.
I would like to learn more about what’s happening and why.
I need to know if / why this is a Plex issue before I can submit a ticket.
(They will challenge me and I will need to defend / explain )
I’m not sure if it’s the browser or PMS that is generating / returning the content, but the issue is the http200 response indicating the “page” is valid (when it is not).
The scan report lists the following threat description:
Predictable Resource Location Via Forced Browsing
Threat:
A file, directory, or directory listing was discovered on the Web server. These resources are confirmed to be present based on our logic. Some of the content on these files might have sensitive information.
NOTE: Links found in 150004 are found by forced crawling so will not automatically be added to 150009 Links Crawled or the application site map. If links found in 150004 need to be tested they must be added as Explicit URI so they are included in scope and then will be reported in 150009. Once the link is added to be in scope (i.e. Explicit URI) this same link will no longer be reported for 150004.
Impact:
The contents of this file or directory may disclose sensitive information.
Solution:
It is advised to review the contents of the disclosed files. If the contents contain sensitive information, please verify that access to this file or directory is permitted. If necessary, remove it or apply access controls to it.
They’re not failing it on use of a non-standard port for http traffic, they are failing it on the content or response received for “predictable” locations that could disclose sensitive information or access. These “locations” do not disclose anything sensitive under PMS, but because PMS is returning an http 200 the scan client thinks the location is valid. Also note the redirect URL.
The PCI report lists the following examples (among others):
I certainly could “hide” this port from their scanner, but that is not the point. PMS is exposed publicly, whether directly or through Cloudfare, and I would prefer it get scanned as well. I do agree with their finding, albeit not a true security vulnerability as nothing sensitive is actually disclosed.
I will submit this to engineering for review however it is known:
Those replies are size=0 replies (no information conveyed)
Those endpoints do not exist.
I do not know if this is Engineering’s intent for misinformation or disinformation however with size = 0, there is nothing disclosed.
I will remind you: :32400/web is the documented PMS endpoint.
PMS will freely offer the Plex/web client to any connection at that URL.
This is deliberate. It is not a vulnerability.
Advancing beyond that point requires authentication.
Yes, :32400/web is legitimate, but that one failed the scan because of the http200 with a redirect. It should send an http308 along with the :32400/web/index.htm url.
The other non-existent ones should return an http404.
As for the content, that is generated by the browser. PMS is not returning content, only a response code.
Thanks for your help. Hope this helps tighten things up a bit.
