Perfect Privacy
Administrator
We took a closer look at this vulnerability over the weekend and have some further analysis on the problem and how to protect against it.
Most importantly it should be noted that while WebRTC is used to exploit this IP leak it is not the cause. Instead it is an underlying Windows feature that allows the routing table to be circumvented. As stated by Microsoft:
“If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.” [1]
Normally, when using VPN, a more specific route to the TUN/TAP adapter is added so that it is always preferred for connections. However, in Windows “Source IP address selection” allows using a different route if the source IP is bound to a specific interface.
You can test this by issuing the following command in the console:
If you use the LAN IP issued by your router, then the ping requests will be routed through the unencrypted connection even if you are connected to VPN. In our tests this did not work on all systems (ping may fail with “General Failure”) but we were able to reproduce this with a fresh install of Windows 7.
The bottom line is that it is possible for Windows applications to use this feature to enforce traffic over an unencrypted adapter – this is not limited to WebRTC. So using a browser extension to block WebRTC only prevents this specific attack but the underlying problem remains.
The Perfect Privacy VPN Manager does prevent this leak with its default settings. The integrated firewall protection is turned on by default if a VPN tunnel is established. This prevents any packets leaving the network over an unencrpyted connection even if source IP selection is used to route over another adapter: such requests will simply be blocked.
To conclude, as long the firewall protection is enabled in the VPN manager, the system is immune to such IP leaks, whether triggered by WebRTC or any other means.
[1] http://blogs.technet.com/b/networkin...-computer.aspx
Kind regards,
Your Perfect Privacy Team
Most importantly it should be noted that while WebRTC is used to exploit this IP leak it is not the cause. Instead it is an underlying Windows feature that allows the routing table to be circumvented. As stated by Microsoft:
“If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.” [1]
Normally, when using VPN, a more specific route to the TUN/TAP adapter is added so that it is always preferred for connections. However, in Windows “Source IP address selection” allows using a different route if the source IP is bound to a specific interface.
You can test this by issuing the following command in the console:
Code:
ping -S "your LAN IP" "remote IP"The bottom line is that it is possible for Windows applications to use this feature to enforce traffic over an unencrypted adapter – this is not limited to WebRTC. So using a browser extension to block WebRTC only prevents this specific attack but the underlying problem remains.
The Perfect Privacy VPN Manager does prevent this leak with its default settings. The integrated firewall protection is turned on by default if a VPN tunnel is established. This prevents any packets leaving the network over an unencrpyted connection even if source IP selection is used to route over another adapter: such requests will simply be blocked.
To conclude, as long the firewall protection is enabled in the VPN manager, the system is immune to such IP leaks, whether triggered by WebRTC or any other means.
[1] http://blogs.technet.com/b/networkin...-computer.aspx
Kind regards,
Your Perfect Privacy Team