Abusing the MPC-HC WebUI to steal private pictures
Update 2015-08-06: As of last night (2015-08-05), the snapshot.jpg function is disabled by default in beta versions of MPC-HC. More mitigation is also on the way but will likely take longer to develop. Thanks to underground78 for making this happen.
A while back I started reading the source code of Media Player Classic (MPC-HC), mainly as an exercise for getting better at reading C++ code. This post is not really related to C++, but to another pretty interesting (IMHO) finding.
MPC-HC and the WebUI MPC-HC is a popular open source desktop media player written in C++. It supports a wide variety of media formats and has a bunch of cool features. One of them is a web interface called the “WebUI” that can be enabled from the Options menu of the desktop client.
When WebUI is enabled, MPC-HC starts a web server on the machine where it’s running. Per default WebUI listens on the external interface of the machine where MPC-HC is running, but it can also be set to listen on localhost only. At first I thought that this feature was not very widely used, but I was wrong. As it turns out, the WebUI is used as an API by several iOS and Android apps, enabling users to remotely control the MPC-HC client over a local network.
When browsing to the WebUI, a very simple website is shown from where you can trigger a number of actions in the MPC-HC player, such as opening a new file, controlling the volume, shutting down the computer (!!!), etc.. There is also a “file browser” function that can be used to browse the filesystem of the host and to choose a file for MPC-HC to open. Any file that is chosen from the file browser will be opened by MPC-HC locally on the system where MPC-HC is running, which means that it is limited to the media player’s supported formats.
Since the WebUI is not protected by authentication, a “rickroll” attack could be performed by an attacker on the same network as the host running MPC-HC with WebUI enabled simply by issuing the following cURL command:
curl "http://<target_ip>:<target_port>/browser.html?path=\\\some_smb_share\rick_astley.mp4″ > /dev/null
Ok, that’s mildy amusing but not really much more. There is more though.
Hidden features, sort of While the fact that the WebUI can be reached by anyone on the same network as the host running MPC-HC is pretty bad since it means that it is possible to browse the filesystem, it is not possible to read or change the content of any files in this way. The MPC-HC client will attempt to open a file chosen from the file browser locally, and only files with a format supported by MPC-HC will be successfully opened. There is however a “hidden” feature in the WebUI that can be abused to steal actual content from the host.
While reading the source code, I came across this section:
There are several things that seem a bit off about the highlighted part of the code; firstly the fact that the “/snapshot.jpg” URI is not referenced anywhere in the HTML code of the WebUI, and secondly that it is pointing to a function (OnSnapshotJpeg()) in the CWebClientSocket namespace.
As it turns out, what the OnSnapshotJpeg() function (line 806 in WebClientSocket.cpp, too big to display here) does is create a snapshot of what is currently displayed by MPC-HC. This means that simply going to the “/snapshot.jpg” will create the snapshot and display it as a JPEG image.
Exploiting the issue Since we already have access to view the filesystem (but not read any file content), what we can do is to enumerate the supported files, make MPC-HC open the ones that are of a supported format (like images), and then download them from “/snapshot.jpg”. This simple Python script will for example steal every image in a given users Pictures folder on Windows.
And a video (sorry about the terrible quality).
While the above PoC is a very simple example of what could be done by abusing this weakness, there are multiple other ways of performing a more comprehensive attack. User names could also easily be enumerated, and there are several other places besides the Pictures folder where interesting media could be found. For example, both Firefox and Chrome store so-called “thumbnails” - image captures - of previously visited websites, which could potentially give away information about the victims browsing habits and other sensitive information.
About disclosure When I reported the issue, I was under the impression that it would be easy to fix and wouldn’t affect a lot of people, but it turns out I was dead wrong. Because of the 3rd party apps using the WebUI as an API, doing something obvious like implementing authentication would likely break things for a lot of people.
The MPC-HC team was very responsive when I reported this back in the beginning of May (the 5th) and assigned the case the highest priority (blocker). Unfortunately, not very much has happened since. As one of the developers put it: “we are understaffed and nobody has time to look into this more closely”, which basically means that this issue will likely not be fixed in a long while. Given that all the information is and always have been publicly available on the MPC-HC bugtracker anyway, I thought it best to fully disclose the issue so that users of MPC-HC can apply the mitigations mentioned below.
Mitigations The issue can be mitigated by disabling the WebUI when not on a trusted network (like at home) or behind a NAT device (i.e. not directly reachable over the Internet). This makes sense as users are unlikely to need the remote control functionality when watching movies on Starbucks or at an airport, but is not really a solution that will scale well across the user base.
Final thoughts This issue is a great example of why security needs to be involved throughout all the stages of the development cycle. Had there been an early security review of the WebUI design, it is very likely that authentication would have been present from the start and then all the 3rd party apps using it would have supported it as well. Fixing bugs is always cheaper the earlier you catch them, and this is not an exception.
One of the developers wrote that “...one has to remember it was never meant to be used outside of a properly protected LAN” which might have been reasonable thinking once upon a time, but given how and where computers are being used today, that reasoning simply does not hold up anymore.