Another "critical" "vulnerability" "VPN" and why Port Fail is nonsense
The morning of November 26 began for me with interesting news - the guys from Perfect Privacy published information about the Port Fail vulnerability , which allows revealing the IP address of VPN services clients with the port forwarding function. I spent a little time because it was called a vulnerability, because This is not a vulnerability, but a routing feature: the traffic to the IP address of the VPN server always goes directly, bypassing the VPN. An obvious thing, I thought, which any network administrator should be aware of. The note is sane and technically competent, you can only complain about the word vulnerability. But then the media got down to business, and off it went ...
Critical vulnerability in all VPN protocols on all operating systems. Wow, how scary!
')
In the news, published on Geektimes , which initially had a yellow headline, it was said about a reward of $ 5000 for the found “vulnerability” from Private Internet Access - one of the largest VPN services. “$ 5,000 for a typical, absolutely obvious to any networker thing?” - I thought - “Incredible!”, And expressed his indignation about this in the comments, along the way writing another, equally obvious, feature of routing that any one who tuned in and more Internet providers on the same computer: the answer to the incoming request does not necessarily leave through the same provider and with the same IP, which the requester does not expect at all. If we imagine that instead of a second provider we have a VPN connection, then by sending a request to our provider’s IP address, under certain conditions it may turn out that we will receive an answer to our request from the VPN server’s IP address.
Applications that listen to the port and accept incoming connections to it, for the most part, rely on the operating system when generating a response to the incoming incoming packet. This works fine when you have one network interface, but the situation changes with several interfaces, depending on the OS and protocol:
Windows :
OS X :
Linux :
In Linux, there is a wonderful setting Reverse Path Filtering (rp_filter), which is enabled by default in most modern distributions. If the filter is enabled, the program listening on the port will not receive any incoming data if the OS is confident that the response will be sent through another interface. It should be noted that in some distributions (at least in Debian) this option is disabled by default, although the reasons for this are not clear.
Unfortunately, there is no such functionality in Windows and OS X.
So, how can companies that monitor violations of intellectual property take advantage of this feature of routing:
In my opinion, to exploit this approach is quite problematic due to the fact that almost all BitTorrent clients select a random port when they first start, and send messages to all ports and all IP addresses on the Internet, although it is quite possible, but at least difficult to do all the time. However, there are customers who use standard ports like 8999 or 6881.
Connecting to this client will not work with a standard network stack, but you can modify it so that such connections are established.
With Linux, everything is very simple - for IPv4, it’s enough to set the option
And for IPv6, you need to add an iptables rule:
On Windows, there is a powerful Windows Filtering Platform, from which you can write quite flexible firewall rules directly in user-space, and if this is not enough, write a kernel driver.
As in the case of DNS leaks in Windows 10 , I tried to implement the semblance of Reverse Path Forwarding under Windows as a plug-in for OpenVPN. He does the following:
Although it is not a full-fledged Reverse Path Forwarding, it does its job quite well: the responses to UDP requests can go to the VPN tunnel only if they come from the ranges of non-routable addresses, but in that case they will be dropped on the VPN side server because they are, in fact, non-routable (they work only within a certain local network); programs that use UDP (for example, BitTorrent Sync) will not stop working on the inside LAN, and neighbors on the provider subnet will still be able to communicate with you correctly.
Download the plugin here: github.com/ValdikSS/openvpn-block-incoming-udp-plugin
In OS X, everything is somewhat more complicated: PF does not allow filtering only new UDP packets, so you have to block all incoming UDP, except for local addresses, the provider subnet and the VPN server itself. This is bad because, for example, you will not be able to use the DNS provider if you want, because the answers you simply will not reach, it will be necessary to make the IP of the DNS server in the white list.
In any case, this can be done approximately as follows:
I sent messages about this feature to 11 VPN providers, I received a response only from 5: Private Internet Access , Perfect Privacy and Mullvad released an updated client with the ability to block incoming connections, Astrill wrote that they do not consider this feature significant, and that it does not have relationship to the VPN. Technically, they are right, but their client has protection from other client problems - IPv6, DNS and WebRTC leaks, and why not adding another one remains a mystery to me. The guys from Cryptostorm suggested the Windows registry key, which should include Reverse Path Forwarding, but it does not work, and TorGuard did not write anything after answering some questions from their side.
By the way, OpenVPN 2.3.9 came out with numerous Windows bug fixes and the long awaited option
So I received my $ 5,000 from Private Internet Access, $ 1,000 on top of Perfect Privacy and $ 1,300 from Mullvad for one more nonsense, and I, frankly, even a little awkward for it. Part of the money goes to the developers of OpenVPN and strongSwan.
Critical vulnerability in all VPN protocols on all operating systems. Wow, how scary!
')
In the news, published on Geektimes , which initially had a yellow headline, it was said about a reward of $ 5000 for the found “vulnerability” from Private Internet Access - one of the largest VPN services. “$ 5,000 for a typical, absolutely obvious to any networker thing?” - I thought - “Incredible!”, And expressed his indignation about this in the comments, along the way writing another, equally obvious, feature of routing that any one who tuned in and more Internet providers on the same computer: the answer to the incoming request does not necessarily leave through the same provider and with the same IP, which the requester does not expect at all. If we imagine that instead of a second provider we have a VPN connection, then by sending a request to our provider’s IP address, under certain conditions it may turn out that we will receive an answer to our request from the VPN server’s IP address.
How can this happen?
When you connect to a VPN, the default route that was previously installed through your provider changes to a route through the VPN.Applications that listen to the port and accept incoming connections to it, for the most part, rely on the operating system when generating a response to the incoming incoming packet. This works fine when you have one network interface, but the situation changes with several interfaces, depending on the OS and protocol:
Windows :
- OpenVPN (def1) - UDP goes through the VPN interface, TCP works correctly
- IPsec IKEv2 - UDP goes through the VPN interface, TCP is dropped
OS X :
- OpenVPN (def1) - UDP goes through the VPN interface, TCP is dropped
- IPsec IKEv2 - UDP goes through the VPN interface, TCP works correctly
Linux :
- OpenVPN (def1) - UDP and TCP go through the VPN interface when rp_filter = 0, are discarded when rp_filter = 1
In Linux, there is a wonderful setting Reverse Path Filtering (rp_filter), which is enabled by default in most modern distributions. If the filter is enabled, the program listening on the port will not receive any incoming data if the OS is confident that the response will be sent through another interface. It should be noted that in some distributions (at least in Debian) this option is disabled by default, although the reasons for this are not clear.
Unfortunately, there is no such functionality in Windows and OS X.
What could this mean?
As you can see, the problem is only incoming packets to applications that listen on the UDP port. It is unlikely that there will be many such applications on a typical user's computer, but there are some, as a rule.Bittorrent
As you may know, in some countries, for example, in the USA, Germany, France, Austria, Canada, Great Britain, there are special organizations that track the participants of BitTorrent distributions of interest at the request of the copyright holders. They connect to BitTorrent trackers and a DHT network and save all the IP addresses of a particular distribution, then send “happiness letters” - messages that such and such an IP address with such a port distributed such and such a file to time, that this is all illegal, and that you need to pay a fine for this thing. Residents of these countries use VPN in other, "less developed" countries, in order not to get caught in the scanners of these villains, and companies are sad about it.So, how can companies that monitor violations of intellectual property take advantage of this feature of routing:
- The user to whom the provider issues a “white” (routable) IP address, connects to the VPN, starts the BitTorrent client and downloads some files, remaining after downloading on the distribution. The BitTorrent client listens on the port and opens it, if necessary, through UPnP.
- The company involved in monitoring collects all the IP addresses on this distribution, including the IP address and port of our user's VPN server.
- The company massively sends UDP packets to BitTorrent clients to all IP addresses on the Internet, to ports collected earlier. You can meet the tens of minutes when using a 10-gigabit channel.
- The BitTorrent client of the user, having received an incoming packet on the network interface of the provider, sends a response via the VPN interface, from the IP of the VPN server.
- The company detects the real IP of the client, distributing material of interest to them.
In my opinion, to exploit this approach is quite problematic due to the fact that almost all BitTorrent clients select a random port when they first start, and send messages to all ports and all IP addresses on the Internet, although it is quite possible, but at least difficult to do all the time. However, there are customers who use standard ports like 8999 or 6881.
Connecting to this client will not work with a standard network stack, but you can modify it so that such connections are established.
Skype
Using this technique, you can find out the real IP of Skype users you are interested in, if they use a VPN. There are a large number of public Skype resolvers that will show you the user's IP and port via Skype login. Next, you need to resort to the same technique that the right holders would use - send some data to the UDP port all over the Internet, and follow the answers. It is noteworthy that almost any garbage can be sent to Skype! Let's use the great nping program from nmap:# nping --udp -p 13318 --data-string 'hellothere!' -c 1 serv.valdikss.org.ru Starting Nping 0.7.00 ( https://nmap.org/nping ) at 2015-12-20 19:54 MSK SENT (0.0157s) UDP 195.154.127.59:53 > 92.42.31.8:13318 ttl=64 id=10802 iplen=39 RCVD (0.0859s) UDP 185.61.149.121:4272 > 195.154.127.59:53 ttl=54 id=1534 iplen=32 Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A Raw packets sent: 1 (39B) | Rcvd: 1 (46B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.01 seconds How to protect yourself?
Although I do not consider this feature to be such a big problem, I still wonder how to prevent this kind of leakage from a technical point of view.With Linux, everything is very simple - for IPv4, it’s enough to set the option
net.ipv4.conf.*.rp_filter in 1, if it is not yet installed. My VPN interface is called tun0 , and the interface with the Internet is wlp3s0 , so I do the following: # sysctl net.ipv4.conf.all.rp_filter=1 # sysctl net.ipv4.conf.default.rp_filter=1 # sysctl net.ipv4.conf.tun0.rp_filter=1 # sysctl net.ipv4.conf.wlp3s0.rp_filter=1 And for IPv6, you need to add an iptables rule:
# ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP On Windows, there is a powerful Windows Filtering Platform, from which you can write quite flexible firewall rules directly in user-space, and if this is not enough, write a kernel driver.
As in the case of DNS leaks in Windows 10 , I tried to implement the semblance of Reverse Path Forwarding under Windows as a plug-in for OpenVPN. He does the following:
- Allows any incoming IPv4 unicast UDP packets from 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 addresses and subnets of active network adapters; Any incoming IPv6 unicast UDP packets from fd00 :: / 8, fe80 :: / 10, and subnets of active network adapters.
- Blocks all new unicast UDP packets from outside the VPN interface.
Although it is not a full-fledged Reverse Path Forwarding, it does its job quite well: the responses to UDP requests can go to the VPN tunnel only if they come from the ranges of non-routable addresses, but in that case they will be dropped on the VPN side server because they are, in fact, non-routable (they work only within a certain local network); programs that use UDP (for example, BitTorrent Sync) will not stop working on the inside LAN, and neighbors on the provider subnet will still be able to communicate with you correctly.
Download the plugin here: github.com/ValdikSS/openvpn-block-incoming-udp-plugin
In OS X, everything is somewhat more complicated: PF does not allow filtering only new UDP packets, so you have to block all incoming UDP, except for local addresses, the provider subnet and the VPN server itself. This is bad because, for example, you will not be able to use the DNS provider if you want, because the answers you simply will not reach, it will be necessary to make the IP of the DNS server in the white list.
In any case, this can be done approximately as follows:
echo 'pass in quick proto udp from 10.0.0.0/8 to any pass in quick proto udp from 192.168.0.0/16 to any pass in quick proto udp from 172.16.0.0/12 to any pass in quick proto udp from 169.254.0.0/16 to any pass in quick proto udp from 185.61.149.121/32 to any block in quick on ! utun1 proto udp to any' | sudo pfctl -Ef - Where 185.61.149.121 is the IP address of the VPN server, and utun1 is the VPN interface.Afterword
If you are all a villain, and you want to try to exploit this feature, you will be helped by packet logging in Linux using netfilter. It is enough to add the following iptables rule, and all packets from Mars will be in full view: iptables -I INPUT -m conntrack -p udp --sport 4455 --ctstate NEW -j LOG Where 4455 is the port you are interested in.I sent messages about this feature to 11 VPN providers, I received a response only from 5: Private Internet Access , Perfect Privacy and Mullvad released an updated client with the ability to block incoming connections, Astrill wrote that they do not consider this feature significant, and that it does not have relationship to the VPN. Technically, they are right, but their client has protection from other client problems - IPv6, DNS and WebRTC leaks, and why not adding another one remains a mystery to me. The guys from Cryptostorm suggested the Windows registry key, which should include Reverse Path Forwarding, but it does not work, and TorGuard did not write anything after answering some questions from their side.
By the way, OpenVPN 2.3.9 came out with numerous Windows bug fixes and the long awaited option
--block-outside-dns , which fixes DNS leaks on Windows 8.1 and 10.So I received my $ 5,000 from Private Internet Access, $ 1,000 on top of Perfect Privacy and $ 1,300 from Mullvad for one more nonsense, and I, frankly, even a little awkward for it. Part of the money goes to the developers of OpenVPN and strongSwan.
Source: https://habr.com/ru/post/273523/
All Articles