Eclipse EDC: OAuth2 Credential Exfiltration Vulnerability

The Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority. This issue it used to request and track the progress of the assignment of a CVE for a vulnerability in the project code for an Eclipse open source project.

Basic information

Project name: Eclipse Dataspace Components

Project id: technology.edc

Request type: publication

Versions affected: [0.2.1, 0.6.2]

Common Weakness Enumeration:

• CWE-201: Insertion of Sensitive Information Into Sent Data
• CWE-522: Insufficiently Protected Credentials

Common Vulnerability Scoring System: {cvss}

6.9

CVSS:4.0/AV:A/AC:H/AT:P/PR:H/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/AU:Y/V:D/RE:L/U:Amber

Exploitable Metrics

• Attack Vector: Adjacent, because attackers have to be part of a dataspace, such as Catena-x, which is not the general public internet. A comparison to a VPN is not unreasonable.
• Attack Complexity: High, because an attacker has to go through a contract negotiation, and a transfer process per guess.
• Attack Requirements: Present, because there has to be some infrastructure and pre-existing setup in place, like onboarding
• Privileges required: attacker has to be a legit member of a dataspace, and they have to fulfill all requirements (Policies) imposed by the provider
• User Interaction: not required.

Vulnerable System Impact Metrics

• Confidentiality: High, as leaking private keys could allow an attacker to pose as the provider
• Integrity: Low, because no modification of data is possible, if downstream systems such as databases are configured properly (i.e. without internet access)
• Availability: Low, because the reachability/availability is not affected

Subsequent System Impact Metrics

• Confidentiality: not disputed
• Integrity: downstream systems cannot be modified by this vulnerability
• Availability: not affected

Supplemental Metrics

• Value Density: every exploit event gives access to exactly one value, i.e. secret stored in the vault
• Vulnerability Response Effort: Low, because it is sufficient to disable Http-PUSH from the dataplane config, or remove the OAuth2 module from the build file
• Provider Urgency: Amber, as this exploit is not available in all combinations of modules and scenarios

Summary:

In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component (https://github.com/eclipse-edc/Connector) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL.

Links:

• {primary resolution link}

Tracking

This section will completed by the project team.

• Reserve an entry only
• We're ready for this issue to be reported to the central authority (i.e., make this public now)

Note that for those projects that host their repositories on GitHub, the use of GitHub Security Advisories is recommended but is not required.

This section will be completed by the EMO.

CVE: {cve}

• All required information is provided
• CVE Assigned
• Pushed to Mitre
• Accepted by Mitre