WebRTC vulnerability

[usr32 2]

I would also like to know which rules to set to Windows Firewall.

 

@Staff: I kindly want to ask if it is the best option to push redirect-gatway def1 server side for Windows clients. This was set to default since some OpenVPN version I have read. I am really not an expert in this matter. In the man it says for def1: "Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway." Are there any advantages in overriding the gateway instead of wiping it out? Without def1 the WebRTC vulnerabilty doesnt seem to affect people on Windows.

[knighthawk 19]

I would also like to know which rules to set to Windows Firewall.

 

@Staff: I kindly want to ask if it is the best option to push redirect-gatway def1 server side for Windows clients. This was set to default since some OpenVPN version I have read. I am really not an expert in this matter. In the man it says for def1: "Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway." Are there any advantages in overriding the gateway instead of wiping it out? Without def1 the WebRTC vulnerabilty doesnt seem to affect people on Windows.

 

One advantage is I can still get (specifically allowed) inbound traffic to my system over the non-vpn interface\connection.

So say like in a hosted environment my server has a vpn connection and by default all traffic is going to go out that vpn traffic path, but incoming connection that I have a rule allowing (for instance an RDP port) will come in on and travel back through the non-vpn interface\route.  This is quite handy, and I think without the original 0/0 DF route I'd have to come in over the vpn ip via a port-mapping.  Another might be so long as it isn't touching the 0/0 route should something get fubar'd with the vpn at least it's not removing your DF route, on a home system whatever...but on a remote system that could leave you in bad situation of lost connectivity.

 

 

Regarding NoDre's mention of rule and blocking FF using the non-vpn interface and requests for examples to accomplish that:

 

You can't truely prevent FF from talking to the interface, you can block it from using ip's related to that interface though.

Firewall rule related to blocking FF on a given IP.  {assuming your outbound ruleset default to block all not otherwise defined - this is not the default setting in say win7\srv2008r2}

Do a 'New' outbound rule, select 'custom', Program: "this program path" : <path to FF exe>, protocol|ports = any , scope:LocalIP=10.0.0.0/8 RemoteIP:Any Action: Allow, Name:AllowFFOnlyOnAirVPNIP

 

cmdline example:

Netsh advfirewall firewall set rule name="AllowFFOnlyONAirVPN" program="%ProgramFiles% (x86)\Mozilla Firefox\firefox.exe" dir=out protocol=any  profile=any localip=10.0.0.0/8 remoteip=any action=allow enable=yes

 

If you are not blocking outbound (default in WinFirewall) then for a deny rule you'd use the reverse specifying your local ip to block

 

Do 'New' outbound rule,select 'custom', Program: "this program path" : <path to FF exe>, protocol|ports = any , scope:LocalIP=<[localip(s)]x.x.x.x/32 RemoteIP:Any, Action: Block, Name:BlockFFOnLocal IP

cmdline example:

Netsh advfirewall firewall set rule name="BlockFFONLocalIP" program="%ProgramFiles% (x86)\Mozilla Firefox\firefox.exe" dir=out protocol=any  profile=any localip=192.168.201.11/32 remoteip=any action=block enable=yes

 

The above is just to give an idea, your own specific needs\case may vary, adjust accordingly. My own is I don't use NetworkLock, never will as it would screw with myown custom configs, and I don't want any webrtc functions to work (let alone be in the browser to begin-with) so I have no issue disabling it.

 

/2cents - not sure if it'll help anyone or just confuse peeps further.

[NaDre 157]

...

I would appreciate it very much if Staff & NaDre could educate me as to how to create the necessary rules to remove the offending routing and define the required events in Eddie to control that.

...

 

The firewall rule I had in mind is one for Windows, rather than Linux. For all of its shortcomings when compared to IPTABLES for Linux, one very nice thing about Windows Firewall is that you can easily place a restriction on a specific program.

 

The firewall rule that I use for this is very much like the ones I use to block my uTorrent clients from making outbound connections on the real interface. To see an example of this see the section "Rules for Outgoing Connections" in my guide about traffic splitting:

 

https://airvpn.org/topic/9549-traffic-splitting-guide-to-setting-up-vpn-only-for-torrenting-on-windows-thanks-to-nadre/

https://airvpn.org/topic/9491-guide-to-setting-up-vpn-just-for-torrenting-on-windows/

 

There are screen shots there.

 

Earlier sections in that guide explain how to obtain the IP address information that the set up needs. Instead of specifying a torrent client as the program, specify the firefox.exe program, which is normally in "C:\Program Files (x86)\Mozilla Firefox" for 64 bit or in "C:\Program Files\Mozilla Firefox" for 32 bit Windows. I do not know where Chrome gets installed. Also, uncheck the "Enabled" check box on the "General" tab, so that the rule is normally disabled.

 

If you give the rule (or rules if you have one for Firefox and another for Chrome, and perhaps even one for Internet Explorer) a name like "___block_native", then you can enable the rule using a line-mode command like this:

netsh advfirewall firewall set rule name="___block_native" new enable=yes

And disable it with a command like this:

netsh advfirewall firewall set rule name="___block_native" new enable=no 

To test this in a command window you must start the command window "As Administrator".

 

If you are using the OpenVPN client directly, then you can run these automatically when the VPN comes up or down in fashion similar to what is discussed here:

 

https://airvpn.org/topic/9289-dns-leaks-and-how-to-fix-them/?p=11603

 

As I said, I do not use the Eddie client. But I suspect that you would need to put the command into a ".bat" file as is done in post linked to above, and then tell Eddie to run that ".bat" script at the appropriate event.

 

There is some documentation on the "netsh advfirewall" command options here:

 

https://technet.microsoft.com/en-us/library/dd734783(v=ws.10).aspx

[NaDre 157]

...

Without def1 the WebRTC vulnerabilty doesnt seem to affect people on Windows.

...

 

On Windows Vista and Windows 7 (maybe still in Windows 8), there is a "feature" of the IP stack that I don't believe is present in Linux (I believe I did check this once).

 

I encountered it when working out my scheme to allow the VPN to be used only for torrents (there is a link to the guide above). On my first try, I removed the routing table entries with the "128.0.0.0" mask in order to restore the default gateway. But I found that with that done, I could not get uTorrent, Vuze or any other program to bind correctly to the VPN interface and send traffic over it. Instead I had to leave the "128.0.0.0"-mask entries in place and hide them by creating more routing table entries with a mask of "192.0.0.0" for the original gateway. Then the bind to the VPN interface would work.

 

I seems that a "bind" for an interface will not work in Windows unless there is an entry in the routing table (which may be hidden by other entries) that points at the interface, and matches the target address for the remote end of the connection.

 

And this is why removing the routing table entry with the "0.0.0.0" mask in Windows will also stop the WebRTC leak. The browser's attempt to "call home" on the real interface (to an STUN server) fails. I would think that this trick does not work on Linux. If anyone wants more information about this approach see:

 

https://airvpn.org/topic/9797-blocking-non-vpn-traffic-without-firewall-using-routing-router/

 

Edit:

 

By the way there is a post earlier in this thread by hugomueller with a link to a youtube video about doing this:

 

https://airvpn.org/topic/13519-webrtc-vulnerability/?do=findComment&comment=24856

 

I think this might be helpful to some folks. I wonder hugomueller made the video? Nice work if so.

[Staff 9971]

And this is why removing the routing table entry with the "0.0.0.0" mask in Windows will also stop the WebRTC leak. The browser's attempt to "call home" on the real interface (to an STUN server) fails. I would think that this trick does not work on Linux.

 

Hello!

 

This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary.

 

Kind regards

[Guest JWW]

Well, when I have time I guess I'll need to plough through all of NaDre's guides to learn how to close this leak in Windows. However, the big 'BUT' for AirVPN, I would suggest, is that the vast majority of users will not be able to grasp this - it's pretty technical. Most people end up here because they've tried all the other rubbish VPN solutions (like me) and realise that Air is a more thorough solution. Even the non-technical user though will understand the implications of the WebRTC revelations and, as paying customers, will look for a solution to be provided for them. Currently, for Windows users at least, there is no dependable 'out of the box' solution. I don't count Network Lock as being a solution - I doesn't take people long to realise that there are issues with that. So, with respect to the AirVPN developers (and I do mean that) - I think you need to take a steps towards implementing something better or, at least, consolidating the guides linked to above into something that's easier to follow and understand.

[Guest JWW]

OK. I had a play with this to see if it could be done, deliberately keeping it simple and using Eddie. See screenshot for the Events defined in Eddie. The .bat files are the delete route / add route commands discussed elsewhere by NaDre - just the one line in each file. With this set up, if I disconnect from the VPN I lose all connectivity which is what I want. When I start Eddie it adds the default route, establishes the SSL tunnel and then deletes the default route. I've also used this now with Tixati - it passes the Torrent IP test on ipleak and does not reveal my real IP when tested with both ipleak and https://diafygi.github.io/webrtc-ips/ As soon as I disconnect Eddie the torrent download stops.

 

So far so good, unless you can spot any flaws...??

 

[Guest JWW]

In the end this didn't work reliably. Not surprised really - it was far too crude.

 

So, for me, it has to be Firefox and disabling 'media.peerconnection.enabled' in Firefox. I've removed Chrome and won't use a Chromium browser again until either someone here offers an easy to follow / implement solution or someone else does. I don't have the time for the learning curve and this is verging on technical geekiness. I'm a user at the end of the day - in search of anonymity.

[bork 0]

For what it's worth, Firefox users can use Pale Moon browser to do things like torrents or whatever they need to do while protected from this leak, until an acceptable workaround is created. Pale Moon doesn't make use of WebRTC (it isn't in the browser code), so it isn't vulnerable to the leak. Just use the migration tool on their web site to copy your Firefox profile over and use either browser (or both at the same time) for different tasks.

[Guest JWW]

For what it's worth, Firefox users can use Pale Moon browser to do things like torrents or whatever they need to do while protected from this leak, until an acceptable workaround is created. Pale Moon doesn't make use of WebRTC (it isn't in the browser code), so it isn't vulnerable to the leak. Just use the migration tool on their web site to copy your Firefox profile over and use either browser (or both at the same time) for different tasks.

 

Does using Pale Moon offer something over and above disabling 'media.peerconnection.enabled' in Firefox? With that done I have no leak wherever I check. I also use Vuse (Azureus) which allows me to force a bind to the IPv4 address of the TAP Windows adaptor. I use ipmagnet to check the IP I'm broadcasting and it's only the AirVPN address.

[bork 0]

 

For what it's worth, Firefox users can use Pale Moon browser to do things like torrents or whatever they need to do while protected from this leak, until an acceptable workaround is created. Pale Moon doesn't make use of WebRTC (it isn't in the browser code), so it isn't vulnerable to the leak. Just use the migration tool on their web site to copy your Firefox profile over and use either browser (or both at the same time) for different tasks.

 

Does using Pale Moon offer something over and above disabling 'media.peerconnection.enabled' in Firefox? With that done I have no leak wherever I check. I also use Vuse (Azureus) which allows me to force a bind to the IPv4 address of the TAP Windows adaptor. I use ipmagnet to check the IP I'm broadcasting and it's only the AirVPN address.

It's been a year or two since I read the full write-up/discussion of all of the differences between Firefox and Pale Moon, and I'm no authority on browser security, but other than the general increased security of using a native 64 bit browser and removing some things like support for older verions of windows, etc. I don't know that there is any increased security against this particular problem over your solution in Firefox. I would guess either the leak is there or it isn't, but again, I really don't know that much more about the leak and it's solutions  than is posted here  and on "Torrent Freak" , and in the Pale Moon forums.

[Guest JWW]

In the end this didn't work reliably. Not surprised really - it was far too crude.

 

So, for me, it has to be Firefox and disabling 'media.peerconnection.enabled' in Firefox. I've removed Chrome and won't use a Chromium browser again until either someone here offers an easy to follow / implement solution or someone else does. I don't have the time for the learning curve and this is verging on technical geekiness. I'm a user at the end of the day - in search of anonymity.

 

An interesting side effect (although I have no idea why...) is that my download speeds have increased by around 50% on average using Firefox! Anyone care to hazard a guess as to the reason?

[DanielJackson 0]

Hello !

I have do the test on http://ipleak.net

Your IP address - WebRTC detection
No leak, RTCPeerConnection not available.

 

Well good !! (i must activate javascript and don't use ResquestPolicy too see that)

But for DNS Address detection I have allaws the six same IP , it's not my real IP , but it's my own InternetServiceProvider and my own country ...

Is this a little bothersome ...

Thank you for your help !
-----
Firefox , Win7x64 , eddie 2.8

 

[Staff 9971]

Hello,

 

in our client Eddie, is "Force DNS" ticked in "AirVPN" -> "Preferences" -> "Advanced"?

 

Kind regards

[DanielJackson 0]

That's it !

I checked "Force DNS" , "eddie" reboot , and now , I have only the IP address of the AirVPN server in the DNS détetction.

I hope I did not forget to check something else ? (even the firmware of the hard drives are dangerous now , be too careful ^^)

Thank you very much for your help

[VPNagent 0]

Found this Video on youtube:

[hugomueller 13]

in our client Eddie, is "Force DNS" ticked in "AirVPN" -> "Preferences" -> "Advanced"?

 

This did not worked for me (Win 8.1 x64). I always have to activate the network lock to hide my DNS.

[Guest JWW]

You also need 'Check if the tunnel use AirVPN DNS'.

[hugomueller 13]

If I tick this, the connection is not established. It starts retrying to reconnect but never connects.

[Guest JWW]

OK, I have some information and a question for Staff:

 

Using Chrome Beta (version 41) and the following extension I have WebRTC completely blocked - https://chrome.google.com/webstore/detail/vpnac-secureproxy/kcndmbbelllkmioekdagahekgimemejo/related

 

I do NOT have an account with these people - just the presence of the extension is enough. I am still connected via AirVPN with Network Lock deactivated. Tested using ipleak and https://mullvad.github.io/webrtc-ips/ More information here: https://vpn.ac/announcements.php?id=15

 

The most obvious question is: If they can do it, is there something you can do along similar lines?

[Staff 9971]

Hello @JWW,

 

Eddie's "Network Lock" works on every browser and every program because it solves the Windows problem at its roots. What you cite is a Chrome extension, unrelated to VPN or other services. It can't prevent WebRTC leaks from other than Chrome programs. Currently we do not have developers for browsers extensions, but who knows, it could be an idea. Anyway, good to know that such an extension now exists. Previously available extension did not work properly.

 

Kind regards

[Guest JWW]

Hello @JWW,

 

Eddie's "Network Lock" works on every browser and every program because it solves the Windows problem at its roots. What you cite is a Chrome extension, unrelated to VPN or other services. It can't prevent WebRTC leaks from other than Chrome programs. Currently we do not have developers for browsers extensions, but who knows, it could be an idea. Anyway, good to know that such an extension now exists. Previously available extension did not work properly.

 

Kind regards

 

Sure, NL covers any browser, but there are issues with it that I personally don't like, plus it still reveals my Air IP, local IP and TAP Adaptor IP. Now, although that may not be a major issue (?) and as a Chrome user, I'd rather take advantage of an extension that blocks the lot!

 

I looked at their info page after you replied and I can see that their new Chrome extension 'WebRTC Stopper' was released today. That wasn't there yesterday, so what I'd installed was their VPN / Secure Proxy extension which includes the same WebRTC blocking functionality. 'WebRTC Stopper' however is neat, works, and successfully replaces the defunct 'WeRTC Block' extension that's now broken. Maybe you could update your info post on this and point people at 'https://chrome.google.com/webstore/detail/webrtc-stopper/mfehokchlmjlkmlgjhkmlpcldcbcooec'

 

Thanks.

 

EDIT: Cyberghost have also released one today that works:

 

https://chrome.google.com/webstore/detail/cyberghost-webrtc-leak-pr/fcacplgecnjoapkgbbfdijidojncpijc?utm_source=chrome-app-launcher-info-dialog

 

Be nice to see one from AirVPN - just to show you care ;-)

[usr32 2]

A little late but thanks to knighthawk and NaDre for your elucidation on firewall rules in Windows. I am in the process of migrating to linux completely as I grew more and more comfortable with it during the last years. I strongly recommend everybody to try it or use it in a VM to browse, etc...

 

@JWW: Why should AirVPN invest resources if others are already providing good Chrome extensions that "solve" the problem?

 

Anyway, is anyone aware if Windows 10 has some changes in architecture regarding the problems with WebRTC?

[Guest JWW]

A little late but thanks to knighthawk and NaDre for your elucidation on firewall rules in Windows. I am in the process of migrating to linux completely as I grew more and more comfortable with it during the last years. I strongly recommend everybody to try it or use it in a VM to browse, etc...

 

@JWW: Why should AirVPN invest resources if others are already providing good Chrome extensions that "solve" the problem?

 

Anyway, is anyone aware if Windows 10 has some changes in architecture regarding the problems with WebRTC?

 

It was only a half serious comment - thus the 'wink'. The only reason would be because the other extension developers are competitive VPN's but to be honest Air doesn't need to prove much, so I agree. Truth be known, I'd rather use Network Lock, imperfect though it is. 

[TunnelRat 0]

I strictly utilize Safari Browser for Windows and it's Good To Go, no leaks and no worries.