The other day, a rather interesting browser “exploit” came to my attention, which utilizes the WebRTC technologies available in modern browsers (used for things like Google Hangouts, and is generally the de facto standard for any peer to peer streaming technology). I call it an exploit because of how it handles virtual interfaces, specifically when it comes to VPNs. The short version?

If you use a WebRTC-enabled browser on a Windows system, your actual public IP can be exposed in Javascript.

When I say “actual public IP”, I mean “the IP address that a VPN should be hiding”. Additionally, I’ve replicated this on a number of Windows machines in Firefox and Chrome (not IE), but friends tell me that the public IP addresses don’t reliably show up on Mac/*NIX platforms.

Curious if you’re affected? Here’s a test.

So why does this happen?

First of all, “STUN” (Session Traversal Utilities for NAT) is a protocol that, as the name might suggest, is designed to expose the public IP address for a machine hidden behind Network Address Translation (how most consumer networks work; if you have a 10.x.x.x or 192.168.x.x IP address on your local machine, you’re behind NAT). STUN requests from the browser (currently), since they are integral to the implementation of a co-protocol (in this case, WebRTC), are executed directly against the network, rather than being pushed through the “normal” channels (which could be blocked by a plugin and/or seen in the developer console of either browser).

The “exploit” works by generating a dummy data channel request via WebRTC and creating an SDP (Session Description Protocol) offer from the browser. It submits the SDP (which, up to this point, does not have any IP information associated with it, as it hasn’t left the browser) by “changing” the SDP for the WebRTC session, which forces the request to be submitted by the browser and resolve the IP addresses. This updates the Javascript object with the updated SDP’s IP address information, which is now accessible to any locally running scripts.

One thing I’ve seen is that when using technologies like “VPN Kill Switch”, this *can* but won’t *always* fix the problem. VPN Kill Switch removes the gateway address from your non-virtual network interface, which in some of the tests seems to remove the “actual public IP” from the list of detected IP addresses. However, it is unclear whether this is a result of the test methodology or if it actually eliminates the issue.

In the meantime, I suggest using Mozilla Firefox, as Chrome doesn’t currently have the ability to disable WebRTC; there is a plugin for it but it works sporadically if at all.

To disable WebRTC in Firefox:

1. Open Firefox and navigate to about:config — Accept the warning dialog if necessary.
2. Type “media.peerconnection.enabled” into the search bar
3. Select the item with that name, change the value to “false”
4. Restart Firefox
5. Run the linked test above again to verify