WebRTC vulnerability

[Staff 9972]

EDIT: a deeper study of improperly called "WebRTC leak" has brought up how the initial approach by a wide part of communities discussing it has been totally wrong, has missed the core reasons and has proposed "solutions" which are questionable. Please see here to get a more balanced and informed view of the so called "problem".

 

http://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks

 

 

WARNING: the following post was written hours after "WebRTC leak" hit the news. It is now to be considered outdated. It is also inappropriate when it uses the word "vulnerability". However, the way to prevent applications to talk outside the tunnel is the same, enable Network Lock or set proper firewall rules. It is absolutely nothing new, just like the whole fabricated "WebRTC leak" affair.

 

 

============================================================================

 

Hello!
 
Browsers supporting WebRTC run in a Windows-environment can seriously compromise the security of VPN-tunnels by allowing the true IP address of the user to be read. https://en.wikipedia.org/wiki/WebRTC#Concerns

WebRTC is supported in the following browsers:

https://en.wikipedia.org/wiki/WebRTC#Support

 

According to our tests we can at this moment confirm that Linux and OS X appear to be not affected. EDIT: OS X users please see here, according to this report OS X is vulnerable as well. https://airvpn.org/topic/13490-vpn-security-flaw-does-this-affect-airvpn/?do=findComment&comment=24757

 

You can test your system here: http://ipleak.net

 

Windows users can fix the vulnerability in one of the following ways:

 

- by enabling "Network Lock" in our free and open source client Eddie

- by configuring a firewall to prevent leaks. In our "How-To" section we have guides for Comodo and Windows Firewall

- by disabling WebRTC on the browser (WARNING: you can't do that in Google Chrome desktop edition, you'll need an extension). This page seems quite accurate https://www.browserleaks.com/webrtc#webrtc-disable

EDIT: in the above linked page, the extension recommended for Chrome does not really prevent leaks

- by running a browser which does not support WebRTC

 

 

Kind regards

AirVPN Support Team

[koloc-1458-261 0]

Hello!

 

Browsers supporting WebRTC run in a Windows-environment can seriously compromise the security of VPN-tunnels by allowing the true IP address of the user to be read. https://en.wikipedia.org/wiki/WebRTC#Concerns

 

 

According to our tests we can at this moment confirm that Linux and OS X appear to be not affected.

 

 

Just out of curiosity: does anyone know the reason why only Windows OS seems to be affected by this issue?

[bluesjunior 43]

I use the 64bit Palemoon browser as my main internet connection. It is a Firefox based browser and I got an okay ie (WebRTC not supported message) when I clicked on the link above.

[rickjames 106]

Thanks for adding those checks at ipleak.net

 

For anyone interested in firefox just set media.peerconnection.enabled to false

 

about:config

media.peerconnection.enabled = false

[JasonBourne 8]

Hello!

 

Thank you for addressing this security 'flaw' affecting Windows firefox, chrome and opera web browsers.

And also thank you for the quick addition of the WebRTC detection check to ipleak.net.

 

Alternatively, Chrome users can install the ScriptSafe extension and Firefox users could block the request with the NoScript addon, which both reportedly block the vulnerability.

 

Opera users can download this plugin that will allow them to download and use Google Chrome add-ons.

[Corsair28 8]

Thank you guys for this information. I use both Firefox and Chromium.  We should have this as a sticky somewhere.

[perhentian 2]

Great guys, thanks for the heads up. Love you customer "care taking"!

[zalbard 0]

I am using the latest client with Network Lock enabled, and it does not prevent WebRTC leak according to ipleak.net.

 

Other software: Windows 8.1 x64 + Chrome with the latest updates. If it helps, I am using SSH.

 

 

Windows users can fix the vulnerability in one of the following ways:

 

- by enabling "Network Lock" in our free and open source client Eddie

 

[Guest JWW]

 

I am using the latest client with Network Lock enabled, and it does not prevent WebRTC leak according to ipleak.net.

 

Other software: Windows 8.1 x64 + Chrome with the latest updates. If it helps, I am using SSH.

 

 

Windows users can fix the vulnerability in one of the following ways:

 

- by enabling "Network Lock" in our free and open source client Eddie

 

No, I discovered the same. In Chrome you need to use this extension which works.

[Staff 9972]

@zalbard

 

Could you please disable IPv6 and try again? http://support.microsoft.com/kb/929852

 

Kind regards

[Guest JWW]

@zalbard

 

Could you please disable IPv6 and try again? http://support.microsoft.com/kb/929852

 

Kind regards

 

I've tried it and it works. IPv6 disabled. Network Lock On. Chrome extension disabled. No leak.

[hugomueller 13]

You can prevent the IP leak by deleting the route in Windows:

 

 

 

http://youtu.be/Ie6UNTnRY-A
 

[fYaA2xJlS3 0]

Is there a method for disabling webrtc on smartphones? I'm using chrome on android and ipleak shows my private ipv4 addresses.

[Guest JWW]

 

Hello!

 

Browsers supporting WebRTC run in a Windows-environment can seriously compromise the security of VPN-tunnels by allowing the true IP address of the user to be read. https://en.wikipedia.org/wiki/WebRTC#Concerns

 

WebRTC is supported in the following browsers:

https://en.wikipedia.org/wiki/WebRTC#Support

 

According to our tests we can at this moment confirm that Linux and OS X appear to be not affected. EDIT: OS X users please see here, according to this report OS X is vulnerable as well. https://airvpn.org/topic/13490-vpn-security-flaw-does-this-affect-airvpn/?do=findComment&comment=24757

 

You can test your system here: http://ipleak.net

 

Windows users can fix the vulnerability in one of the following ways:

 

- by enabling "Network Lock" in our free and open source client Eddie

- by configuring a firewall to prevent leaks. In our "How-To" section we have guides for Comodo and Windows Firewall

- by disabling WebRTC on the browser (WARNING: you can't do that in Google Chrome desktop edition, you'll need an extension). This page seems quite accurate https://www.browserleaks.com/webrtc#webrtc-disable

- by running a browser which does not support WebRTC

 

 

Kind regards

AirVPN Support Team

Just made a horrible discovery. Currently I'm on an SSL tunnel through Eddie. I have the Chrome extension 'WebRTC' block enabled. ipleak is telling me, right now, that I have "No leak, RTCPeerConnection not available". However, if I go here that page tells gives me my AirVPN address and my real one!

 

Conclusion: the Chrome extension does NOT work! And... ipleak does not, apparently, work either!

[AirVpnUser82 4]

Hello!

 

Browsers supporting WebRTC run in a Windows-environment can seriously compromise the security of VPN-tunnels by allowing the true IP address of the user to be read. https://en.wikipedia.org/wiki/WebRTC#Concerns

 

WebRTC is supported in the following browsers:

https://en.wikipedia.org/wiki/WebRTC#Support

 

According to our tests we can at this moment confirm that Linux and OS X appear to be not affected. EDIT: OS X users please see here, according to this report OS X is vulnerable as well. https://airvpn.org/topic/13490-vpn-security-flaw-does-this-affect-airvpn/?do=findComment&comment=24757

 

You can test your system here: http://ipleak.net

 

Windows users can fix the vulnerability in one of the following ways:

 

- by enabling "Network Lock" in our free and open source client Eddie

- by configuring a firewall to prevent leaks. In our "How-To" section we have guides for Comodo and Windows Firewall

- by disabling WebRTC on the browser (WARNING: you can't do that in Google Chrome desktop edition, you'll need an extension). This page seems quite accurate https://www.browserleaks.com/webrtc#webrtc-disable

- by running a browser which does not support WebRTC

 

 

Kind regards

AirVPN Support Team

Just made a horrible discovery. Currently I'm on an SSL tunnel through Eddie. I have the Chrome extension 'WebRTC' block enabled. ipleak is telling me, right now, that I have "No leak, RTCPeerConnection not available". However, if I go here that page tells gives me my AirVPN address and my real one!

 

Conclusion: the Chrome extension does NOT work! And... ipleak does not, apparently, work either!

 

Yep, just went to it today and I can confirm that the extension indeed doesn't work. Any other extensions?

[Kenwell 9]

I just disabled port 3478 for UDP and TCP in my router with success. After disabling this port.

Ipleak couldn't find any ip's rather then the standard exit ip from AIR.

 

Also i tried ipIeak on my mobile phone and tablet using my home wifi. No leaks where found. 

 

Downside of it is, some In the house couldn't talk back when they where in chat on the ps4.

These ports have something to do with voip?

 

Source: http://en.wikipedia.org/wiki/STU

 

TLS i couldn't find in my router and didn't block port 5349 for TLS because the above already worked.

 

Maybe it helps.

 

Cheers.

[Guest JWW]

 

@zalbard

 

Could you please disable IPv6 and try again? http://support.microsoft.com/kb/929852

 

Kind regards

 

I've tried it and it works. IPv6 disabled. Network Lock On. Chrome extension disabled. No leak.

 

That wasn't a genuine test, well...sort of. I discovered that IPv6 is in any case disabled by my ISP, so I didn't need to use the MS 'FixIt' to disable. However, I can confirm that with Network Lock running my ISP IP Address is not revealed by ipleak or by https://diafygi.github.io/webrtc-ips/

 

It is true though that the Chrome extension does not work in that your real IP is still revealed by https://diafygi.github.io/webrtc-ips/ although NOT by ipleak.

 

Fine, except Network Lock still screws with local network discovery and slows down local access.

[go558a83nk 362]

Yes, it is known that the RTC testing site was updated to show the vulnerability still exists for chrome users.  My advice is to uninstall anyting related to google. :-)  but if you won't do that, use script safe.

[Guest JWW]

Yes, it is known that the RTC testing site was updated to show the vulnerability still exists for chrome users.  My advice is to uninstall anyting related to google. :-)  but if you won't do that, use script safe.

 

You mean anything related to Chromium based browsers . I'm running Firefox now with WebRTC turned off which works pefectly without having to have Network Lock running. I'm annoyed at the situation with Network Lock frankly. It's purpose should be to secure the VPN route ONLY, not interfere with local network sharing settings - that's the user's reponsibility, not AirVPN's. In another thread somewhere about similar issues someone asked (of AirVPN) 'Are you trying to protect us from ourselves'?!

[usr32 2]

I just want to share my personal solution which I already posted in Off-topic:

So I solved the problem with the additional arguments:

 

route-nopull

redirect-gateway bypass-dhcp

 

This is to ignore the argument def1 that is being pushed by the server to the client that is responsible.

But:

 

dhcp-option DNS x.x.x.x

route x.x.x.x

 

will be ignored. So the DNS of the server will not be used. If you add this argument with a public DNS or 10.4.0.1 it should be fine.

 

I don't know if route is important in this case. I did not experience any differences when adding route 10.4.0.1 or leaving it out.

 

This has the effect that the route that reveals the ISPs IP gets deleted when connecting.

With also adding:

 

dhcp-option DNS 10.4.0.1

route 10.4.0.1

 

the config should stay the same just without the argument def1.

[Staff 9972]

Just made a horrible discovery. Currently I'm on an SSL tunnel through Eddie. I have the Chrome extension 'WebRTC' block enabled. ipleak is telling me, right now, that I have "No leak, RTCPeerConnection not available". However, if I go here that page tells gives me my AirVPN address and my real one!

 

Conclusion: the Chrome extension does NOT work! And... ipleak does not, apparently, work either!

 

Hello!

 

Confirmed. Also, ipleak.net code has been updated (just like other sites did) to show that this Chrome extension does not work properly. Code update to show the leak more effectively was necessary for all sites, because the demo code was different a couple of days ago.

 

Kind regards

[NaDre 157]

...I'm running Firefox now with WebRTC turned off which works perfectly without having to have Network Lock running. I'm annoyed at the situation with Network Lock frankly. It's purpose should be to secure the VPN route ONLY, not interfere with local network sharing settings - that's the user's responsibility, not AirVPN's. In another thread somewhere about similar issues someone asked (of AirVPN) 'Are you trying to protect us from ourselves'?!

 

I don't use AirVPN's client.

 

This is because the way I use my network connections is probably quite unique to me. And I do not expect a single program, written by AirVPN or anyone else, to provide the level of flexibility and generality that can be achieved by configuring client programs, OpenVPN, the routing table and Windows Firewall. The idea of a program like the AirVPN client is to make things easier for those who do not want to spend the time learning how to configure all of the individual components. To be simpler for the user, such a program must present some simpler paradigm to the user. And this guarantees that there will be things that cannot be added or removed from the underlying (real configuration).

 

I am sure many people who start out using AirVPN's program will grow to a point where what they want to do cannot be done using AirVPN's program. When that point is reached, I think their efforts would be better spent learning how to do without AirVPN's program rather than demanding that AirVPN add more and more complexity to their client.

 

Setting "media.peerconnection.enabled" to false suppresses some functionality that some users may want to use. And use over the VPN.

 

A simple alternative is to add a rule (just one rule, so nothing so extensive as "network lock") to Windows Firewall that blocks Firefox from using the real interface. The rule must be given a name. This rule can then be enabled when the VPN is up, and disabled when the VPN is down, using a line-mode command that refers to the name of the rule (there can be several rules with the same name, so all get enabled or disabled together). And if you are using the OpenVPN client with your own customized configuration files, this can be made automatic.

 

So one could use the functionality lost by setting "media.peerconnection.enabled" to false over the VPN, without any risk of the real IP address be discovered.

 

I could provide a bit more explanation, or links to other topics here about doing this sort of thing, if anyone asks. I am sure other people here could too.

[Staff 9972]

A simple alternative is to add a rule (just one rule, so nothing so extensive as "network lock") to Windows Firewall that blocks Firefox from using the real interface. The rule must be given a name. This rule can then be enabled when the VPN is up, and disabled when the VPN is down, using a line-mode command that refers to the name of the rule (there can be several rules with the same name, so all get enabled or disabled together). And if you are using the OpenVPN client with your own customized configuration files, this can be made automatic.

 

 

 

Hello!

 

Wise words. On top of that, we would like to underline that developer has made remarkable efforts to keep the client flexible for users who are "evolving" to advanced competence, with subsequent higher requirements, but still do not feel to leave Eddie which provides several commodities that can be appreciated even by quite advanced users.

 

About this topic, keep in mind that seven different "Events" can be defined in Eddie. Events can occur at Eddie start, Eddie shut down, Session start, Session end, VPN Pre, VPN up and VPN down. For each event, in any combination, user can tell Eddie to execute something, with or without arguments. For each event, Eddie can be instructed to wait for the event end, or go on without waiting.

 

This is a useful addition for a very wide variety of purposes, in addition to the option to customize completely OpenVPN directives from inside Eddie as well. We are confident that "Events" provide a fair balance between advanced usage requirements and demands to not allow the client to become too heavy as well as maintaining the option to run it without installation.

 

The quickest way to define events is through the GUI, at "AirVPN" -> "Preferences" -> "Advanced" -> "Events".

 

Kind regards

[koloc-1458-261 0]

A simple alternative is to add a rule (just one rule, so nothing so extensive as "network lock") to Windows Firewall that blocks Firefox from using the real interface. The rule must be given a name. This rule can then be enabled when the VPN is up, and disabled when the VPN is down, using a line-mode command that refers to the name of the rule (there can be several rules with the same name, so all get enabled or disabled together). And if you are using the OpenVPN client with your own customized configuration files, this can be made automatic.

 

So one could use the functionality lost by setting "media.peerconnection.enabled" to false over the VPN, without any risk of the real IP address be discovered.

 

I could provide a bit more explanation, or links to other topics here about doing this sort of thing, if anyone asks. I am sure other people here could too.

 

Yes, I am very interested in a firewall rule that could prevent firefox from direct access to the real interface. Even with Linux it appears that at least my local network address is leaked through webrtc (according to ipleak.net). I'm wondering how such a rule can be implemented? Up to now I'm only using a rule that blocks all traffic through the real interface (DROP OUTPUT) except traffic to the air vpn server as suggested in the tutorial section. Do you use some sort of prerouting to force all traffic through tun0?

 

Thank you!

[Guest JWW]

OK. I accept that - to a degree. There is a half way house though, so to speak. I'm pretty technical but possibly not as technical as NaDre. I'd like to continue with the convenience of of using Eddie but I do not want to use Network Lock - it goes too far for me as I've made clear in other posts.

 

As I am fairly technical 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. I understand the basis of creating firewall rules and importing them - I just need the detail. I like the idea, which I admittedly hadn't considered, that Eddie can still be a tool for advanced users in terms of managing events that are outside it's 'default' behaviour. I'm certainly ready for that, particularly as 1) I'd rather continue using Chrome anyway and 2) I appreciate why it's not necessarily a good idea to completely disable  'media.peerconnection.enabled' in Firefox. That would certainly seem to be the 'using the sledgehammer to crack the nut' approach.

 

Thanks in advance!