Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excuse Me Sir, Your WebRTC Is Leaking

blog.golgi.io

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Excuse Me Sir, Your WebRTC Is Leaking

#11

Post by Golgi_SDK »

softdev12 wrote: post #8

This is interesting and seems to indicate that there is a small edge case for people who want as much privacy as possible. The larger topic for me is that webRTC has to make tradeoff for developers. And, I for one, love what it does. If you look at legacy comms development in the peer to peer space (e.g. Skype) the process was orders of magnitude more difficult than using a webRTC implementation. So, as a developer,…

I agree that WebRTC is very powerful and makes peer-to-peer communication from browsers easily accessible for developers. And I also love what it does. However, the issue raised in the post is seen from the point of view of the user. Convenience for the developer probably won't be a concern to a user who is concerned about IP leakage. Yes, the WebRTC API is still being standardised so perhaps this issue will be addressed in future

Re: Excuse Me Sir, Your WebRTC Is Leaking

#12

Post by mikeash »

AdrianRossouw wrote: post #5
0x0 wrote: post #2

Interesting, maybe browsers should add a permission prompt like they do for web camera access before allowing a webrtc stun request?

i was under the impression it already does.

Doesn't look like it. The LAN scanner in another comment didn't put up any prompts for me. It might look like it does because WebRTC is normally used with audio or video, which does require a prompt, but you don't have to use it that way.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#13

Post by 0x0 »

softdev12 wrote: post #7
jjbiotech wrote: post #3

Vulnerability doesn't seem like the correct word to describe this issue. It's more of an exposure of potentially sensitive information (your local IP address if you're using a VPN) as a result of WebRTC's protocol design.

I agree. For the vast majority of use cases, this doesn't seem to be an exceptionally big issue. Almost all major websites collect IP addresses and don't explicitly prompt the user that this is happening. It seems the OP is really highlighting the edge case for users who want quasi-absolute security.

Knowing the LAN IP behind any NAT is useful for silently launching behind-the-firewall cross-site attacks against the router web admin interface (or any other local services) via a browser, without having to blindly guess addresses. Someone posted a POC LAN scanner elsewhere in a thread here, too.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#15

Post by JoshTriplett »

It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads?

That said, long-term, I think networks need to stop treating non-routability alone as a firewall mechanism. Any information that this WebRTC mechanism reveals could also be exploited by any random client application, or in the case of http-based protocols, by anyone who can embed an iframe or submit a form. Consider how you'd design a network in which every device had a routable IP address, and go ahead and design it that way anyway as a defense-in-depth measure. Use encrypted and authenticated protocols even on your "private" network.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#16

Post by diafygi »

Relevant Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=959893

My test: https://diafygi.github.io/webrtc-ips/

The main two issues are that a data connection doesn't require user consent (unlike video/audio) and the browser checks all network interfaces as connection candidates (so VPN users on Windows and Mac expose their real IPs). As I proposed in the bug, if we fix those two things, we would be a lot better off.

Re: Excuse Me Sir, Your WebRTC Is Leaking

#18

Post by Udo »

diafygi wrote: post #16

Relevant Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=959893 My test: https://diafygi.github.io/webrtc-ips/ The main two issues are that a data connection doesn't require user consent (unlike video/audio) and the browser checks all network interfaces as connection candidates (so VPN users on Windows and Mac expose their real IPs). As I proposed in the bug, if we fix those two things, we would be a lot be…

A quick heads-up:

  These requests do not show up in developer consoles and 
  cannot be blocked by browser plugins
I'm using FF with a WebRTC-blocking plugin, and it does successfully block the proof-of-concept exploit (it's called "Happy Bonobo Disable WebRTC", an admittedly shady name, but there are surely others).

Re: Excuse Me Sir, Your WebRTC Is Leaking

#19

Post by diafygi »

Udo wrote: post #18
diafygi wrote: post #16

Relevant Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=959893 My test: https://diafygi.github.io/webrtc-ips/ The main two issues are that a data connection doesn't require user consent (unlike video/audio) and the browser checks all network interfaces as connection candidates (so VPN users on Windows and Mac expose their real IPs). As I proposed in the bug, if we fix those two things, we would be a lot be…

A quick heads-up: These requests do not show up in developer consoles and cannot be blocked by browser plugins I'm using FF with a WebRTC-blocking plugin, and it does successfully block the proof-of-concept exploit (it's called "Happy Bonobo Disable WebRTC", an admittedly shady name, but there are surely others).

Yes, most of those plugins were made after this test was created. This one just sets "media.peerconnection.enabled" to false in Firefox's settings. However, it means you have to disable WebRTC entirely, not just the STUN requests.

Unfortunately, Chrome doesn't let you disable WebRTC at all unless you recompile with "-Denable_webrtc=0", and Chrome blocking plugins are easily bypassed (see some pull requests in my repo).

Post reply on HN