webRTC browser IP leak fix via Windows Firewall

[Pattern_Juggled]

{direct link: cryptostorm.ch/stunner}
UPDATED: moved to a port-based approach 9 Feb 2015; crossposted to github, & onsite echo.


We've implemented a client-side solution to this Windows leak, which has just recently been posted.

NOTE that one must have Windows Firewall enabled on the local machine for this patch to function (h/t, again, @KaganKongar). If WF isn't your preferred firewall setup, feel free to port these rules into whatever you use - and if you think to report back here or in the github repository on the rules you develop, that'd be helpful for others doing the same. Thanks.

As kongar noted, the problem isn't so much the webRTC protocol itself as the fact that the Windows kernel consistently leaks UDP packets carrying the protocol's payload outside of the virtual NIC & thus encrypted tunnel. That means both that they're not able to be nullrouted simply by "catching" them as they show up at cryptostorm exitnodes (for example) - since the leaked packets don't follow that routing pathway - and that they're difficult to squash with some conventional packet management tools given that they're already "out-of-pocket."

Turns out there's a small number of STUN servers used by Firefox and Chrome for these lookups. With the help of a hefty pack of friends and fellow investigators on twitter today (full details in the opening post at our new blog: cryptostorm.is/bloggy (we also pointed kfuckoffnow.com at it because it was sitting around and... why not, really?)

Here's the whittled-down final script to implement the needs packet filtering rules on Windows to ensure none of these packets get off the machine. It requires no fiddling with browsers, adding extensions that may or may not work consistently, etc.

[quote]@echo off
::save as a .bat file, run as administrator
::then visit https://diafygi.github.io/webrtc-ips/ to verify
::no more public IP leaking
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=out action=block protocol=UDP localport=3478
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=out action=block protocol=UDP remoteport=3478
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=in action=block protocol=UDP localport=3478
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=in action=block protocol=UDP remoteport=3478
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=out action=block protocol=UDP localport=19302
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=out action=block protocol=UDP remoteport=19302
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=in action=block protocol=UDP localport=19302
netsh advfirewall firewall add rule name="No STUN leak for j00!" dir=in action=block protocol=UDP remoteport=19302[/quote]
(yes, the emoticon is in df's pushed-to-production script - it's not an unintended render...)

And, lastly, we striped in a little workspace at github both to help in collecting & de-duplicating the STUN addresses, and to publish the above-quoted script so it's easily accessible for anyone who decides to build on it, expand it, etc.

• github.com/stunner

Thanks again to everyone who helped us out with this today, and we hope this unassuming bit of script-fu helps keep folks safe.

Cheers,

~ df & pj

[marzametal]

How to handle this via Android custom ROM? ...or is it up to the Developer to handle it?

...maybe a bit of help in creating a custom script for AFWall+ ?

[steely_glint]

I fear that doesn't really fix the problem.
1) The attacking web page can point to their own stun server in their version of that page

eg: {iceServers: [{urls: "stun:stun.me_evil.com"}]}

2) I'm not convinced that webRTC needs (or uses Stun) when it discovers local IP addresses,
all it has to do is the C equivalent of ifconfig.

[Pattern_Juggled]

I fear that doesn't really fix the problem.
1) The attacking web page can point to their own stun server in their version of that page

eg: {iceServers: [{urls: "stun:stun.me_evil.com"}]}

This is an interesting observation, and I don't think we can respond with any confidence until we look a bit closer at the implementation details... but given your expertise in these matters, it's more likely than not that you've raised an important point.

Nothing we saw in our in-house testing suggested that pages could specify arbitrary STUN server values... but, then again, I can't point to any code snipped that explicitly prevents it at this point. It would seem reckless in the extreme to me, as a network-level workhouse, to have applications that can do things like that... but that's not my world, so what do I know about the general trends? Not much - hence the need to review specific code for specific logic or lack thereof.

Do you think there's any input validation on what "STUN server" a webpage can ask a browser to send UDP packets to? Must they even be UDP? Silly I know... but one wonders how deep that rabbit hole goes.

2) I'm not convinced that webRTC needs (or uses Stun) when it discovers local IP addresses,
all it has to do is the C equivalent of ifconfig.

This... pretty well chills me to my bones. If both points 1 and 2 validate, then it means any webserver can request of any browser - irrespective of presence or absence of webRTC or any other protocol suite - the most intimate details of its local affairs... this certainly drifts close to being a form of remote privilege escalation in act if not in formal name. I'd certainly not want strangers ifconfig'ing boxes in our network as they see fit - and if this isn't protocol-limted in scope, then that's essentially what's taking place.

I suspect you've more than a hunch about this C-based netstack query. Care to share further details, when you have a moment?

Thanks for contributing your knowledge here - it's invaluable.

Cheers,

~ pj

[steely_glint]

Do you think there's any input validation on what "STUN server" a webpage can ask a browser to send UDP packets to?

None that I'm aware of - but there are strict rules on how often those packets are sent,
the javascript has no control over the content and only gets notified when a valid STUN reply has been seen (e.g. the javascript can't swamp a machine by throwing lots of STUN packets at it, you can't know if there is a machine there or not unless it replies and you can't craft up buffer overflow attacks by messing with what is in the STUN packets). There is a good discussion of these issues here : https://tools.ietf.org/html/draft-ietf- ... tion-4.2.4 .

I'd certainly not want strangers ifconfig'ing boxes in our network as they see fit - and if this isn't protocol-limted in scope, then that's essentially what's taking place.

Sorry, that really wasn't what I meant at all. I was trying to say that there are perfectly good C api's for discovering a local
interface's ip addresses that don't need to fling packets around, webRTC will use them.

On the good news front, Chromium filters the IPv6 addresses returned to prefer the 'temporary' which should prevent the one that is derived from the mac address from being leaked on OS's that support this feature. https://code.google.com/p/webrtc/issues/detail?id=3808

[bricky149]

Just a heads-up, WebRTC still leaks for me on CStorm, disabled PeerConnection in Firefox for now. Not a big deal.

[Pattern_Juggled]

Just a heads-up, WebRTC still leaks for me on CStorm, disabled PeerConnection in Firefox for now. Not a big deal.

This is one of those blindingly-obvious things in hindsight, but our block won't work unless Windows Firewall is enabled on the machine. I know of many folks who disable WF, so I think this is not entirely uncommon.

If that's not what explains your report, we'd like to get a bit more detail from you so we can track down what's allowing the packets to get by. Let us know, ok?

Thanks,

~ pj

[bricky149]

Just a heads-up, WebRTC still leaks for me on CStorm, disabled PeerConnection in Firefox for now. Not a big deal.

This is one of those blindingly-obvious things in hindsight, but our block won't work unless Windows Firewall is enabled on the machine. I know of many folks who disable WF, so I think this is not entirely uncommon.

If that's not what explains your report, we'd like to get a bit more detail from you so we can track down what's allowing the packets to get by. Let us know, ok?

Thanks,

~ pj

Windows Firewall was disabled so it's me who's at fault. Enabled and working as expected.

[bricky149]

Windows Firewall was disabled so it's me who's at fault. Enabled and working as expected.

Since it was disabled, I presume that you normally use some other firewall. If that's the case, why not just create an appropriate rule for it instead?

I do not use any security software (AV and firewalls anyway) apart from my router's firewall and the security that runs atop my shoulders. It hasn't let me down over the past 8 years.

[marzametal]

Been tempted to downgrade my products, things are starting to piss me off... lol

[Pattern_Juggled]

There's been a great deal going wrt webRTC we've not summarised in posts here in-forum in recent days; things have been evolving at a pace that makes such realtime updates a challenge... but we'll get some conclusive information posted by the end of the week. Much of what's going on is taking place realtime in our main twitter feed, with some very experienced community members helping us nail down fundamental concepts & craft responses. There's an equal amount of communication nonpublic/out-of-band, for reasons that will become clear in due course.

A few things about this Lifehacker article, which as I've just noted in twitter, passes along some serious misunderstandings about this issue. I know these guys at Lifehacker are making good affiliate money from PIA and Torguar, that's great for them... however confusing that cosy "pay to play" relationship for a marker of technical competence on the part of either of those less-than-competent "VPN services" is a serious error.

edited to correct: Alan has clarified in email that Lifehacker has no affiliate relationship with either Torguard or PIA. I assumed that was the case based on the wording of the article, and that assumption was incorrect. Rather than edit the text of the above paragraph, I'm leaving it - so my error can be noted and judged by others reading this post - and correcting that statement here in a follow-on edit. Thanks to Alan for the correction, and my apology for implying an affiliate relationship where none exists.

We're unable to reply in comments, as they are facebook-only and cryptostorm has a project-wide/team-wide policy of facebook avoidance that is not going to change. As such, we're replying here (also hoping for direct comms, via a request in our twitter account).

Down towards the most recent comments, the author of the article posts this:

Daniel Roseler, the author of the IP test page and the developer who revealed the issue emailed me this morning to clarify a couple of things, and I wanted to pass them along here in the discussions so everyone else could see them too:

FYI, this is not considered a flaw or security hole, which is why I published this demo publicly. This behavior in WebRTC is by design.

Also, whether or not your real IP is exposed when you're on a VPN appears to depends on the type of VPN software you have, not your browser. For example, if you use the default Mac OSX VPN setup, I will leak your real IP. But of you use an OpenVPN installation, it will not expose your real IP. I suspect a similar situation is true for Windows. I'm on Ubuntu, and the OpenVPN setup I use does not expose my real public IP.

That first bit is a big deal - we've been talking about this up to this point as though it's a vulnerability or a hole that needs to be patched, but because this is designed behavior in WebRTC, that means it's less likely developers will jump to correct its behavior. (I'm also going to go through the post and change some of my language away from "vulnerability" and "hole" as such.

Second, it's important to note that the type of VPN plays a role here, which explains how some people are getting inconsistent results even with the same VPN provider. If you're using an OpenVPN setup to connect to PIA, for example, and someone else is using the default OS X built-in VPN tools to connect to PIA, that would explain the difference. In fact, whether you're subject to this or not may say more about the VPN provider's software than it does about your browser, although we know that the act of passing along your IP takes place in browsers that have WebRTC built-in.

Anyway, good additional data, and I thank Daniel for writing in and sharing it with us!

The statement that "But of you use an OpenVPN installation, it will not expose your real IP" is simply empirically wrong. Anyone who assumes this is the case, and acts on that assumption, is extremely vulnerable to leakage.

Second, the "router-based installs will save you" fantasy is included higher up in the article:

The Better Way: Configure Your VPN on Your Router

If you want a more surefire way to protect yourself beyond installing add-ons and making tweaks to your browser every time you install or update, there is a more permanent method. Run your VPN at your router instead of on your computer directly.

I have absolutely no idea how people are able to come to the conclusion that tunnelling packets through a router-based VPN is going to stop a browser-based STUN/webRTC IP address leak... I've asked others who have repeated this statement to explain the theoretical mechanism that is supposed to be at play, at a packet-level perspective. I have not received any cogent reply to this question, thus far.

As such, anyone repeating this should perhaps provide router-level pcaps to validate that this "fix" actually works... or, at the least, repeatable results publication of website-test results both on-network (via) router, on-network (non-router), and off-net, in order to demonstrate empirical findings even if there is a lack of theoretical explanation or framework.

Meanwhile, I have no reason to conclude that encapsulating leaked webRTC UDP (or TCP) replies in a router-based tunnel will do anything except ensure those packets get back to the server sending the STUN query without being subject to surveillance along the way.

Cheers,

~ pj

[Fermi]

I'm on Ubuntu, and the OpenVPN setup I use does not expose my real public IP.

Tested this on Ubuntu 14.04.

• Using Network Manager, only the Cryptostorm IP is being leaked, not my real IP.
  Using openvpn, both Cryptostorm IP and real IP are leaked.

Difference between the two methods is the fact that Network Manager doesn't 'absorb' all configuration items out of the conf file, resulting in different behaviour (routing table).
So the method used to connect to the VPN is clearly influencing the result.
On Windows (7), I didn't notice a difference between widget (without the firewall scripts) and the OpenVPN method, both public IP's leaked

I'll try to contact someone who is using a router based setup (pfsense) and try to get pcaps. He/she indicated me that the real IP isn't leaking. Hopefully this will learn us more.

[Fermi]

Did some further tests, using pfsense.
pfsense setup:
WMWare running W7, bridged to the physical NIC (which is connected to a router, internet), both IPv4 and IPv6 are disabled on this interface within W7.
In addition, there's a loopback adapter installed, which bridges directly to the LAN side of a VirtualBox running pfsense on the W7 VMWare (virtual machine in virtual machine).
The WAN side of pfsense, bridges to the same physical as mentioned above.
As IPv4 and IPv6 are disabled the W7 doesn't have connection to the internet using the physical NIC.
pfsense is configured to connect to Turing, and route all outbound traffic of the W7 platform inside the tunnel.
What is leaking in this case?:

• internal IP's
  Cryptostorm IP

Flow Graph of communications on W7 lan interface:

webrtc_openvpn on pfsense - lan pcap workstation.png (7.32 KiB) Viewed 107064 times

Only binding requests! ... rest handled by tunnel interface on pfsense ... .

Flow Graph of communications on the pfsense OpenVPN interface:

VPN running on VMWare running W7 (connected to Onyx):
What is leaking in this case?:

• internal IP's
  my public IP
  Cryptostorm IP

Flow Graph of communications on W7 lan interface:

This is an indication that router based vpn setups are helpful in avoiding public IP leaks.
To capture Microsoft Loopback Interface packets, use rawcap (http://www.netresec.com/?page=RawCap)

/Fermi

[Guest]

I have absolutely no idea how people are able to come to the conclusion that tunnelling packets through a router-based VPN is going to stop a browser-based STUN/webRTC IP address leak... I've asked others who have repeated this statement to explain the theoretical mechanism that is supposed to be at play, at a packet-level perspective. I have not received any cogent reply to this question, thus far.

I lack the knowledge to dig into this stuff as you guys have- or provide much of a 'packet-level' perspective to my theory I'm afraid... so it's possible I have a significant misunderstanding of how rtc works, but here's my thinking- however wrong it may be; and please try and explain in somewhat plain language if it is...
Router based VPN is a protection because rtc runs on the computer, not the router, and the computers network stack has no authority over the router. If the router is setup properly, the vpn session is transparent and the computer will never be privileged with the knowledge of the native ip- it can't leak what it doesn't know. Instead it leaks what it does know, which is internal ip's to the router, and the vpn exit ip (which, being the first external ip it can *see*, is what it would belive IS the native ip.). I've not done p-caps (wouldn't know how tbh) on my dd-wrt based setup but I never witnessed a leak from the rtc tests, even with rtc enabled in browser. (is it flash dependant?) Traceroute from my system normally shows CS exitnode as the first non-internal ip. I"m also nat'd from the modem, and run a strict firewall if that makes a difference.

...So- I'm really intrigued- you're saying rtc CAN bypass router based vpn? how?

[Guest]

no matter how many ports/ips you block, more can allways be setup... why not just go whitelist on this? ...just block everything execpt UDP/DNS CS ip's.... could potentially help with more then just rtc then.

[Fermi]

Did some further experiments/tests, using a different approach than using routing tables ... .
Stumbled upon SNORT (https://www.snort.org/) ...

Snort is a free and open source network intrusion prevention system (NIPS) and network intrusion detection system (NIDS)[4] created by Martin Roesch in 1998.[5] Snort is now developed by Sourcefire, of which Roesch is the founder and CTO.[6] In 2009, Snort entered InfoWorld's Open Source Hall of Fame as one of the "greatest [pieces of] open source software of all time".

Must say that I'm rather impressed by this ... , also because:

Daily Ruleset Update Summary 2015/02/19

[***] Summary: [***]

11 new Open signatures, 22 new Pro (11 + 11). SuperFish, Win32.InstallCore, Bedep.

Thanks: pckthck and Jake Warren


[+++] Added rules: [+++]

Open:
2020479 - ET TROJAN Win32.Beaugrit.gen.AAAA (trojan.rules)
2020480 - ET TROJAN Trojan.NSIS.Comame.A Checkin (trojan.rules)
2020485 - ET EXPLOIT Possible dlink-DSL2640B DNS Change Attempt (exploit.rules)
2020486 - ET EXPLOIT Possible ShuttleTech 915WM DNS Change Attempt (exploit.rules)
2020487 - ET EXPLOIT Generic ADSL Router DNS Change GET Request (exploit.rules)
2020488 - ET EXPLOIT Generic ADSL Router DNS Change POST Request (exploit.rules)
2020489 - ET TROJAN SuperFish CnC Beacon 1 (trojan.rules)
2020490 - ET TROJAN SuperFish CnC Beacon 2 (trojan.rules)
2020491 - ET TROJAN Possible Bedep Connectivity Check (2) (trojan.rules)
2020492 - ET TROJAN SuperFish Possible SSL Cert CnC Traffic (trojan.rules)
2020493 - ET TROJAN SuperFish Possible SSL Cert Signed By Compromised Root CA (trojan.rules)

(http://www.emergingthreats.net/products ... 2015/02/19)

Ring a bell?

According to my humble opinion SNORT is worth investigating and can add added value when applied on the node?

Overview can be found here:

WebRTC STUN – SNORT rules - iptables.pdf

(174.07 KiB) Downloaded 2599 times

/Fermi

[Fermi]

fwsnort --ipt-drop --snort-sid 2016149,2016150

generates 'drop' rules ....

/Fermi

[Zim]

Welcome:
stun:146.148.121.175:443
turns:146.148.121.175:443?transport=tcp
turns:146.148.121.175:443?transport=udp
©
http://146.148.121.175:8080/webrtc-ips/
https://github.com/steely-glint/webrtc-ips

So, let's try block TCP+UDP 443 lol? (HTTP SSL? TLS? No, not heard)
And when you watched which ports are used by Hangouts (Google Talk), you forgot to read beyond the first one (which is a part of a whole region 19302-19309):
https://support.google.com/a/answer/1279090?hl=en

If someone still didn't understand: on your own server you can use any port which you want! RFC doesn't limit it.
So, what did you fix here? Sorry, but nothing.

[nostunner]

1. Change the default outbound rules for your zone (either home,work or public) from the default which is "allow" to "block"

From: https://technet.microsoft.com/en-us/lib ... s.10).aspx
"Default rules. These rules define the action that takes place when a connection does not match any other rule. The inbound default is to block connections and the outbound default is to allow connections. The defaults can be changed in Windows Firewall Properties on a per-profile basis."


2. Specify individual rules for outbound (e.g. allow all tcp, allow all windows services/dhcp/dns/time)

Now udp to stun servers from web browsers are all blocked (match default rule)

[df]

To zim: You're right, it is possible to use any port with a STUN server. Your best protection would be to use noscript to block all javascript, or use a local HTTP proxy like Proxomitron (or Privoxy) along with some scripting that removes any <script></script> blocks that contain the text stun: or turns: or any other protocol you don't want to support. We do this for torstorm users (since the WebRTC leak thing does work over .onion's), but we can't do this with VPN users without completely breaking SSL (more than it already is anyways :P).

[nostunner]

1. Change the default outbound rules for your zone (either home,work or public) from the default which is "allow" to "block"

From: https://technet.microsoft.com/en-us/lib ... s.10).aspx
"Default rules. These rules define the action that takes place when a connection does not match any other rule. The inbound default is to block connections and the outbound default is to allow connections. The defaults can be changed in Windows Firewall Properties on a per-profile basis."


2. Specify individual rules for outbound (e.g. allow all tcp, allow all windows services/dhcp/dns/time)

Now udp to stun servers from web browsers are all blocked (match default rule)

[nostunner]

More specific
1 Put your native network adaptor connection on a separate zone (Home/Work/Public) from your VPN connection.
That can be done in the "Network and Sharing Center".
2 Bring up Windows Firewall
3 Enable it.
4 Go to windows firewall configuration.
5 Change the Default outbound policy for the zone (e.g. public, private depends on your choice in 1) from "ALLOW" to "BLOCK"
6 Change "Protected Network Settings" to apply to the interface of your real internet connection.
7 Edit/Add the Outbound Rules, make sure "Core Networking" for DHCP,DNS,TIME etc are allowed in outbound rules. If you want windows update to work on that interface, you have to add rules to allow "Windows update" service and "BITS" service.
8 Add an ALLOW rule for your VPN client.
9 For any application that does not use VPN you add an "ALLOW" outbound rule.

[Clodo]

I do some research on WebRTC leak, if anyone is interested. Details here: http://redd.it/32d94q

[sysfu]

If you're forced to use Chrome for whatever reason you can block WebRTC leaks with the WebRTC Leak Prevent Extension

I also came across the manual method below posted here

08.01.2016 at 13:41
To deactivate WebRTC in chrome-Browser and clones you have to insert a code-line into the file “preferences” in user-directory:
,”webrtc”:{“multiple_routes_enabled”:false}
in front of last }

[marzametal]

For those who use AdGuard for Windows (the installer, not the browser addon)... this has the ability to block WebRTC at the network level.

If you do the usual check of your details as sites such as IPLeak, it will say that your IP is leaking, but this is not the case. It is just the fact that the browser has not had the specific reference blocked; eg: no IPs will be displayed, but the script will still run, returning null results.

[sysfu]

People seeking to solve the WebRTC issue with Firefox might try installing the 'Statutory' add-on.

I also found out about a privacy centric Mozilla fork known as Pale Moon which should also solve the problem. This project is recommended in the description for the Statutory add-on.