It has recently been reported that an API called WebRTC can be exploited to discover your machine’s public and local IP addresses. If you haven’t heard of it WebRTC (or Web Real-Time Communication) is an API that allows peer-to-peer voice and video calls as well as data transfers between browsers. WebRTC is currently supported on Chrome, Firefox and Opera (which as of December 2014 accounts for 86.8% of all browser use) which means a huge number of browsers could be vulnerable. But what is the cause of this vulnerability?


To understand the vulnerability lets look first at how WebRTC works. WebRTC transmits data over UDP with DTLS. In the short version each browser binds an IP address and port on which it will receive data. The other browser is then notified of this binding and can begin transmitting packets towards it.

In the long version it isn’t quite as simple as that. WebRTC is attempting to create a peer-to-peer connection. Ideally this would be between two browsers on a single network – in which case the devices local IP address should be bound. But the world of IP connectivity is far from ideal. In many cases the two browsers will be on different networks and likely separated by NAT (Network Addresss Translation) network entities – in which case the devices public IP address should be bound. Worse still is when your browsers are separated by a symmetric NAT – in which case the IP address of a relay server should be bound.

These latter two cases fall into an area of networking known as NAT traversal. It is achieved in WebRTC by utilising three related network protocols STUN (Session Traversal Utilities for NAT), TURN(Traversal Using Relays around NAT) and ICE (Interactive Connectivity Establishment). The three protocols work together to gather IP addresses (and ports) that allow NAT traversal.

The IP address and port bindings (known within WebRTC as ICE candidates) are then transmitted to the other browser. A signaling layer that would transmit the ICE candidates is not part of the WebRTC API, however. In fact it is up to the developer to implement a signaling layer for this (and other related) setup transmissions. This means that the ICE candidates must be passed to the developer through the APIs JavaScript interface. And it is at this point that a developer can get access to your local and public IP addresses.

The WebRTC API calls necessary to gather this information can be run without any user interaction or knowledge. Furthermore, the requests necessary to gather your IP addresses do not even result in console logs. To see an example of the exploit at work you can check out a demo put together by Daniel Roesler at If your browser supports WebRTC and you have JavaScript enabled you should see you local and public IP addresses appear.

What’s the problem?
What security issues will I face due to these leaked IPs? I should preface this section by saying that exploiting users identifying data is not one of my areas of expertise. But with that in mind let’s look at what for me is the most pressing security concern.

As we said WebRTC will gather all IP addresses where you are available as part of it’s connection establishment. These will include not only your real local and public IPs but also any IPs associated with a VPN that you may be using. VPNs are used for a wide range of security issues. However, one particular use is for anonymity. If my real local and public IP addresses as well as my VPN local and public IP addresses are exposed it becomes that little bit easier to deanonymise me.

Can I fix it?
Short term there are some steps that you can take. On Firefox you can type “about:config” into the address bar to access Firefox settings. Find the setting “media.peerconnection.enabled” and set it tofalse. Of course this will mean that any website legitimately trying to use WebRTC will not be able to so you may have to toggle the setting.

On Chrome you can access a similar settings menu by typing “chrome://flags” into your address bar. There is a “Disable WebRTC” option but it is only available on Android and not on Chrome’s desktop offering.

Edit: A solution to the problem was added in Chrome version 42. Thanks to Justin Uberti and Guowei Shieh for letting us know about the fix. A preference has been added that disables the use of local IPs in WebRTC. To enable this preference you will have to edit your Chrome user preference file. You will also have to use Chrome’s Canary version as the latest stable Chrome version (on Mac OSX at least) is 40. Quit Chrome Canary and edit your preference file (~/Library/Application\ Support/Google/Chrome\ Canary/Default/Preferences) and add the lines:

"webrtc": { 
    "multiple_routes_enabled": false 

now restart Chrome Canary and WebRTC should no longer use local IPs. You can check you’ve configured it correctly using the exploit demo linked earlier in the post. This time only your public IP address should be listed.

Long term the ideal solution would be to have a user prompt whenever a WebRTC connection is being requested. This would be similar to the prompt requesting a user to authorise access to the camera and microphone. However, this solution relies on such a mechanism being mandated in the specifications and implemented by your browser provider.

ShareShare on Facebook0Share on Google+5Tweet about this on TwitterShare on LinkedIn0
Back to Articles

Leave a Reply