How to avoid dual-stack VPN traffic Leakage

 

Free and available IPv4 addresses will soon be "exhausted". Over the years, this has prompted most general operating systems to begin to add IPv6 support. However, many applications (such as VPN clients and server software) are not ready for IPv6. This will lead to the situation where the dual-protocol stack host deployment does not support IPv6 VPN software, thus opening the door for security vulnerabilities and causing VPN traffic leakage. In this article, we will discuss how these VPN security problems occur and how to mitigate VPN traffic leaks. Introduction: Risks of VPN Leakage

Employees working from remote locations usually establish virtual private network (VPN) connections to access services in the enterprise network, and protect the traffic that must pass through the insecure network. In some cases, because VPN provides security services, for example, to keep all communications over VPN confidential, we believe that using VPN connections makes insecure protocols acceptable (for example, transmitting sensitive information in plain text ).

Many VPN connections only support the IPv4 protocol. However, hosts that deploy these technologies are generally dual-protocol stacks, which means they support both IPv4 and IPv6 (enabled by default ). Currently, many hosts only use IPv4, because most networks do not provide IPv6 connections. IPv6 support still exists on the host but needs to be enabled. In this case, the host may unconsciously use a VPN that does not support IPv6.

The subtle relationship between interaction and coexistence between IPv4 and IPv6 protocols in a dual-protocol stack network may be unintentional or intentional (deliberate attack) cause VPN leakage security problem-the traffic transmitted through the VPN connection may leak out of the VPN connection and be sent in plain text on the local network, without using the VPN service at all.

Interaction between IPv4 and IPv6

The coexistence of IPv4 and IPv6 protocols has some interesting and subtle aspects that may lead to unexpected consequences. Although IPv6 cannot be backward compatible with IPv4, these two protocols are "glued" together by the Domain Name System (DNS. For a dual-protocol stack system dependent on the name resolution service (such as the service provided by DNS), communication between the two systems cannot be guaranteed without protecting the two Protocols.

Many VPN deployments do not support the IPv6 protocol, or worse, they completely ignore IPv6. When a VPN connection is established, the VPN software usually inserts the IPv4 default route, so that all IPv4 traffic is sent through the VPN connection (instead of sending traffic in plain text by the local router ). However, if IPv6 is not supported, all data packets sent to IPv6 addresses are sent in plain text using the local IPv6 router. VPN software cannot protect IPv6 traffic security.

For example, assume that A website supports both IPv4 and IPv6, the corresponding domain name contains A and aaaa dns resource records (RR), and each A contains an IPv4 address, each AAAA contains an IPv6 address, and each of these record types can have multiple instances. When A two-protocol stack client application tries to communicate with the server, it can request A and aaaa rr and use any available address. The preferred address family (IPv4 or IPv6) and the specific address to be used (assuming that each family has multiple addresses available) are deployed differently, and many host deployment prefer the Pv6 address, instead of an IPv4 address.

Accidental and intentional VPN traffic Leakage

Assume there is a dual-stack host that uses only IPv4 VPN software to establish a VPN connection with the server. What happens if the host is connected to the dual-protocol stack network? If the application of the host tries to communicate with the dual-protocol stack system, this usually requires querying A and aaaa dns resource records. If the host supports both IPv4 and IPv6 connections, but prefers IPv6 addresses, even if the other system has A and aaaa dns resource records, all hosts use IPv6. If the VPN software does not support IPv6, IPv6 traffic will not be connected through a VPN, and it will be transmitted in plain text through the local IPv6 router.

This inadvertently exposes potential sensitive traffic, which should have been protected by VPN software. In this case, VPN leakage is the negative effect of using IPv6 software (VPN) not supported in the dual-protocol stack network.

RFC 6724 specifies an algorithm to select a destination address from the IPv6 and IPv4 address lists. RFC 6555 ("happy eye: success of Dual-protocol stack hosts") discusses the challenges faced by choosing the most appropriate destination address and recommends feasible deployment methods.

Accidental VPN traffic leakage is not the only concern of this issue. By pretending to be a local IPv6 router, a local attacker can send a forged ICMPv6 Router announcement message to deliberately trigger IPv6 connections on the affected host. These packets can be sent using standard software (such as rtadvd) or data packet writing tools (such as the IPv6 Toolkit. Once the IPv6 connection is enabled, communication with the dual-protocol stack system may cause VPN traffic leakage, as mentioned above.

Due to the increasing number of websites that support IPv6, this attack is feasible. However, traffic leakage only occurs when the target system uses a dual-protocol stack. However, it is not difficult to bring such VPN leaks to any target system. Attackers can simply send fake router notification messages (including the corresponding RDNSS options), pretend to be a cost-effective recursive DNS server, then execute DNS spoofing attacks to become middlemen, and intercept traffic. Data Packet writing tools (such as the IPv6 Toolkit) can easily perform such attacks when no data packet is leaked.

　VPN leakage mitigation

We can use a lot of mitigation measures to avoid VPN leakage in the dual-protocol stack network. The simplest way (though not necessarily the most desirable) is to disable IPv6 connections in all network interface cards When Using VPN connections. The application on the host running the VPN Client software can only use IPv4. Therefore, the VPN software should be prepared to protect its security.

The network can prevent local attackers from successfully performing the above attacks against other local hosts by deploying the first-Hop Security Model, such as RA-Guard and DHCPv6-Shield. However, it is obvious that when connected to an open network, hosts cannot rely on these mitigation measures. Remember that even if RA-Guard is deployed in a large number, it is vulnerable to leakage attacks.

Some may think that the most comprehensive mitigation should be to add IPv6 support to the VPN software and allow the VPN Server to provide IPv6 connections. Although this method is not feasible in many cases, it may be of some significance because IPv6 is automatically configured as a router (and also as an attacker) you can insert other route information in multiple ways. For example, attackers can still perform "Neighbor Discovery" attacks to cause IPv6 traffic leakage, such as sending fake ICMPv6 redirection messages and forging routing information options (for example, "More specific routing") routing broadcast, forged propaganda "high-priority" router routing broadcast, etc. Even if the VPN software supports IPv6, some VPN deployment may be vulnerable to such attacks in the short term.

　　Conclusion

The subtle interaction between IPv6 and IPv4 protocols, and (unfortunately) the established saying: If someone plans to deploy IPv6, security will be a problem and may cause adverse consequences, for example, unintentional VPN traffic leakage. Because most general operating systems use dual-protocol stacks, most networks have at least dual-protocol stacks, which means that the security impact of IPv6 cannot be ignored. The increasing demand for address space on the Internet will inevitably lead to widespread adoption and deployment of IPv6. Before adoption and deployment, enterprises should fully understand the corresponding security risks.