Opened 23 months ago

Closed 20 months ago

Last modified 17 months ago

#5411 closed Bug (fixed)

Security design flaw in WebUI enables information leakage

Reported by: addelindh Owned by: underground78
Priority: high Milestone: 1.7.10
Component: WebUI Version: 1.7.8
Severity: blocker Keywords: WebUI
Cc: underground78, xhmikosr Evaluation: diagnosed

Description

When starting the WebUI/web server from View->Options->Web interface, the default is to listen on the external interface, not localhost only. This makes it possible for an external user on the same network to browse the structure of the MPC-HC users filesystem by using the http://<ip-address>/browser.html?path= URL, and also to image content from the users computer by first opening an image file (such as a JPEG file) in the MPC-HC and then downloading the snapshot of it generated by going to the "hidden" URI /snapshot.jpg.

  1. Make a GET request to, for example, http://<ip-address>:<port>/browser.html?path=C:\Users\joe\Pictures\kitten.jpeg
  2. kitten.jpeg is displayed by MPC-HC on the target machine
  3. Download the snapshotted kitten.jpeg from http://<ip-address>:<port>/snapshot.jpg

It is trivial to write a script that spiders the users filesystem looking for image files, launches them in MPC-HC, and then takes a snapshot of them. See the attached video and Python script for a quick PoC. Note that the Python script attached takes 2 arguments; host and username, while the one in the PoC video has the username hardcoded.

Regards,
Andreas

Attachments (1)

get_pics.py (673 bytes) - added by addelindh 23 months ago.
PoC attack script

Download all attachments as: .zip

Change History (33)

Changed 23 months ago by addelindh

PoC attack script

comment:1 Changed 23 months ago by addelindh

2 MB attachment size limitation, download the video from here instead:

http://www.filedropper.com/getpics

Regards,
Andreas

Last edited 23 months ago by addelindh (previous) (diff)

comment:2 Changed 23 months ago by addelindh

"and also to image content" should be "and also to steal image content". Sorry about that.

comment:3 Changed 23 months ago by kasper93

What do you suggest? Access to filesystem alone is pretty bad if we consider external access. WebUI was designed to be used in home network. Nowadays we have open wireless networks everywhere so it can be an issue.

One thing we could do is password protected access to WebUI. But this would not help for careless users who would enable WebUI without password.

comment:4 Changed 23 months ago by addelindh

Password protecting the WebUI would definitely be one solution, although I see your point about careless users. Perhaps a middle way would be to enable password by default and then give users the option to disable it, but to display a clear warning when this is done? Maybe also make listening on localhost only the default and display a warning when you enable an external listener?

Do you have any idea if the external listener is used a lot, or if localhost would do in most cases?

comment:5 Changed 23 months ago by thevbm

"Allow access from localhost only" should be enabled by default for starters indeed.

Later on, user/pass (#913) or something similar should be implemented.

comment:6 follow-up: Changed 23 months ago by kasper93

Do you have any idea if the external listener is used a lot, or if localhost would do in most cases?

For me listening on localhost beats the point. The idea is to give access to MPC-HC from remote location. And be able to control it, if you are on the same PC you can do it directly.

Perhaps a middle way would be to enable password by default and then give users the option to disable it, but to display a clear warning when this is done?

Default password is same as no password at all. Random generated password is not convenient.

I think best way would be to ask user for password when enabling WebUI. With short explanation why he should set it.

comment:7 in reply to: ↑ 6 Changed 23 months ago by thevbm

Replying to kasper93:

Do you have any idea if the external listener is used a lot, or if localhost would do in most cases?

For me listening on localhost beats the point. The idea is to give access to MPC-HC from remote location. And be able to control it, if you are on the same PC you can do it directly.

You're right @kasper93

Also i didn't think properly when i wrote what i wrote :)

I had in mind limiting not to localhost by default but on same local network if that's easily doable.

@addelindh
Kinda yeah, external listener is used via 3rd party apps that control MPC-HC. Common use is via android/ios apps.

comment:8 Changed 23 months ago by underground78

For me listening on localhost beats the point. The idea is to give access to MPC-HC from remote location. And be able to control it, if you are on the same PC you can do it directly.

It would make sense to replace this option by something that would limit access to the local network.

I'm not sure user/password is such a good idea, it will completely break existing applications and people will just turn it off so that it works again.

comment:9 follow-up: Changed 23 months ago by underground78

I just had a look and it's pretty easy to modify said "localhost" feature to accept IP from a private network as defined by RFC 1918. Do you think it would be enough?

Another solution would be to use a whitelist option, enabled by default and pre-populated with the private IP ranges from RFC 1918.

comment:10 in reply to: ↑ 9 Changed 23 months ago by addelindh

Replying to underground78:

I just had a look and it's pretty easy to modify said "localhost" feature to accept IP from a private network as defined by RFC 1918. Do you think it would be enough?

Another solution would be to use a whitelist option, enabled by default and pre-populated with the private IP ranges from RFC 1918.

Restricting access to RFC1918 addresses only would protect against over-the-internet attacks, but not against attacks on open WiFi like Starbucks, or an airport. The latter is by far the biggest threat, as most users browse the internet from behind a NAT device and are not directly reachable from remote anyway.

From a security point of view, some kind of authentication would be the most obvious solution but you guys/gals probably know your user base and their requirements way better than me so...

I was brainstorming with myself about some kind of device-based whitelisting, where you'd have to approve a device locally the first time it connected to the WebUI, but that's tricky if you're dealing with 3rd party apps. I guess you could do it based on MAC address, although MACs are easily spoofed. Also, you're only using HTTP so a cookies could easily be intercepted on open WiFi anyway.

Tricky situation this...

Last edited 23 months ago by addelindh (previous) (diff)

comment:11 follow-up: Changed 23 months ago by underground78

Well it's very difficult to protect people if they connect to open networks as if they were on a home network. :/

The other solution I thought about was to have some kind of notification on the first connection and let the user allow or disallow the remote access. Problem is people will be soon pissed if they have to accept the connection every time MPC-HC is reloaded. However if we whitelist the IP permanently we can never be sure that we are still on a safe network next time we get an incoming connection. Using the MAC address instead of the IP should be safer, it would take some spying on the user home network to be able to know the MAC address of the device used to control MPC-HC.

The good thing with this solution is that it can work quite easily with already existing app.

comment:12 in reply to: ↑ 11 Changed 23 months ago by addelindh

Replying to underground78:

Using the MAC address instead of the IP should be safer, it would take some spying on the user home network to be able to know the MAC address of the device used to control MPC-HC.

Assuming someone isn't controlling the MPC running on their laptop with their phone while on open WiFi, I agree. Please note that retrieving a MAC address while on the same network is trivial though, for example by using ARP ping. (http://en.wikipedia.org/wiki/Arping)

comment:13 Changed 23 months ago by underground78

Assuming someone isn't controlling the MPC running on their laptop with their phone while on open WiFi, I agree.

Well it doesn't really seem so likely...

If we all agree on this MAC-based authorization, the harder part will be to correctly implement that UI wise. The notification can happen at any time when the web interface is enabled which isn't so easy to handle. Also it should be visible, easy to interact with but not too intrusive.

Another solution would be to force the user to manually associate MPC-HC with a device, for example using a button from the option panel. I doubt it would make our users happy though...

comment:14 Changed 23 months ago by addelindh

Do you have any idea how long it will take to do something about this?

comment:15 Changed 23 months ago by underground78

Well it could be quite quick if we were sure of the solution to go with.

comment:16 Changed 23 months ago by addelindh

Of course. :)

Please let me know once you decide on a solution, I'm planning to include this in a blog at some point (us security people will do anything for some attention).

comment:17 Changed 23 months ago by underground78

  • Cc underground78 added
  • Evaluation set to diagnosed
  • Priority changed from normal to high
  • Severity changed from normal to blocker
  • Status changed from new to evaluated

comment:18 Changed 22 months ago by addelindh

Any progress?

comment:19 Changed 22 months ago by underground78

  • Cc xhmikosr added

@XhmikosR: We really need to make a decision about this. All solutions have pros and cons of course. The MAC-based authentication seems relatively safe while being non-disruptive for the existing apps.

comment:20 Changed 22 months ago by EtohRedux

How about adopting a three-pronged solution:

1) As the main means of security require a password. This would be done in a way that mitigated against password sniffing and brute forcing.

2) For backwards compatibility, allow for MAC-based exceptions to the password requirement.

3) To reduce the potential impact from unauthorised access and allow for more granularity of authorised access, allow users to specify a media folder (or media folders), and external access will be restricted to those folders (as recently requested by Lolipo on #mpc-hc).

Last edited 22 months ago by EtohRedux (previous) (diff)

comment:21 Changed 22 months ago by underground78

1) I'm not sure how you want to prevent password sniffing since we are using HTTP. We can easily mitigate against brute forcing by banning IPs after a certain number of failed authentication.

2) How do you see this? If a device attempts to connect without authenticating, prompt the user on whether it should be white-listed (permanently?) or banned?

3) This should not be a problem.

comment:22 Changed 20 months ago by addelindh

Any news regarding when this can be fixed?

comment:23 Changed 20 months ago by addelindh

Hi again. Still no news I gather?

This upcoming Monday, it's been 90 days since I reported this. 90 days is (in the security community) seen as sort-of a generic time period for how long it should take for a security bug to be fixed from when it was reported. I have no problem waiting before disclosing it (then again, this list is public), but it would at least be nice to know when you think it can be fixed. :)

comment:24 Changed 20 months ago by underground78

Well we honestly cannot tell. We are understaffed and nobody has time to look into this more closely. We could probably add some options to restrict access to the LAN and maybe add optional basic auth. However you seem to think it's not enough. Adding some auth mechanism based on the MAC address would need more UI work to have a proper integration but again you seem to think it's too easy to bypass.

The only solution I see would be optional https auth but I don't see that happening any time soon.

You have to understand that the web interface is disabled by default and by definition enabling it means opening an access to your computer. Although I understand that it's not perfect and could be improved, one has to remember it was never meant to be used outside of a properly protect LAN.

comment:25 Changed 20 months ago by addelindh

OK, I understand your situation. Would you like me to keep my mouth shut about it for the time being?

comment:26 Changed 20 months ago by underground78

Well this is public already so I'm not sure what you mean.

comment:27 Changed 20 months ago by armada651

Password protecting the WebUI is going to take some work, however just removing the snapshot feature from the UI is pretty easy. It wasn't exposed in the web interface anyway, so how about we just remove it for now?

comment:28 Changed 20 months ago by clsid2

Apps may use snapshots for showing a preview. So perhaps make it optional?

I would suggest adding an option to restrict file system access to a user defined list of folders (and their subfolders).

comment:29 Changed 20 months ago by underground78

Apps may use snapshots for showing a preview.

That's how it's used in our web UI at least. I guess disabling this by default could be a solution.

@addelindh: Would you say this is a good enough solution for now?

Last edited 20 months ago by underground78 (previous) (diff)

comment:30 Changed 20 months ago by Underground78 <underground78@…

  • Owner set to Underground78 <underground78@…>
  • Resolution set to fixed
  • Status changed from evaluated to closed

In a2548a:

Web interface: Add an option to disable the preview.

This option is disabled by default since it needs to be used with caution.

Fixes #5411.

comment:31 Changed 20 months ago by underground78

  • Milestone set to next release
  • Owner changed from Underground78 <underground78@… to underground78

Will be in the nightly build as of version 1.7.9.141.

I might add the folder restriction option before the end of the week.

comment:32 Changed 17 months ago by thevbm

  • Milestone changed from next release to 1.7.10

Milestone renamed

Note: See TracTickets for help on using tickets.