A virtual return to Black Hat 2020
20 July 2020
The trouble with Secure Remote Access
Is Secure Remote Access really secure?
On this page, we will share research we conducted into the efficacy of commercial Secure Remote Access (or ‘VPN’) solutions in the face of modern mobile worker use cases, typical endpoint technologies, and contemporary threat models.
As millions of users worldwide work from home and depend on VPN technologies to access corporate systems and data, we explore the question of security for corporate endpoints on untrusted networks and examines the role that VPN technology can be expected to play in ensuring the protection of those devices and the data they generate.
We examine the question of what security we as users probably expect from VPN software, then methodically examine several enterprise VPN implementations to determine if we’re really getting what we thing.
In short:
Virtual Private Networks - are they enough?
This page serves as an appendix to a research paper that Orange Cyberdefense presented at BlackHat Briefings USA on 6 August 2o2o.
As the research involved substantial and ongoing engagement with several ‘VPN’ technology vendors, the results of the study are expected to change on a regular basis. To keep the information current we will share the latest results data and other updates, along with copies of the presentation, whitepaper and demo videos, on this page.
If Secure Remote Access is the logical extension of a private network to another location, and if we assume that the ‘other location’ is a Wi-Fi network that is either compromised or malicious, how much protection do enterprise remote access products provide against common threats we could reasonably expect to encounter?
Results overview
This table summarizes the findings of our research as on 6th August 2020, representing pass/fail results of 4 products, in 4 different scenarios, against 6 different technical attacks.
On the x-axis you find the different products, the y-axis shows the attack scenarios.
Red means the attack could be successfully executed, green means that the attack could be prevented by the VPN.
The general pattern shows a clear tendency: while most (yet not all) attacks could be prevented in online/lockdown mode there is virtually no protection at all in offline/standard mode.
On the rest of this page you will find:
- Resources and updates
- A note on terminology
- Background - Is Secure Remote Access really secure?
- Research - Virtual Private Networks - are they enough?
- What do we expect a VPN to do?
- Attack scenarios
- Test Environment
- Results overview
- Demo videos
If you have any questions or comments please contact us via charl.vanderwalt[at]orangecyberdefense.com
Resources and updates
Whitepaper
06 August 2020
Download the detailed technical report here.
Frequently Asked Questions
06 August 2020
Find answers to common questions about our research and findings.
Security Weekly Hacker Summer Camp
03 August 2020
View our interview with Paul Asadoorian of the Security Weekly Podcast on their virtual 'Hacker Summer Camp' show for Black Hat 2020.
Black Hat presentation page
06 August 2020
Visit the summary and details of of our presentation at Black Hat 2020.
Palo Alto Networks Security Advisory
06 August 2020
Palo Alto Networks has released advisory PAN-SA-2020-0009 - 'Informational: Mitigating threats for GlobalProtect clients connecting from untrusted networks'.
Summary from the ITWeb Security Summit
31 August 2020
ITWeb Magazine has published a summary of our research after we presented it at the ITWeb Security Summit in August'.
What do we expect a VPN to do?
Virtual Private Networks fulfill a kind of hybrid role between the networking and security domains. To a large extent the technology simply facilitates access to internal network resources. There is entrenched in this use-case, however, a set of security requirements that enable the connection to occur ‘privately’ as the name suggests.
Certainly we expect the data transmitted between an endpoint and the target to be appropriately encrypted, resistant to tampering and operational when required, but this seems insufficient to describe the full set of capabilities required to allow a remote user to operate on the internal network with the same level of security as a user connected to the LAN.
A note on terminology
This page examines the security properties of a class of technologies we will refer to primarily as ‘Virtual Private Networks’ or ‘VPN’. As our business is a significant seller and implementer of security technologies, we feel it is fair to say that this term accurately captures the class of tooling we are exploring. Indeed, it is used by some of the vendors we examine to describe themselves. The term ‘VPN’ is used much more broadly than this, however, and expands to (even originates in) enterprise networking constructs like site-to-site links and MPLS ‘virtual private LAN’ and ‘virtual private routed network’, services among others. Our research and this page do not examine the technologies deployed under this broader definition of the term ‘VPN’.
Another term used to describe the technologies we’re discussing is ‘Secure Remote Access’ or ‘Remote Access Security’. Once again, this term is widely used to describe the technologies we’re discussing here but also stretches to encompass a different class of technologies that are used to remotely access desktops directly over a network. Again, this latter group is not what we are discussing here.
This research presented on this page discusses ‘Virtual Private Network’ or ‘Secure Remote Access’ technologies that allow a remote user on an endpoint device like a laptop or tablet to connect into a corporate environment over an untrusted network like the Internet by enforcing authentication and creating an encrypted virtual tunnel between an agent on the computer and a gateway deployed on the perimeter of the network.
For the purpose of this research we propose that the expectation corporate users have of VPN technologies can be expressed in terms of the idea of ‘equivalency
When faced with security threats a roaming worker connected remotely via VPN would expect ‘equivalent’ protection to a user connected directly to the corporate LAN.
By this definition we would argue that any scenario under which a VPN-connected computer is more vulnerable to a form of attack than its LAN-connected counterpart, constitutes a security failure of the VPN.
It should be clear that a ‘security failure’ by this definition does not constitute an urgent exploitable vulnerability. We assert however that such failures in security are important to understand for security to assured. Moreover, we will demonstrate with our Proof of Concept videos below that some of these failures may in fact translate to technical vulnerabilities that can be exploited with significant downstream implications for enterprise security.
Attack scenarios
For this research, its important to understand the basic threats against confidentiality, integrity and access control that the VPN is supposed to protect the typical corporate user against. We focused on the following:
Sniffing sensitive data
Extracting sensitive information like login credentials from the data traffic.
DNS ‘person in the middle’ (PiTM) or spoofing
The attacker feeds fake DNS responses to legitimate requests from the client, thereby controlling where the subsequent connection ultimately terminates. This is a precursor to several other attacks, like spoofed websites.
Harvesting credentials using spoofed website
Once the attacker controls DNS and routing (as they would with a malicious AP) they can present the user with a fake login page to valuable resources like O365 to harvest login credentials.
Capturing Windows hashes via responder
‘Responder’ attacks involve tricking Windows systems into connecting to a fake Windows service, which in turn requests authentication and then captures the password hash that is sent. This enables further attacks against Active Directory.
Using the Browser as a tunnelling proxy
Once the attacker controls DNS and routing (with a malicious Access Point) they can inject code into legitimate websites to exert remote control over the victim’s computer, eg.using it as a pivot point to tunnel traffic into the corporate network.
Using IPv6 to interact with host
Most enterprise VPN technologies are designed to protect IPv4 traffic, but many endpoints now also run IPv6 stacks that can be used to communicate on the LAN and internet. If the VPN doesn’t control IPv6, that presents the attacker with an open channel for communicating with the computer.
Test Environment
A standard network configuration was used to test all the VPN products included in this study. The simple network is displayed below. The important element to note is that the Access Point (and therefore the Captive Portal) is under the control of the malicious actor, who is therefore also in a position to sniff or inject traffic onto the Wi-Fi network where the victim is connected.
Summary of Vendor Features
Results Standard-mode:
Results Lockdown-mode:
Demo 1
Malware changes search suffix to make a Wi-Fi Access Point Malicious
In this simple demonstration we want to illustrate the point that the risks we highlight in our research are not just limited to Captive Portal environments, but can be directly applied to compromise home Wi-Fi environments also, and potentially at significant scale.
The video shows a simple script attacking a standard off-the-shelf home Wi-Fi router via brute-force, then over-writing the DHCP configuration so that the ‘DNS Search Suffix’ is changed to a domain controlled by the attacker.
With this change any attempt to access an unqualified host name (host name without a full DNS domain suffix (as is commonly found within corporate environments) will lead to the resulting connection being directed to a server under the attacker’s control, where the Windows password hash can be stolen or used by the attacker.
Demo 2
Windows credential harvesting from a computer on a captured portal
This test demonstrates that there exists a possibility to capture credentials that could be used impersonate the victim. We explore what role a VPN client plays that is configured as ‘always-on’ to accommodate captive portals.
The demonstration assumes that the remote user has joined the captive portal Wi-Fi access point and they have not yet gained Internet access. This also implies that the VPN is not yet active.
Demo 3
Tunneling over a VPN using the Captive Portal and Javascript
This test demonstrates a theoretical risk, showing that there exists the possibility to use the browser of a remote user to access resources on the corporate LAN. The demonstration assumes that the remote user uses a full tunnel VPN with controls that let it interact with a captive portal.
A special JavaScript resource, called a BeEF hook, is injected into the web session of the remote user before the VPN tunnel is fully established. The BeEF hook will remain active if the browser tab stays open and the user does not browse away to another site. Once the tunnel is established the client’s DNS cache is flushed (by the VPN) but the attacker uses the same host name advertised via public DNS to continue controlling the Javascript hook.
Once connected the VPN will allow the BeEF hook to perform some mundane interactions with resources on the corporate network.
We argue that the captive portal scenario we sketch also holds for a compromised home Wi-Fi router.
