Author: Chase Snyder, Sr. PMM, Xage Security

The TunnelVision “VPN Vulnerability” (CVE-2024-3661) was disclosed in early May and is likely to generate more waves of news coverage over time as organizations fall victim to its exploitation. To avoid becoming one of those, you should check in with any VPN providers officially used by your company and make sure that they have already taken mitigation measures to assure they are not vulnerable.

You should also assure that your own organization is taking steps internally to insulate yourself from the risk posed by TunnelVision These mitigations include but are not limited to actions like:

• Ignoring DHCP Option 121 (the underlying insecure protocol option that makes this “VPN decloaking” vulnerability possible.
• Firewall configurations 
• Implementing network namespaces
• And miscellaneous others

These options have their own downsides, largely due to the way they affect network connectivity, performance, and technology management burden. In the short term, making sure you aren’t immediately vulnerable is important. 

On the other hand, some cybersecurity industry commentators are also claiming that the risks posed by TunnelVision are being exaggerated and sensationalized, and that most companies just shouldn’t worry about it. 

Our take is that you should probably just replace your VPN with something better. VPNs have somehow developed the reputation that they protect users, and their companies, in situations where the users are logging in remotely. Leviathan Security, the company that coined the moniker “TunnelVision” even suggested that companies should tell their employees to stop logging into work from coffee shops and airports over VPN due to this vulnerability.

In truth, VPNs weren’t built for security, and you shouldn’t rely on them for it. Many popular VPN products have been proven vulnerable, and have provided the initial access vector for ransomware gangs and nation state adversaries alike. 

The Ivanti VPN vulnerabilities were the most recent major disclosures resulting in the confirmed compromise of at least one U.S. Federal agency. Ivanti won’t be the last one. If you weren’t already looking into VPN replacement, you should strongly consider using a different option entirely, to reduce your remote access security risk. Whether TunnelVision is a risk to your organization or not, VPN is definitely not the best way to enable secure remote access for local or remote employees.

Who Is Vulnerable to TunnelVision?

Because this is not a vulnerability in a specific VPN technology, but a potential way to abuse an option in the DHCP protocol, any VPN that relies on DHCP could hypothetically be vulnerable. Many VPN providers, and other providers of remote access that do not use VPN technology, have published blog posts to reassure customers that they are not affected. 

At Xage, our first step upon the disclosure of TunnelVision was to make sure that our products are not vulnerable. They aren’t! No surprise, since we aren’t a VPN, but good to confirm anyway.

There’s a broader point to be made here about software supply chain security risk. The fact that vulnerable network protocols like DHCP underpin so many of the crucial technologies widely deployed in enterprises and critical infrastructure worldwide should be cause for concern.

As more and more important systems get built upon these aging and increasingly vulnerable underlying systems, it becomes clear why a zero trust approach to security is necessary. The number of newly revealed, difficult or impossible to patch vulnerabilities in systems that are deeply integrated into your business will only go up over time. You have to assume that the machines inside your environment are compromised, and put mitigations in place to prevent lateral movement BEFORE such a vulnerability is even disclosed. Don’t wait until the news is already out. The attackers won’t.

Key Insight from the TunnelVision Attack

The core mechanics of TunnelVision have been discussed at length in the original disclosure post from LeviathanSecurity, as well as in Wired Magazine and other publications, so we won’t rehash them here.

However, the sheer age of this vulnerability, and the fact that it is just now making serious headlines, is a topic that deserves a little more airtime. If this vulnerability has been around for 22 years, why didn’t anyone figure it out sooner?

The short answer is that they did. After Leviathan published their disclosure post and coined the name TunnelVision, various researchers pointed out that they had discussed the risk of attackers abusing DHCP option 121 since at least 2015. This points to the overall challenges of distributing information about security vulnerabilities. Just as it may take a long time to patch vulnerabilities even after they are disclosed, it can take a long time to even get the word out about the existence of a vulnerability so that patches can be created! 

It took almost a decade from when the first blog posts about this vulnerability came out, to when it got a name (“TunnelVision”) and a CVE designation. That is a long time that such a technique could be exploited against you before you take direct mitigation steps against it. This is the crux of why zero trust is so important. Zero Trust Access methodologies can mitigate unknown unknown risk, and future-proof your systems against vulnerabilities you haven’t even heard about yet.

What does this mean for security?

Risk can come from anywhere. When a 22 year old feature of a networking protocol can be discovered to underpin a high risk vulnerability affecting almost any VPN, it becomes clear that assessing external sources of risk ahead of time is not a complete security strategy. Software supply chain risk management is vital, but is only one piece of the puzzle. 

Protecting assets from the inside, so that even if a vulnerability like this is discovered, your own internal security controls minimize the impact, is a necessary mindset. This is the heart of the Zero Trust Model that has gained steam for the past decade.

How To Mitigate Remote Access Security Risks

Aside from making sure your VPN providers aren’t vulnerable to TunnelVision, you should move toward eliminating VPN from your environment entirely and using something else more secure. Any solution you pursue should have, at bare minimum, the following capabilities to reduce the impact if an attacker were to attempt to exploit a new vulnerability inside your network:

1. MFA for remote access – make sure that every access event to your network requires MFA challenges. Even when a user is already logged in, they should have to do another MFA challenge if they try to access additional more sensitive resources within the environment.
2. Distributed Password Vaulting – so that an attacker inside your environment can’t steal your credentials and use them for subsequent attacks, or to re-establish access after you block them out once.
3. Privileged Session Management so that each individual session can be recorded, managed, and terminated at the first signal of risky behavior.

To learn more, check out our eBook: Five Must Haves for Modernizing Remote Access