Two zero-day vulnerabilities have been discovered in Ivanti Secure VPN, a popular VPN solution used by organizations worldwide. The vulnerabilities are currently being exploited in the wild by at least one Chinese nation-state threat actor dubbed UTA0178. The chaining of the two vulnerabilities allow any attacker to execute remote code without any authentication and compromise affected systems.
What are the Ivanti Secure VPN zero-day vulnerabilities?
Ivanti published an official security advisory and knowledge base article about two zero-day vulnerabilities, CVE-2023-46805 and CVE-2024-21887, affecting all supported versions of Ivanti Connect Secure (previously known as Pulse Connect Secure) and Ivanti Policy Secure Gateways.
- CVE-2023-46805 is an authentication bypass vulnerability in the web component of Ivanti Connect Secure and Ivanti Policy Secure. It allows an attacker to access restricted resources by bypassing control checks.
- CVE-2024-21887 is a command injection in web components of Ivanti Connect Secure and Ivanti Policy Secure. It allows an authenticated administrator to send specially crafted requests and execute arbitrary commands on the appliance and can be exploited via the internet.
When combined, these two vulnerabilities allow an attacker to run commands on affected appliances.
Patrice Auffret, founder, chief executive officer and chief technology officer at ONYPHE, a French cyber defense search engine dedicated to attack surface discovery and attack surface management, told TechRepublic in an email interview earlier today that 29,664 Ivanti Secure VPN appliances are connected to the internet, with more than 40% of the exposed systems being in the U.S., followed by Japan (14.3%) and Germany (8.48%) (Figure A).
Figure A
![Ivanti Secure VPN unique IP addresses on the internet.](jpg/tr_20240112-volexity-ivanti-connect-secure-vpn-vulnerabilities-figure_a-770x628.jpg)
Exploitation of these zero-day vulnerabilities in the wild
U.S.-based cybersecurity company Volexity discovered both vulnerabilities during an incident response investigation across multiple systems. The incident response revealed that a threat actor modified several files placed on the Ivanti Connect Secure VPN appliance (Figure B).
Figure B
![Files modified on a compromised Ivanti Secure VPN appliance.](jpg/tr_20240112-volexity-ivanti-connect-secure-vpn-vulnerabilities-figure_b-770x769.jpg)
Volexity also believes a number of files have been created and used/executed in the system’s temporary folder (/tmp) but were no longer available for investigation at the time of the incident response, such as:
- /tmp/rev
- /tmp/s.py
- /tmp/s.jar
- /tmp/b
- /tmp/kill
A Python-based proxy utility, PySoxy, believed to be s.py, was found on a disk image. It is a SOCKS5 proxy script freely available on the internet.
The threat actor, dubbed UTA0178 by Volexity, deployed webshells and modified files to allow credential theft before moving from system to system using the compromised credentials. The threat actor kept collecting newly harvested credentials on every system they hit, and was observed dumping a full image of the Active Directory database. Finally, the attacker modified the JavaScript loaded by the web login page for the VPN appliance to capture any credential provided to it. The legitimate lastauthserverused.js script was modified to send the stolen credentials to an attacker-controlled domain: symantke(.)com.
Once in possession of credentials, the threat actor explored the network, looking at user files and configuration files, and deployed more webshells on the network, including a custom webshell dubbed GLASSTOKEN.
Custom GLASSTOKEN webshell
While the threat actor made use of several public and known tools, GLASSTOKEN was deployed in two slightly different versions.
The first version includes two code paths, depending on the parameters provided in the request. The first path is used to relay a connection, while the second one is used to execute code that is decoded from hexadecimal before being base64 decoded. According to Volexity’s observations, the threat actor used it mostly to execute PowerShell commands.
The second version of the webshell is close to the first one except that it misses the proxying feature, only allowing code execution.
Full code for those webshells has been provided by Volexity.
Threat detection
Network traffic analysis
Careful analysis of the outbound traffic from the VPN appliance can detect suspicious activity. Aside from the legitimate connect back to pulsesecure.net and any other customer-related configured integration (SSO, MFA etc.), any suspicious activity should be analyzed. Examples as observed by Volexity are curl requests to remote websites, SSH connections to remote IP addresses, or encrypted communications to hosts that are not associated with providers or device updates.
Activity on the inbound network traffic from IP addresses associated with the VPN appliance should also be checked carefully. Suspicious traffic that might be observed on such connections can be RDP or SMB activity to internal systems, SSH connection attempts or port scanning, to name a few.
VPN device log analysis
Any indication that the VPN appliances log files have been wiped or disabled is a strong indicator of compromise, in case it was previously active.
Requests for files in atypical paths in the logs should also be concerning and analyzed, as threat actors might store or manipulate files out of the usual folders.
Integrity Checker tool
The In-Build Integrity Check tool can be used to run automatically and detect new or mismatched files. As written by Volexity’s researchers, “if any new or mismatched files are listed, the device should be considered compromised.”
Ivanti provides an external version of the Integrity Checker tool, which should be used in case the system is suspected of being compromised. The tool should only be installed and launched after all forensic evidence has been collected from the system — in particular a memory image because the execution of the tool will reboot the appliance and possibly overwrite evidence data.
Threat mitigation
Ivanti provides a mitigation method until a full patch will be available. Ivanti indicates that “patches will be released in a staggered schedule with the first version targeted to be available to customers the week of 22 January and the final version targeted to be available the week of 19 February.”
The mitigation consists of importing a mitigation.release.20240107.1.xml file via the download portal. Depending on the configuration, system degradation might result from this operation, as listed on the dedicated Ivanti page. It is strongly advised to carefully follow all of Ivanti’s instructions and check that the mitigation is working correctly.
Disclosure: I work for Trend Micro, but the views expressed in this article are mine.