The SonicWall Capture Labs threat research team became aware of the Ivanti Connect Secure and Policy Secure Gateway authentication bypass vulnerability, assessed its impact and developed mitigation measures for the vulnerability.
Ivanti Connect Secure, formerly known as Pulse Connect Secure, is an SSL VPN (Virtual Private Network) solution designed to enable remote and mobile users to access corporate networks securely from any web-enabled device. Recently, an authentication bypass vulnerability has been identified in both Ivanti Connect Secure and Ivanti Policy Secure Gateways. This security flaw arises from insufficient validation of HTTP request paths within the software. Consequently, a remote attacker could potentially exploit this vulnerability by crafting a malicious HTTP request directed at the target server. If exploited successfully, this vulnerability could grant the attacker unauthenticated access to otherwise secure, authenticated web endpoints, posing a significant security risk to affected systems.
The list below concisely summarizes the Common Platform Enumeration (CPE) entries for Ivanti’s Connect Secure and Policy Secure products. It encompasses a range of versions and revisions, highlighting the extensive variety within the product lineup. The versions impacted are as follows:
- Ivanti Connect Secure:
- Version 9.0: Base, – , r1 – r6, r2.1, r3 – r3.5, r4 – r4.1, r5.0, r6.0
- Version 9.1: r1, r10 – r11.5, r12 – r12.1, r13 – r13.1, r14, r15 – r15.2, r16 – r16.1, r17 – r17.1, r18, r2 – r4.3, r5 – r9.1
- Version 22.1: r1, r6
- Version 22.2: -, r1
- Version 22.3: r1
- Version 22.4: r1, r2.1
- Version 22.5: r2.1
- Version 22.6: -, r1, r2
- Ivanti Policy Secure:
- Version 9.0: Base, – , r1 – r4
- Version 9.1: r1, r10 – r11, r12 – r13.1, r14, r15 – r16, r17 – r18, r2 – r4.2, r5 – r9.1
- Version 22.1: r1, r6
- Version 22.2: r1, r3
- Version 22.3: r1, r3
- Version 22.4: r1, r2, r2.1
- Version 22.5: r1, r2.1
- Version 22.6: r1
Each entry is formatted as “Version: Revision(s)”, where “-” indicates the base version and specific revisions are listed thereafter.
This security issue has been formally acknowledged and indexed in the Common Vulnerabilities and Exposures (CVE) system, explicitly identified as CVE-2023-46805 and CVE-2024-21887.
CVE-2023-46805 carries an overall CVSS score of 8.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N), highlighting its high severity. The score’s detailed composition indicates the vulnerability’s attributes and potential repercussions. It has a network-based attack vector, meaning the vulnerability can be exploited remotely, and its attack complexity is low, suggesting minimal effort is required for exploitation. It necessitates no special privileges, increasing its potential reach, and it doesn’t require user interaction, enhancing its stealth and potential for unnoticed exploitation. Although the scope of the attack is unchanged, the vulnerability critically endangers data confidentiality, implying a significant risk of sensitive data exposure. However, its impact on data integrity is low, and it does not affect data availability, suggesting that unauthorized data disclosure is more likely than data alteration or service disruption.
Contrastingly, CVE-2024-21887 presents an even more critical threat, evidenced by its CVSS score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). While this vulnerability shares certain characteristics with CVE-2023-46805 — such as a network-based attack vector and low attack complexity — it differs notably in its requirement for high privileges, indicating it affects more protected or sensitive areas. Like its counterpart, it operates covertly without user interaction. However, this vulnerability’s scope is classified as changed, hinting at a broader, more systemic impact. Its high ratings across confidentiality, integrity and availability underscore its potential for extensive harm, allowing attackers not only to access and modify sensitive data but also to significantly disrupt dependent services or applications.
An alarming authentication bypass vulnerability has been reported in Ivanti Connect Secure, attributed to superficial access checks on the unnormalized Request-URI in the web process. This flaw is notably present in Ivanti Connect Secure (versions 9.x, 22.x) and Ivanti Policy Secure, where a specifically crafted request with a Request-URI beginning with vulnerable paths such as “/api/v1/totp/user-backup-code/” or “/api/v1/cav/” can evade standard authentication protocols. This vulnerability arises due to the web process’s reliance on a vulnerable function that conducts basic string comparisons against predefined prefixes, allowing requests that match these paths to bypass authentication checks. The exploit hinges on manipulating the Request-URI, incorporating parent reference segments (e.g., “../”) to pivot to endpoints normally safeguarded by authentication. However, the exploit’s scope is somewhat contained due to session checks and the limited distribution of the REST API, restricting accessible endpoints to those managed by the receiving WSGI (Web Server Gateway Interface) process.
Further probing into the system’s architecture revealed a critical loophole in a custom web server developed in C++, integral to managing all incoming HTTPS requests and closely associated with Perl-based CGI scripts and the REST API. Situated within the system’s binary structure at ics_disk1/root/home/bin/web, this server serves not only as a gateway for HTTPS requests but also plays a pivotal role in the REST API’s functionality. Acting as a proxy, the server directs requests to the API as necessary, focusing heavily on authentication enforcement. However, the authentication mechanism is compromised by the server’s flawed URI processing method, which employs a strncmp function for path validation. This function’s limitation to checking only a set number of initial characters in the path creates a significant security gap. By crafting a path (see Figure 1) that initiates with a vulnerable endpoint and appending additional characters, attackers can navigate around the authentication, gaining unauthorized access to sensitive resources and functions within the system. This discovery underscores the urgency for a comprehensive overhaul of the security measures, particularly the methods for URI path validation and processing.
Figure 1: Example GET Request Path
The vulnerability in Ivanti Connect Secure related to authentication bypass can be triggered under certain conditions. Here are four key scenarios or factors that can lead to the exploitation of this vulnerability:
- Unnormalized Request-URIs: The vulnerability is exploited by sending a request with a Request-URI that starts with specific paths and has not been normalized, allowing the attacker to circumvent the expected URL structure and access controls.
- Prefix Matching in URL Paths: The web process performs shallow checks by comparing the raw Request-URI against a list of vulnerable prefixes. If the Request-URI matches one of the known vulnerable paths, such as “/api/v1/totp/user-backup-code/” or “/api/v1/cav/”, the request is allowed to pass through without proper authentication.
- Use of Directory Traversal Techniques: The attacker can employ directory traversal techniques using “../” notation in the Request-URI. This allows the attacker to pivot from the allowed prefix to another endpoint that normally requires authentication, effectively bypassing the access control checks.
- Limited Endpoint Scope Due to Distributed REST API: While the vulnerability allows pivoting to different endpoints, the scope of accessible endpoints is limited to those implemented by the receiving WSGI process. However, this still poses a significant risk as it exposes certain endpoints of the REST API to unauthenticated access.
Developed with Flask, a Python-based, lightweight, and flexible web framework, a Flask application simplifies starting and scales up to complex commercial sites, providing an array of tools, libraries, and technologies. Despite its benefits, Flask applications can exhibit vulnerabilities, such as the command injection flaw in the License class of restservice/api/resources/license.py which manages requests for the /api/v1/license/keys-status endpoint. This vulnerability arises from the get method’s improper concatenation of command strings, especially when handling the node_name parameter, enabling attackers to execute arbitrary commands via subprocess.Popen.
Leveraging Flask’s automatic mapping of URL endpoints to function parameters, attackers can send crafted GET requests to redirect to vulnerable endpoints with command injection payloads, with URL encoding complicating the attack by allowing the transmission of intricate payloads. Although these vulnerabilities present substantial security risks, it is notable that vendor-supplied mitigations effectively counteract these exploits. Notably, this vulnerability allows attackers to achieve unauthenticated command injection by sending a GET request to the following URI path where CMD is any arbitrary Linux OS (Operating System) command, presenting a significant security concern.
Figure 2: URI path
Figure 3: Python Source Code for Arbitrary Linux OS Reverse Shell
Given the scenario of exploiting a command injection vulnerability (Figure 5) at the endpoint seen in Figure 4.
Figure 4: Endpoint
Figure 5: Reverse Shell URI Path
This one-liner Python command (Figure 5) is crafted to establish a reverse shell from the target server to the attacker’s machine. This command, when appended to the vulnerable endpoint, would be executed on the server due to the vulnerability. The Python script, starting with a semicolon to signify the end of a previous command, is a compact and potent snippet designed to create a socket connection back to the attacker’s machine (at IP address 192.168.2.200 and port 5555).
Once the connection is established, it spawns a shell and redirects the shell’s standard input, output and error streams to the socket, effectively tying the shell to the attacker’s console.
This provides the attacker with interactive control over the shell on the target machine. However, for this command to be successfully processed and interpreted by the web server and not get blocked by URL parsing mechanisms, it must be URL-encoded before being sent in the GET request to the vulnerable endpoint. URL encoding transforms potentially unsafe ASCII characters into a format that can be transmitted over the internet, ensuring the payload is delivered intact to the server for execution
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:
- IPS:4234 Ivanti Connect Secure Authentication Bypass
- IPS:19611 Ivanti Connect Secure Command Injection 1
- IPS:19612 Ivanti Connect Secure Command Injection 2
The risks posed by this vulnerability can be mitigated or eliminated by:
- Applying the vendor-supplied patch to eliminate this vulnerability.
- Utilizing up to date IPS signatures to filter network traffic.
- Configure the vulnerable product to allow access to trusted clients only.