Security

January 25, 2024

6 Minute Read

Security Insights: Investigating Ivanti Connect Secure Auth Bypass and RCE

By Michael Haag, Splunk Threat Research Team

On January 10th, 2024, Volexity reported that there is active exploitation in the wild against Ivanti Connect Secure (ICS) VPN devices. Ivanti and Volexity worked together to review impacted devices, and Volexity identified two different zero days, which have been assigned the following CVEs IDs:

CVE-2023-46805: An authentication-bypass vulnerability with a CVSS score of 8.2
CVE-2024-21887: A command-injection vulnerability found in multiple web components with a CVSS score of 9.1

When combined, these two vulnerabilities make it trivial for attackers to run commands on the system. In the incident worked by Volexity, the attacker leveraged these exploits to steal configuration data, modify existing files, download remote files, and reverse tunnel from the ICS VPN appliance. After gaining access to the system, Volexity observed attackers making modifications to legitimate ICS components and changes to the system to evade the ICS Integrity Checker Tool. Once inside, the adversary performed common Living off the Land techniques, including some of the techniques we've previously documented here.

In response to these threats, the Splunk Threat Research Team has swiftly developed Splunk analytics and hunting queries to support defenders, which we'll review below.

Splunk Security Analytics

Ivanti Connect Secure System Information Access via Auth Bypass

This analytic is designed to identify the "check phase" of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a GET request is made to the /api/v1/totp/user-backup-code/../../system/system-information URI. This request exploits the authentication bypass vulnerability to gain access to system information. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable.

This particular content was developed after reviewing the MetaSploit module, which performs the following functions:

The module first checks for potential exploitation by trying to bypass authentication and access system information.
Upon successful verification, it proceeds to exploit the command injection vulnerability. It creates a temporary shell script, encodes it in base64, and then executes it on the target system via the command injection vulnerability.
The attack is executed without authentication, chaining both vulnerabilities.

| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/api/v1/totp/user-backup-code/../../system/system-information*" Web.http_method=GET Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url
| `drop_dm_object_name("Web")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{Figure 1: MetaSploit Check Phase}

Ivanti Connect Secure Command Injection Attempts

This analytic is designed to identify the exploit phase of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a POST request is made to the /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection URI. This request exploits the command injection vulnerability to execute arbitrary commands. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable.

This particular content was developed after reviewing the MetaSploit module.

| tstats count min(_time) as firstTime max(__time) as lastTime from datamodel=Web where Web.url="*/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection*" Web.http_method=POST Web.status=200 by Web.src, Web.dest, Web.http_user_agent, Web.url
| `drop_dm_object_name("Web")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{Figure 2: MetaSploit Exploit Phase}

Access to Vulnerable Ivanti Connect Secure Bookmark Endpoint

This analytic monitors access to the /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark endpoint, a key indicator for both CVE-2023-46805 and CVE-2024-21887 vulnerabilities. It detects potential vulnerabilities by looking for a 403 Forbidden response with an empty body on this endpoint. This detection method is used in both Nmap script and Project Discovery Nuclei, with the latter focusing on systems where XML mitigation for these vulnerabilities has not been applied.

This particular content was developed after reviewing this watchTowr blog, nmap script and Nuclei template.

| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url="*/api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark*" Web.http_method=GET Web.status=403 by Web.src, Web.dest, Web.http_user_agent, Web.status, Web.url source
| `drop_dm_object_name("Web")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

^{Figure 3: Vulnerable Device Identification}

The watchTowr blog provides additional insight into the vulnerabilities and includes a specific focus on the detection approach. This is particularly useful for identifying potentially vulnerable systems. One key aspect highlighted in the blog is the behavior of certain API endpoints in response to these vulnerabilities.

The blog specifically mentions the URI path /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark. This endpoint is critical for detection because

A vulnerable system responds to requests at this endpoint with an empty 403 Forbidden response.
In contrast, a system with the mitigation XML applied responds with a 403 Forbidden status but includes a full HTML page, indicating that access is blocked by the administrator.

This difference in response provides a clear and straightforward method to distinguish between vulnerable and mitigated systems, making it an invaluable tool for defenders.

Hunting Queries

Below are a few hunting queries developed to help track down other URI endpoints that may be of interest regarding these vulnerabilities that we found while digging into this incident.

To assist with hunting in an organization's environment, we developed three queries: one that’s datamodel specific and another that’s sourcetype specific, and an atomic indicator query. Modify, tune, and review the data to hunt for behaviors in your environment. If the service is in the environment, broaden the query to review the egress and ingress while looking at the POST and GET methods, including status codes with the request.

Ultimately, reduce the attack surface by mitigating the vulnerability quickly in these instances.

| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web.Web where 
    (
        Web.url="*/api/v1/totp/user-backup-code/*" OR 
        Web.url="*/system/system-information*" OR 
        Web.url="*/license/keys-status*" OR 
        Web.url="*/system/maintenance/archiving/cloud-server-test-connection*"
    ) AND 
    (Web.http_method="GET" OR Web.http_method="POST")
    by Web.src, Web.dest, Web.http_method, Web.http_user_agent, Web.status, Web.url
| `drop_dm_object_name("Web")`
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)`

(index=web OR index=proxy OR index=firewall) AND (
    (http_method=GET OR http_method=POST) AND (
        uri="*/api/v1/totp/user-backup-code/*" OR 
        uri="*/system/system-information*" OR 
        uri="*/license/keys-status*" OR 
        uri="*/system/maintenance/archiving/cloud-server-test-connection*"
    )
)
| stats count by src_ip, dest_ip, http_method, uri, user_agent, status_code
| sort - count

These two queries are great starting points to review suspicious HTTP status codes or methods and understand the normal ingress activity to the software.

Multiple vendors also provide atomic network indicators that may be useful to hunt for retroactively. These are based on the shares from Volexity and Mandiant. Modify as needed for your organization or add to your threat feeds.

(index=your_index_name (dest_ip IN ("206.189.208.156", "75.145.243.85", "47.207.9.89", "98.160.48.170", "173.220.106.166", "73.128.178.221", "50.243.177.161", "50.213.208.89", "64.24.179.210", "75.145.224.109", "50.215.39.49", "71.127.149.194", "173.53.43.7") OR dest_host IN ("gpoaccess.com", "webb-institute.com", "symantke.com")))
| stats count by dest_ip, dest_host
| sort - count

Summary

Uncovered by Volexity, these vulnerabilities highlight the pressing challenge of protecting digital infrastructures. The CVE-2023-46805 allows attackers to bypass authentication controls, while CVE-2024-21887 enables command injection, a combination of unauthorized system access and control.

In response to these threats, the Splunk Threat Research Team has swiftly developed Splunk analytics and hunting queries, helping defenders quickly adapt and respond to emerging threats. The insights from the MetaSploit module, WatchTowr Blog, Nmap NSE script, and Project Discovery Nuclei provide visibility into checking for vulnerable assets and exploitation.

As the year begins, this event is a stark reminder of the dynamic and persistent nature of cyber threats.

Learn More

Visit research.splunk.com to view the Splunk Threat Research Team's complete security content repository. You can implement this content using the Enterprise Security Content Updates app or the Splunk Security Essentials app.

Additional Resources:

Michael Haag

Michael Haag is Principal Threat Research Enginer at Splunk. Michael led the development of Atomic Red Team, an open-source testing platform that security teams can use to assess detection coverage. An avid researcher, he is passionate about understanding and evaluating the limits of defensive systems. His background includes security analysis, threat research, and incident handling.

Splunk Threat Research Team

The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository.

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

SOARing to the Clouds with Splunk SOAR

Now available as part of Splunk Cloud, Splunk SOAR further delivers on our promise to modernize security operations – read on to learn more.

Security 3 Min Read

Macro ATT&CK for a TTP Snack

Splunk's Mick Baccio and Ryan Fetterman explore 2024's macro-level cyber incident trends through the lens of the MITRE ATT&CK framework.

Security 2 Min Read

Staff Picks for Splunk Security Reading December 2021

Welcome to the Splunk staff picks blog. Each month, Splunk security experts curate a list of presentations, white papers, and customer case studies that we feel are worth a read.

About Splunk

The world’s leading organizations rely on Splunk, a Cisco company, to continuously strengthen digital resilience with our unified security and observability platform, powered by industry-leading AI.

Our customers trust Splunk’s award-winning security and observability solutions to secure and improve the reliability of their complex digital environments, at any scale.

Learn more about Splunk

Subscribe to our blog

Get the latest articles from Splunk straight to your inbox.

Connect with Splunk on X

Follow @Splunk

Connect with Splunk on Instagram