Critical Patches Released for VMware vCenter Server and GitLab (CVE-2024-38812, CVE-2024-45409)

Broadcom recently issued important patches for VMware, addressing two critical vulnerabilities in its vCenter Server platform, the more severe of them being CVE-2024-38812. Due to the vulnerability, the company cites risk of potential Remote Code Execution (RCE) attacks.

As a vital tool for managing virtual machines and ESXi hosts, VMware vCenter Server is widely used across many organizations, making these vulnerabilities especially concerning.

In separate news, the leading DevOps platform GitLab patched a critical vulnerability with a maximum CVSS score of 10/10. This vulnerability can grant unauthorized access to GitLab instances, raising concerns about data exposure and supply chain security.

What is CVE-2024-38812? How Does It Affect VMware vCenter Server?

The latest VMware vulnerabilities fixed by Broadcom were reported by researchers from the 2024 Matrix Cup contest in China, with CVE-2024-38812 being the most severe.

The CVE-2024-38812 (CVSS: 9.8) vulnerability stems from a heap-overflow flaw in the Distributed Computing Environment/Remote Procedure Call (DCERPC) protocol. An attacker with network access to vCenter Server could exploit this flaw by sending a specially crafted network packet, potentially leading to RCE and full system compromise.

In addition to this critical issue, VMware also patched another severe flaw, CVE-2024-38813 (CVSS: 7.5).

CVE-2024-38813 allows an attacker to escalate privileges to root on the system. While less critical than CVE-2024-38812, it still carries a significant risk for vCenter Server. Attackers can exploit this vulnerability by sending specially crafted network packets, enabling them to gain elevated access to the affected system.

Which VMware Products/Versions Are Affected?

The recently disclosed vulnerabilities, CVE-2024-38812 and CVE-2024-38813, impact multiple versions of VMware products. Specifically, they affect:

• VMware vCenter Server versions 7.0 and 8.0
• VMware Cloud Foundation versions 4.x and 5.x

Organizations using any of these versions are strongly encouraged to apply the available patches to secure their systems against potential exploitation.

Are There Any Exploitation Activities Regarding CVE-2024-38812 or CVE-2024-38813?

At the time of writing, there are no known instances of these vulnerabilities being actively exploited.

VMware’s advisory has not reported any exploitation activity related to these vCenter Server vulnerabilities. However, it remains critical for organizations to patch them promptly, as the potential for exploitation exists, especially once details are publicly known.

How to Address These Vulnerabilities?

The following list shows the fixed versions that address CVE-2024-38812 and CVE-2024-38813:

• For vCenter Server 8.0: Update to version 8.0 U3b
• For vCenter Server 7.0: Update to version 7.0 U3s
• For VMware Cloud Foundation 5.x: Async patch to version 8.0 U3b
• For VMware Cloud Foundation 4.x: Async patch to version 7.0 U3s

There are no available workarounds, so applying these updates is necessary to protect against potential exploitation. For detailed guidance about these updates, refer to the official VMware advisory.

SOCRadar’s Vulnerability Intelligence keeps you updated on the most recent CVE trends and exploitation methods, providing tools that support proactive vulnerability management. Use this module to discover new vulnerabilities, track exploits, and receive actionable insights to enhance your security efforts.

Critical GitLab Vulnerability (CVE-2024-45409) Poses Risk of Authentication Bypass

Recently, GitLab has also addressed a critical security vulnerability, CVE-2024-45409 (CVSS: 10), which affects both its Community Edition (CE) and Enterprise Edition (EE). The flaw presents a significant risk by potentially granting attackers unauthorized access to sensitive projects and source code on GitLab instances.

The vulnerability originates from improper signature verification in specific versions of the ruby-saml library, which manages SAML authentication in GitLab. It allows unauthenticated attackers to forge a SAML response and gain access to GitLab as any user, bypassing authentication checks.

Affected versions of the library include:

• versions up to and including 12.2
• 1.13.0 through 1.16.0

If left unpatched, CVE-2024-45409 could allow attackers to bypass authentication measures, putting valuable GitLab repositories at risk of unauthorized access, significantly impacting organizations depending on GitLab for secure development and source code management.

How to Address the CVE-2024-45409 Vulnerability in GitLab

GitLab has released security patches to address CVE-2024-45409, updating the omniauth-saml dependency to version 2.2.1 and the ruby-saml library to version 1.17.0.

Affected GitLab installations should be updated to the following patched versions immediately:

• 17.3.3
• 17.2.7
• 17.1.8
• 17.0.8
• 16.11.10

Given the critical nature of this flaw, which could allow remote, unauthenticated access, you should apply these updates without delay to prevent potential breaches.

To continuously monitor your digital assets for emerging threats, SOCRadar’s Attack Surface Management (ASM) module can be a vital solution.

With ASM, the platform sends alerts on newly discovered vulnerabilities that affect your systems, helping you streamline patch management and strengthen your overall security stance.

Methods to Mitigate CVE-2024-45409

GitLab recommends two mitigation steps for self-managed GitLab users to reduce the risk of exploitation.

1. One important measure is enabling Two-Factor Authentication (2FA) for all user accounts on the instance. It’s essential to use GitLab’s built-in 2FA, as Multi-Factor Authentication (MFA) provided by third-party identity providers (IdPs) will not mitigate this particular vulnerability.
2. Additionally, disabling the SAML Two-Factor Bypass option in GitLab can prevent attackers from exploiting this method to bypass security layers.

By taking these steps, organizations can add essential defenses against potential attacks targeting the vulnerability.

Indicators of Compromise (IOCs) for CVE-2024-45409 Exploitation

To help detect potential exploitation of CVE-2024-45409, GitLab has provided key indicators within application and authentication logs:

Unsuccessful Exploitation Attempts: Look for occurrences of RubySaml::ValidationError, typically caused by incorrect callback URLs or certificate signing issues.

Successful Exploitation Attempts: These leave traces in SAML-related log events where attackers manipulate extern_uid values. Administrators should scrutinize logs for unexpected or unfamiliar extern_uid fields.

Here’s an example of a log event showing a potential exploit:

{"severity":"INFO","time":"2024-xx-xx","correlation_id":"xx","meta.caller_id":"OmniauthCallbacksController#saml","meta.remote_ip":"0.0.0.0","meta.feature_category":"system_access","meta.client_id":"ip/0.0.0.0","message":"(SAML) saving user [email protected] from login with admin =u003e false, extern_uid =u003e exploit-test-user"}

Sigma-Based Detection Rules

For organizations using a SIEM, GitLab has provided Sigma-based detection rules to identify suspicious activity:

• Multiple extern_uid Values: Detect multiple extern_uid values for a single authenticated user, which may indicate manipulation:

title: Multiple extern_ids
description: Detects when their are multiple extern_id's associated with a user. 
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
  select log source application.log
  where 7d < event_time < now()
  where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
  regex(message, "saving user (?S+) .*extern_uid S+ (?[S]+)")
  count extern_id by user_email as total_extern_ids
  where total_extern_ids > 1
verify: Review Gitlab application logs for the source IP of the SAML authentications. If there is a singular IP for all extern_ids this could point to a false positive. Cross reference the SAML authentication source IP/s with the known user's IP from sso authentication logs. 
tuning: N/A

• IP Address Mismatches: Look for mismatches between IP addresses in SAML authentication events and other IdP-related activities for the same user:

title: Gitlab SAML IP differs from SSO IP
description: Detects when the source IP for the SAML authentication to Gitlab from application.log differs from the users known IP from SSO MFA logs. 
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
  select log source application.log 
  where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
  regex(message, "saving user (?S+) ")
  #Create sub-query to bring in table from SSO authentication data
  select meta_remote_ip, user_email
  where user_email in
    (
    select log source authentication
    where 1d < event_time < now()
    where event_type="user.authentication.auth_via_mfa"
    group by user_email, sso_source_ip
    )
  where sso_source_ip!=meta_remote_ip
verify: False positives can arise when the user is traveling. Review SSO authentication logs to see if the geo-location is similar to the SAML authentication to Gitlab. If any discrepancies are found, reach out to the user for verification. If the user is not traveling, temporarily lock the user's Gitlab account and review their activity through Gitlab's application logs. 
tuning: If the query is producing high false positives, consider using geolocation functions on IPs to compare the cities and countries that are generating the authentications.

For more detail, see the full GitLab advisory here.