{"id":25073,"date":"2024-08-14T16:01:38","date_gmt":"2024-08-15T00:01:38","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2024\/08\/14\/news-18803\/"},"modified":"2024-08-14T16:01:38","modified_gmt":"2024-08-15T00:01:38","slug":"news-18803","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2024\/08\/14\/news-18803\/","title":{"rendered":"Chained for attack: OpenVPN vulnerabilities discovered leading to RCE and LPE"},"content":{"rendered":"

Credit to Author: Microsoft Threat Intelligence| Date: Thu, 08 Aug 2024 18:00:00 +0000<\/strong><\/p>\n

Microsoft researchers recently identified multiple medium severity vulnerabilities in OpenVPN, an open-source project with binaries integrated into routers, firmware, PCs, mobile devices, and many other smart devices worldwide, numbering in the millions. Attackers could chain and remotely exploit some of the discovered vulnerabilities to achieve an attack chain consisting of remote code execution (RCE) and local privilege escalation (LPE). This attack chain could enable attackers to gain full control over targeted endpoints, potentially resulting in data breaches, system compromise, and unauthorized access to sensitive information. Exploiting these vulnerabilities, however, necessitates user authentication and a deep understanding of OpenVPN’s inner workings, alongside intermediate knowledge of the operating systems. Today, we presented this research and demonstrated the discovered attack chain in our session at Black Hat USA 2024<\/a>.<\/p>\n

OpenVPN is widely used by thousands<\/a> of companies spanning various industries across major platforms such as Windows, iOS, macOS, Android, and BSD. As such, exploitation of the discovered vulnerabilities, which affect all versions of OpenVPN prior to version 2.6.10<\/a> (and 2.5.10<\/a>), could put endpoints and enterprises at significant risk of attack.<\/p>\n

We reported the discovery to OpenVPN through\u00a0Coordinated Vulnerability Disclosure<\/a>\u00a0(CVD) via\u00a0Microsoft Security Vulnerability Research<\/a>\u00a0(MSVR) in March 2024 and worked closely with OpenVPN to ensure that the vulnerabilities are patched. Information on the security fixes released by OpenVPN to address these vulnerabilities can be found here: OpenVPN 2.6.10<\/a>. We strongly urge OpenVPN users to apply the latest security updates<\/a> as soon as possible. We also thank OpenVPN for their collaboration and recognizing the urgency in addressing these vulnerabilities. <\/p>\n

Below is a list of the discovered vulnerabilities discussed in this blog:<\/p>\n

\n\n\n\n\n\n\n\n\n
CVE ID<\/strong><\/td>\nOpenVPN component<\/strong><\/td>\nImpact<\/strong><\/td>\nAffected platform<\/strong><\/td>\n<\/tr>\n
CVE-2024-27459<\/a><\/td>\nopenvpnserv                             <\/td>\nDenial of service (DoS), local privilege escalation (LPE)<\/td>\nWindows<\/td>\n<\/tr>\n
CVE-2024-24974<\/a><\/td>\nopenvpnserv                             <\/td>\nUnauthorized access <\/td>\nWindows<\/td>\n<\/tr>\n
CVE-2024-27903<\/a><\/td>\nopenvpnserv<\/td>\nRemote code execution (RCE)<\/td>\nWindows<\/td>\n<\/tr>\n
Local privilege escalation (LPE), data manipulation<\/td>\nAndroid, iOS, macOS, BSD<\/td>\n<\/tr>\n
CVE-2024-1305<\/a><\/td>\nWindows TAP driver <\/td>\nDenial of service (DoS) <\/td>\nWindows<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

In this blog post, we detail our analysis of the discovered vulnerabilities and the impact of exploitation. In addition to patching, we provide guidance to mitigate and detect threats attempting to exploit these vulnerabilities. This research emphasizes the need for responsible disclosure and collaboration among the security community to defend devices across platforms and build better protection for all, spanning the entire user-device ecosystem. The discovery of these vulnerabilities further highlights the critical importance of ensuring the security of enterprise and endpoint systems and underscores the need for continuous monitoring and protection of these environments.<\/p>\n

What is OpenVPN?<\/h2>\n

OpenVPN is a virtual private network (VPN) system that creates a private and secure point-to-point or site-to-site connection between networks. The OpenVPN open-source project is widely popular across the world, including the United States, India, France, Brazil, the United Kingdom, and Germany, as well as industries spanning the information technology, financial services, telecommunications, and computer software sectors. This project supports different major platforms and is integrated into millions of devices globally.<\/p>\n

OpenVPN is also the name of the tunneling protocol it uses, which employs the Secure Socket Layer (SSL) encryption protocol to ensure that data shared over the internet remains private, using AES-256 encryption. Since the source code is available for audit, vulnerabilities can be easily identified and fixed.<\/p>\n

OpenVPN analysis<\/h2>\n

We discovered the vulnerabilities while examining the OpenVPN open-source project to enhance enterprise security standards. During this research, we checked two other popular VPN solutions and found that at the time they were impacted by a vulnerability (CVE-2024-1305). Following this discovery, we started hunting for and uncovered additional vulnerable drivers with the same issue and decided to investigate open-source VPN projects. Upon confirming that the same vulnerability was located in the OpenVPN open-source repository, our research then focused on examining the architecture and security model of the OpenVPN project for Windows systems.<\/p>\n

OpenVPN architecture<\/h3>\n

OpenVPN server client architecture<\/h4>\n

OpenVPN is a sophisticated VPN system meticulously engineered to establish secure point-to-point or site-to-site connections. It supports both routed and bridged configurations, as well as remote access capabilities, making it a versatile choice for various networking needs. OpenVPN comprises both client and server applications, ensuring a comprehensive solution for secure communication.<\/p>\n

With OpenVPN, peers can authenticate each other through multiple methods, including pre-shared secret keys, certificates, or username\/password combinations. In multi-client server environments, the server can generate and issue an individual authentication certificate for each client, leveraging robust digital signatures and a trusted certificate authority. This ensures an elevated level of security and integrity in the authentication process, enhancing the overall reliability of the VPN connection. <\/p>\n

\"Diagram
Figure 1. OpenVPN client server model<\/a><\/em><\/figcaption><\/figure>\n

Client-side architecture<\/h3>\n

The client-side architecture is where we discovered the additional three vulnerabilities (CVE-2024-27459, CVE-2024-24974, and CVE-2024-27903):<\/p>\n

OpenVPN\u2019s client architecture can be summarized in the following simplified diagram:<\/p>\n

\"Diagram
Figure 2. OpenVPN client architecture with loaded plugin.dll<\/em><\/figcaption><\/figure>\n

openvpnserv.exe<\/em> and openvpn.exe<\/em><\/h4>\n

The system service launches elevated commands on behalf of the user, handling tasks such as adding or deleting DNS configurations, IP addresses, and routes, and enabling Dynamic Host Configuration Protocol (DHCP). These commands are received from the openvpn.exe<\/em> process through a named pipe created for these two entities, such as \u201copenvpn\/service_XXX\u201d where XXX is the thread ID (TID) that is being passed to the newly created process as a command line argument.<\/p>\n

The launched commands arrive in the form of a binary structure that contains the relevant information for the specific command, with the structure being validated and only then launching the appropriate command. The below figure displays an example of the structure that contains information for adding\/deleting DNS configuration:<\/p>\n

\"Screenshot
Figure 3. OpenVPN DNS configuration managing structure<\/em><\/figcaption><\/figure>\n

Additionally, openvpnserv.exe<\/em> serves as the management unit, spawning openvpn.exe<\/em> processes upon requests from different users on the machine. This can be done automatically using the OpenVPN GUI or by sending specifically crafted requests. Communication for this process occurs through a second named pipe, such as \u201copenvpn\/service\u201d.<\/p>\n

Openvpn<\/em>.exe<\/em> is the user mode process being spawned on behalf of the client. When openvpn.exe<\/em> starts, it receives a path for a configuration file (as a command line argument). The configuration file that\u2019s provided holds different information.<\/p>\n

A lot of fields can be managed in configuration files<\/a>, such as:<\/p>\n

    \n
  1. Tunnel options<\/li>\n
  2. Server mode options<\/li>\n
  3. Client mode options<\/li>\n<\/ol>\n

    Plugin mechanism in openvpn.exe<\/em><\/h4>\n

    Another mechanism of interest for us is the plugin mechanism in openvpn.exe<\/em>, which can extend the functionality to add additional logic, such as authentication plugins to bring authentication against Lightweight Directory Access Protocol (LDAP) or Radius or other Pluggable Authentication Module
    (PAM) backends. Some of the existing plugins are:<\/p>\n

      \n
    1. Radiusplugin \u2013 Radius authentication support for open OpenVPN.<\/li>\n
    2. Eurephia \u2013 Authentication and access control plugin for OpenVPN.<\/li>\n
    3. Openvpn_defer_auth \u2013 OpenVPN plugin to perform deferred authentication requests.<\/li>\n<\/ol>\n

      The plugin mechanism fits into the earlier diagram, as shown in Figure 2.<\/p>\n

      The plugin is loaded as a directive in the configuration file, which looks like:<\/p>\n

      \"Screenshot
      Figure 4. OpenVPN client directive to load plugin<\/em><\/figcaption><\/figure>\n

      Furthermore, the number of callbacks<\/a> defined in the plugin launch on behalf of the loading process (openvpn.exe<\/em>), such as:<\/p>\n

        \n
      1. openvpn_plugin_func_v1<\/em> – This function is called by OpenVPN each time the OpenVPN reaches a point where plugin calls should happen.<\/li>\n
      2. openvpn_plugin_{open, func}_v3()<\/em> \u2013 Defines the version of the v3 plugin argument.<\/li>\n<\/ol>\n

        OpenVPN security model<\/h3>\n

        As previously mentioned, we discovered four vulnerabilities on the client side of OpenVPN\u2019s architecture.<\/p>\n

        As described before, openvpnserv.exe<\/em> (SYSTEM service) spawns the openvpn.exe<\/em> process as a result of the request from the user. Furthermore, the spawned process runs in the context of the user who requested to create the new process, which is achieved through named pipe impersonation<\/a>, as displayed in the below image:<\/p>\n

        \"Screenshot
        Figure 5. Named pipe impersonation<\/em><\/figcaption><\/figure>\n

        The ImpersonateNamedPipeClient<\/em> function impersonates<\/a> a named pipe client application.<\/p>\n

        Furthermore, to prevent unwanted behavior, specific EXPLICIT_ACCESS must be granted for any new process:<\/p>\n

        \"Screenshot
        Figure 6. Explicit access for OVPN DACL<\/em><\/figcaption><\/figure>\n

        This explicit access, in addition to the earlier described \u201celevated commands\u201d launched by openvpnserv.exe<\/em> on request from the openvpn.exe<\/em> process, and other comprehensive inspection of the passed arguments  ensure that malicious behavior cannot be launched in the name of the impersonated user.<\/p>\n

        Vulnerability analysis<\/h2>\n

        CVE-2024-1305    <\/h3>\n

        We identified a vulnerability in the “tap-windows6” project that involves developing the Terminal Access Point (TAP) adapter used by OpenVPN. In the project’s src<\/em> folder, the device.c<\/em> file contains the code for the TAP device object and its initialization.<\/p>\n

        In the device.c<\/em> file, the CreateTapDevice<\/em> method initializes a dispatch table object with callbacks for methods managing various Input\/Output Controls (IOCTLs) for the device. One of these methods is TapDeviceWrite<\/em>, which handles the write IOCTL.<\/p>\n

        \"Screenshot
        Figure 7. Wild kernel overflow vulnerability location<\/em><\/figcaption><\/figure>\n

        The TapDeviceWrite<\/em> method performs several operations and eventually calls TapSharedSendPacket<\/em>. This method, in turn, calls NdisAllocateNetBufferAndNetBufferLists<\/em> twice. In one scenario, it calls this function with the fullLength<\/em> parameter, defined as follows:<\/p>\n

        \"Screenshot
        Figure 8. Integer overflow<\/em><\/figcaption><\/figure>\n

        Both PacketLength<\/em> and PrefixLength<\/em> are parameters passed from the TapDeviceWrite<\/em> call and, therefore, attacker controlled. If these values are large enough, their sum (fullLength<\/em>) can overflow (a 32-bit unsigned integer). This overflow results in the allocation of a smaller-than-expected memory size, which subsequently causes a memory overflow issue.<\/p>\n

        CVE-2024-27459  <\/h3>\n

        The second vulnerability that we discovered resided in the communication mechanism between the openvpn.exe<\/em> process and the openvpnserv.exe<\/em> service. As described earlier, both of which communicate through a named pipe:<\/p>\n

        \"Screenshot
        Figure 9. Reading size from a named pipe<\/em><\/figcaption><\/figure>\n

        The openvpnserv.exe<\/em> service will read the message size in an infinite loop from the openvpn.exe<\/em> process and then handle the message received by calling the HandleMessage<\/em> method. The HandleMessage<\/em> method reads the size provided by the infinite loop and casts the read bytes into the relevant type accordingly:<\/p>\n

        \"Screenshot
        Figure 10. Stack overflow vulnerability location<\/em><\/figcaption><\/figure>\n

        This communication mechanism presents an issue as reading the \u201cuser\u201d provided number of bytes on to an \u201cn bytes\u201d long structure located on the stack will produce a stack overflow vulnerability.<\/p>\n

        CVE-2024-24974  <\/h3>\n

        The third vulnerability involves unprivileged access to an operating system resource. The openvpnserv.exe<\/em> service spawns a new openvpn.exe<\/em> process based on user requests received through the \u201c\\openvpn\\service\u201d named pipe. This vulnerability allows remote access to the named service pipe, enabling an attacker to remotely interact with and launch operations on it.<\/p>\n

        CVE-2024-27903  <\/h3>\n

        Lastly, we identified a vulnerability in OpenVPN’s plugin mechanism that permits plugins to be loaded from various paths on an endpoint device. This behavior can be exploited by attackers to load harmful plugins from these different paths.<\/p>\n

        Exploiting and chaining the vulnerabilities<\/h2>\n

        All the identified vulnerabilities can be exploited once an attacker gains access to a user’s OpenVPN credentials, which could be accomplished using credential theft techniques, such as purchasing stolen credentials on the dark web, using info-stealing malware, or sniffing network traffic to capture NTLMv2 hashes and then using cracking tools like HashCat or John the Ripper to decode them. The discovered vulnerabilities could then be combined to achieve different exploitation results, or chained together to form a sophisticated attack chain, as detailed in the below sections.<\/p>\n

        RCE exploitation<\/h3>\n

        We first explored how an attacker could achieve remote code execution (RCE) exploitation using CVE-2024-24974 and CVE-2024-27903.<\/p>\n

        To successfully exploit these vulnerabilities and achieve RCE, an attacker must first obtain an OpenVPN user\u2019s credentials. The attacker\u2019s device must then launch the NET USE<\/em><\/a> command with the stolen credentials to remotely access the operating system resources and grant the attacker access to the named pipes objects devices.<\/p>\n

        Next, the attacker can send a \u201cconnect\u201d request to the \u201c\\openvpn\\service\u201d named pipe to launch a new instance of openvpn.exe<\/em> on its behalf.<\/p>\n

        \"Screenshot
        Figure 11. Initializing OpenVPN from a remote location (in which {TARGET_MACHINE_PLACEHOLDER} can be substituted by a different end point)<\/em><\/figcaption><\/figure>\n

        In the request, a path to a configuration file (\\\\DESKTOP-4P6938I\\share\\OpenVPN\\config\\sample.ovpn<\/em>) is specified that\u2019s located on the attacker-controlled device. A log path is also provided into which the loaded plugin will write its logs (“–log \\\\{TARGET_MACHINE_PLACEHOLDER}<\/em>\\share\\OpenVPN\\log\\plugin_log.txt<\/em>).<\/p>\n

        The provided configuration has instructions to load malicious plugin, as such:<\/p>\n

        \"Screenshot
        Figure 12. Malicious plugin loading directive from a remote location<\/em><\/figcaption><\/figure>\n

        After successful exploitation, the attacker can read the log provided on the attacker-controlled device.<\/p>\n

        \"Screenshot
        Figure 13. Plugin log on the attacker-controlled device<\/em><\/figcaption><\/figure>\n

        LPE exploitation<\/h3>\n

        Next, we investigated how an attacker could achieve local privilege execution (LPE) using CVE-2024-27459 and CVE-2024-27903. To successfully achieve an LPE exploit in this context, an attacker must load a malicious plugin into the normal launching process of openvpn.exe<\/em> by using a malicious configuration file.<\/p>\n

        First, the attacker will connect to a local device \u201c\\openvpn\\service\u201d named pipe with a command that instructs openvpnserv.exe<\/em> to launch openvpn.exe<\/em> based on the attacker-provided malicious configuration.<\/p>\n

        \"Screenshot
        Figure 14. Initializing OpenVPN from a local configuration<\/em><\/figcaption><\/figure>\n

        The malicious configuration will include a line like the below example:<\/p>\n

        \"Screenshot
        Figure 15. Malicious plugin loading directive from the local location<\/em><\/figcaption><\/figure>\n

        For the malicious plugin to successfully communicate with openvpnserv.exe,<\/em> it must hijack the number of the handle used by openvpn.exe<\/em> to communicate with the inner named pipe connecting the openvpv.exe<\/em> process and the openvpnserv.exe <\/em>service. This can be achieved, for instance, by parsing command line arguments, as displayed below:<\/p>\n

        \"Screenshot
        Figure 16. Parsing command line arguments to extract the thread ID (TID)<\/em><\/figcaption><\/figure>\n

        This works because when the openvpn.exe<\/em> process spawns, it\u2019s being passed the TID (as a command line argument) that the inner named pipe (which is being used for communication between this specific OpenVPN instance and the openvpnserv.exe<\/em> service) will have. For instance, if the inner named pipe created is \u201c\\openvpn\\service_1234\u201d then openvpn.exe<\/em> will be launched with an extra argument of 1234.<\/p>\n

        \"Screenshot
        Figure 17. Passing the TID as a command line argument<\/em><\/figcaption><\/figure>\n

        Next, attackers can exploit the stack overflow vulnerability by sending data bigger than the MSG structure. It is important to note that there are stack protection mechanisms in place, called stack canaries<\/a>, which make exploitation much more challenging. Thus, when triggering the overflow:<\/p>\n

        \"Screenshot
        Figure 18. Stack overflow triggered<\/em><\/figcaption><\/figure>\n

        After the crash of openvpnserv.exe<\/em>, the attacker has a slot of time in which they can reclaim the named pipe \u201c\\openvpn\\service\u201d.<\/p>\n

        If successful, the attacker then poses as the server client side of the named pipe \u201c\\openvpn\\service\u201d. From that moment on, every attempt to connect to the \u201c\\openvpn\\service\u201d named pipe will result in a connection to the attacker. If a privileged enough user, such as a SYSTEM or Administrator user, is connected to the named pipe, the attacker can impersonate that user:<\/p>\n

        \"Screenshot
        Figure 19. Impersonating a privileged user<\/em><\/figcaption><\/figure>\n

        The attacker can then start an elevated process on the user\u2019s behalf, thus achieving LPE.<\/p>\n

        Chaining it all together<\/h3>\n

        As our research demonstrated, an attacker could leverage at least three of the four discovered vulnerabilities to create exploits to achieve RCE and LPE, which could then be chained together to create a powerful attack chain.<\/p>\n

        A number of adjustments are needed for the full attack chain to be exploited as presented in this blog post, mainly the malicious payload that crashes openvpnserv.exe<\/em> and the malicious payload that actually behaves as openvpnserv.exe<\/em> after openvpnserv.exe<\/em> is crashed all have to be loaded with the malicious plugin. After successfully achieving LPE, attackers will use different techniques, such as Bring Your Own Vulnerable Driver (BYOVD)<\/a> or exploiting known vulnerabilities, to achieve a stronger grasp of the endpoint. Through these techniques, the attacker can, for instance, disable Protect Process Light (PPL) for a critical process such as Microsoft Defender or bypass and meddle with other critical processes in the system. These actions enable attackers to bypass security products and manipulate the system’s core functions, further entrenching their control and avoiding detection.<\/p>\n

        Critical importance of endpoint security in private and enterprise sectors<\/h2>\n

        With OpenVPN being widely used across various vendors, industries, and fields, the presented vulnerabilities may impact numerous sectors, device types, and verticals. Exploiting these vulnerabilities requires user authentication, a deep understanding of OpenVPN\u2019s inner workings, and intermediate knowledge of the operating system. However, a successful attack could significantly impact endpoints in both the private and enterprise sectors. Attackers could launch a comprehensive attack chain on a device using a vulnerable version of OpenVPN, achieving full control over the target endpoint. This control could enable them to steal sensitive data, tamper with it, or even wipe and destroy critical information, causing substantial harm to both private and enterprise environments.<\/p>\n

        The discovery of these vulnerabilities underscores the importance of responsible disclosure to secure enterprise and endpoint systems, in addition to the collective efforts of the security community to protect devices across various platforms and establish stronger safeguards for everyone. We would like to again thank OpenVPN for their partnership and swift action in addressing these vulnerabilities.<\/p>\n

        Mitigation and protection guidance<\/h2>\n

        OpenVPN versions prior to 2.5.10 and 2.6.10 are vulnerable to discussed vulnerabilities.<\/p>\n

        It is recommended to first identify if a vulnerable version is installed and, if so, immediately apply the relevant patch found here: OpenVPN 2.6.10<\/a>.<\/p>\n

        Additionally, follow the below recommendations to further mitigate potential exploitation risks affiliated with the discovered vulnerabilities:<\/p>\n