A recently publicized hole in WebRTC, a protocol for web communication, is revealing the local IP addresses of users, even those who go to extra lengths to hide theirs by using a virtual private network.
Daniel Roesler, a San Francisco-based researcher who’s dabbled in encryption, posted a demonstration on GitHub last week to illustrate how the vulnerability works.
Roesler’s proof-of-concept shows how websites make requests to STUN servers. STUN – or Session Traversal Utilities for NAT, servers – send a ping back that contains the IP address and port of the client–from the server’s perspective. The local and public IP addresses of the user can be gleaned from these requests via JavaScript.
While researchers have suspected since WebRTC’s inception that the protocol could be used to reveal local IP addresses, Roesler’s slick proof-of-concept outlines a potential security and privacy consequence that’s become more fully realized over the past several months as browsers continue to adopt the technology.
Perhaps more alarming, Roesler claims that users who implement adblockers can’t prevent the STUN requests from getting made, as they go outside the normal request procedure.
“These STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery,” Roesler wrote on his Github page.
Many privacy-conscious users use plugins like AdBlockPlus and Ghostery, in addition to accessing the internet via proxies and VPNs to keep their IP addresses shrouded in secrecy. It could be reasoned that the hole bypasses much of the premise of using a VPN.
On top of that Roesler claims that users should be concerned of advertisers taking advantage of the flaw.
In his GitHub post Roesler writes that if an advertiser were to set up a STUN server with a wildcard domain, they could make these sort of requests available for online tracking, something that could lead to a mess of additional issues and make it even easier for advertisers to identify users.
For the moment, because of the way WebRTC is deployed, the issue is mainly affecting users who run either Google Chrome or Mozilla Firefox on Windows.
Users can disable WebRTC in either browser, however. Firefox users can type “about:config” in the browser’s address bar and then set “media.peerconnection.enabled” to false, while Chrome users can enter “chrome://flags/” into the browser’s address bar and enable “Disable WebRTC device enumeration.”
There are also plugins, including the WebRTC block extension or ScriptSafe for Chrome and NoScript for Firefox, that mitigate the vulnerability.
WebRTC, or Web Real-Time Communication, is an open-source project supported by Google primarily used for browser-to-browser communication, voice calling, video chat, and so forth. The HTML5 protocol, which is really more of an API directory, reduces the need for multiple plugins and was most recently deployed alongside the Firefox Hello client in Firefox 34. Google first began integrating WebRTC into Chrome way back in 2011 but it wasn’t until this past summer that some of its apps, like Hangouts, fully embraced the platform.
It’s unclear if the issue will ever get addressed by Google, or if it’s an inherent design flaw that users will have to address on their own. Google did not immediately respond to a request for comment on Monday.
