

Excuse Me Sir, Your WebRTC Is Leaking - Golgi_SDK
http://blog.golgi.io/excuse-me-sir-your-webrtc-is-leaking

======
diafygi
Relevant Firefox bug:
[https://bugzilla.mozilla.org/show_bug.cgi?id=959893](https://bugzilla.mozilla.org/show_bug.cgi?id=959893)

My test: [https://diafygi.github.io/webrtc-
ips/](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.

~~~
Udo
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).

~~~
diafygi
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).

~~~
toonse
Even if you have the SafeScript and WebRTC extensions installed in Chrome? (no
settings changed). That combo passed every online test I could find.

------
algorithm_dk
I made a LAN scanner based on this in JS:
[http://algorithm.dk/lanscan](http://algorithm.dk/lanscan)

~~~
ryanseys
Very cool. I ran this on my laptop connected to my school's WiFi network and
found 65 alive hosts.

~~~
DanBC
You need to be very careful about what you do on other people's computers.
Make sure you get permission and are able to explain what you're doing.

------
jjbiotech
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.

~~~
softdev12
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.

~~~
0x0
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.

~~~
jusssi
How many guesses would you need for typical NAT gateway LAN side IP?

I'd say two.

------
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.

~~~
arkitectual
The problem is that in order for WebRTC to work correctly for all use cases
all local IPs must be sent to the remote client.

One example would be if you happened to use WebRTC with two peers on the same
VPN.

~~~
juberti
We have added an initial solution for this issue in Chrome 42. Users can set
the following preference:

"webrtc": { "multiple_routes_enabled": false },

For the location of the prefs file, see
[http://www.chromium.org/administrators/configuring-other-
pre...](http://www.chromium.org/administrators/configuring-other-preferences).

This forces all WebRTC connections to only use server-reflexive and relay ICE
candidates, and only on the default IP route. While this may cause a QoS hit
(two users behind NAT can no longer keep their traffic internal to the NAT),
it does allow the issue mentioned here to be fully addressed without disabling
WebRTC altogether.

~~~
Golgi_SDK
Thanks very much for your reply. I've been trying to enable the preference in
Google Chrome Canary on Mac OSX. However, I haven't been able to successfully
block the IP leak - I suspect because I haven't configured it correctly. I had
to manually create the file "/Library/Google/Google Chrome Master Preferences"
and add the setting you suggested. I then reinstalled Chrome Canary and tested
but no effect. I also tried editing the user preferences file in
~/Library/Application\ Support/Google/Chrome\ Canary/Default/Preference but
that seems to be overwritten by the browser. How should I be configuring this
preference? Thanks again.

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

~~~
echeese
Why would you want to disable STUN requests? Wouldn't they just return the
public-facing IP that the server already knows about?

~~~
0x0
Did you even read the article and click the demo link? :)
[https://diafygi.github.io/webrtc-ips/](https://diafygi.github.io/webrtc-ips/)

~~~
echeese
Yeah, but you don't even need a stun server for that. The browser itself
provides the local IP addresses.

~~~
0x0
Oh, I thought it had to read them back from the STUN server negotiation
because of javascript limitations.

------
echeese
Flash has been able to do this for years: [https://tools.ietf.org/html/draft-
thornburgh-rtmfp-flash-02#...](https://tools.ietf.org/html/draft-thornburgh-
rtmfp-flash-02#section-5.3.3)

 _The "setPeerInfo" command is sent by the client to the server over the
NetConnection control flow to inform the server of candidate socket addresses
through which the client might be reachable. This list SHOULD include all
directly connected interface addresses and proxy addresses except as provided
below. The list MAY be empty. The list need not include the address of the
server, even if the server is to act as an introducer for the client. The list
SHOULD NOT include link-local or loopback addresses._

~~~
marquis
Flash can be blocked, or not installed. If you are running a modern Chrome or
Firefox, there is no way to stop this from running. (edit: apparently you can
now block WebRTC entirely in Firefox, but Chrome has to be recompiled)

~~~
tracker1
I wish chrome had an advanced configuration interface similar to firefox's for
this kind of thing... I'm actually surprised WebRTC doesn't at least prompt
for access, similar to location, camera and similar requests.

------
softdev12
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, sacrificing
a prompt that grants an IP detection notice seems like a worthwhile tradeoff.

Also, I think webRTC is still in draft form and is still being modified in
working sessions (although I'm not 100% sure of this). It would be great if
Apple would get on board with webRTC for ios.

~~~
Golgi_SDK
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

------
jakub_g
WebRTC can also be used for fingerprinting (apparently Chrome only) in a
similar way as cookies. [1] has an explanation and test of it, as well some
other fingerprinting methods.

[1] [https://www.browserleaks.com/webrtc#webrtc-device-
id](https://www.browserleaks.com/webrtc#webrtc-device-id)

~~~
juberti
These ids work just like cookies; scoped to each user and origin. If you clear
cookies, the ids are cleared as well.

------
toonse
The comments in the Chrome WebRTC extension say to use ScriptSafe along with
WebRTC. If you do that it works great.

------
eugeneionesco
This is known for years, unbelievable how many people still exploit this for
page clicks.

