Security Advisories and other security content are provided on an "as is" basis and do not imply any kind of guarantee or warranty. Your use of the information in these publications or linked material is at your own risk. Inrupt reserves the right to change or update this content without notice at any time.
OpenID Token Manipulation Vulnerability in ESS Access Grant, Storage and Query Services
Advisory ID: NRPT-2024-002
Date
Published: 2024 March 6 13:30 UTC
Last Update: 2024 March 6 13:30 UTC
Severity
Exploitation by a malicious OpenID identity provider could lead to unauthorized access to resources or unauthorized privilege escalation. The potential impact includes unauthorized data access and potential compromise of sensitive information.
CVSS: 7.4 (High) https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE-287: Improper Authentication
Summary
A malicious OpenID identity provider has the capability to generate a customized access token, formatted as a signed JWT. This manipulated token can masquerade as a legitimate one issued by a trusted authorization server. Consequently, an operator of the malicious OpenID provider could exploit this token to gain unauthorized entry to resources or elevate their privileges to access resources beyond their authorized level. This issue affects only access grant, storage and query servers that haven't implemented an allow list for trusted identity providers.
Workarounds
Set up the allow list for a service (access grants, storage, and query) to specify trusted identity providers. This ensures the service only accepts tokens from approved identity providers.
Fixes
ESS Access Grant Service 2.1.10 and 2.2.1 or later removes this vulnerability.
ESS Storage Service 2.1.10 and 2.2.1 or later removes this vulnerability.
ESS Query Service 2.1.8 and 2.2.1 or later removes this vulnerability.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Source
Jarlath Holleran
ESS Authorization Off-by-One Error in Shared Status Lists
Advisory ID: NRPT-2024-001
Date
Published: 2024 January 14 13:30 UTC
Last Update: 2024 January 14 13:30 UTC
Severity
In scenarios where both Agent A and Agent B utilize the same access grant status list, an off-by-one error in the ESS code that manages access requests, grants, and denials could enable one agent to invalidate the credential of another. While status lists are designed to be shared among access credentials, their indexes are not, leading to a specific vulnerability affecting only the first two items in the status list. This issue results in an estimated collision probability of 1 in 1.6 million instances.
CVSS: 3.1 (Low) https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization
Summary
Starting in version 2.0, ESS supports an authorization mechanism based on access requests and grants. An agent sends an access request to the resource owner. This request includes specific access modes (e.g. Read, Write, Append) to a resource. The resource owner can deny or grant the request. If the requesting agent is approved, they can exchange this access grant for an access token to a resource.
This issue is related to two grants being held by different agents (e.g. Agent A and Agent B) or a single agent that stores their status in a single list index. This list, randomly chosen, will have the status for status for Grant A and B in one shared index (0) instead of two consecutive ones. In the example below, an XYZ portion of a URI shows a collision.
Agent A: /issue
- 201
status list URI -> https://vc/example/status/XYZ#0
Agent B: /issue
- 201
status list URI -> https://vc/example/status/XYZ#0
This collision represents a vulnerability in availability because it enables an agent to revoke the credential of another agent when they share it. While the likelihood is estimated to be extremely low with a small number of access grants, as the number of grants increases towards 1.6 million, a collision becomes expected.
Workarounds
An increase to ESS entropy through configuration will reduce the likelihood of index collisions, yet also prevent status lists from being reused.
Fixes
Version ESS Access Grants 2.1.9 or later resolves this error.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Source
Jarlath Holleran
Missing ESS Pod Storage Service Content-Security-Policy could allow a malicious service worker
Advisory ID: NRPT-2023-001
Date
Published: 2023 April 13 13:30 UTC
Last Update: 2023 April 13 13:30 UTC
Severity
Insufficient origin verification on a service worker within a targeted Solid Pod could allow privilege escalation.
CVSS: 8.0 (High) https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
CWE-346: Origin Validation Error
Summary
When a Content-Security-Policy (CSP) is not configured to restrict service worker (SW) privileges, an attack could be constructed on ESS. The attack relies on tricking a targeted Pod owner into accessing malicious Web content to initiate a malicious SW on the targeted owner’s Solid Pod. A CSP on ESS has been set now to source:none as the default.
Workarounds
Add a CSP to ESS configured to restrict SW.
Fixes
Version ESS Pod Storage Service 2.1.1 or later resolves this configuration change.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Source
Othmar Lechner
Claim token verification flaw in UMA
Advisory ID: NRPT-2022-002
Date
Published: 2022 Nov 16 13:30 UTC
Last Update: 2022 Nov 16 13:30 UTC
Severity
Insufficient UMA claim token verification could allow a bypass of grant contents to gain unauthorized access.
CVSS: Critical (9.8)
https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-287: Improper Authentication
Summary
The UMA service performed insufficient VC validation, which could allow impersonation. A Solid client exchanges a series of data objects (claim tokens) in the UMA authorization flow to build up an access token. These objects are UMA tickets, OpenID ID Tokens and Verifiable Credential (VC) documents. Several layers of validation should be used for VC-based UMA claim token exchanges. Due to missing validation, an attacker with a VC issued for one resource could provide it as part of the token exchange for another resource.
Workarounds
None
Fixes
Enterprise Solid UMA Authorization Server Version 2.0.6 or later resolves this verification flaw.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Source
Anonymous
WebID token verification flaw in UMA
Advisory ID: NRPT-2022-001
Date
Published: 2022 November 16 13:30 UTC
Last Update: 2022 November 16 13:30 UTC
Severity
Insufficient ID token verification could allow a UMA token to be used for unauthorized access.
CVSS: 8.1 (High)
https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-287: Improper Authentication
Summary
A vulnerability in ESS leads to privilege escalation due to insufficient validation of user-supplied ID tokens.The UMA service permits WebIDs specified in ID token claims. Issuers of ID token claims are only partially restricted. Therefore an IDP issuing OIDC tokens for any WebID could be used for impersonation attacks on a WebID for unauthorized access.
Workarounds
None
Fixes
Enterprise Solid UMA Authorization Server Version 2.0.5 or later resolves this verification flaw.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Source
Inrupt
Enterprise Solid Server microservices privilege escalation
Advisory ID: NRPT-2021-003
Date
Published: 2021 Aug 06 20:29 UTC
Last Update: 2021 Aug 06 20:29 UTC
Severity
A specially constructed request header could escalate read access to write access on a Solid Pod with Enterprise Solid Server (ESS) version 1.1.2 or earlier.
CVSS v3.1 Base Score: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)
Summary
An Agent that has been granted read access to a resource on ESS can elevate its privileges to write level on that resource by constructing a special request header value. This is due to an access validation flaw in the storage service for Solid Pods. ESS audit logs capture agent write access to resources, which can be used to report elevation from read access.
Workarounds
The header value in a request can be blocked at the network level.
Fixes
Version 1.1.3 of ESS or later resolves this access control validation flaw.
Contact
Email: security@inrupt.com
Web: inrupt.com/security
Verification flaw in Solid identity-token-verifier
Advisory ID: NRPT-2021-002
Date
Published: 2021 March 05 13:30 UTC
Last Update: 2021 March 05 13:30 UTC
Severity
A spoofed Demonstration of Proof-of-Possession (DPoP) token binding with a Solid Pod is possible on a Solid server using a vulnerable version of the identity-token-verifier library. A spoofed token could grant unauthorized and complete access to a targeted Pod.
Summary
A verification flaw in the implementation of the identity token verifier library (https://github.com/solid/identity-token-verifier) allows DPoP proofs to be spoofed.
DPoP proofs are used to bind access tokens to a private key meant to be in sole possession of a specific user. Instead of verifying against the hash of an embedded public key, the library instead verifies against a field that an attacker can modify to spoof another user’s DPoP.
A stolen DPoP proof, when used in the right context, therefore allows the rebinding of a DPoP-bound access token. Any attacker in possession of a targeted access token could build an attack environment to replay it on any Pod service with this vulnerability.
Workarounds
None
Fixes
Version 0.5.2 of identity-token-verifier or later resolves this verification flaw: https://github.com/solid/identity-token-verifier/blob/7e18d86d65ee681e8ae912b6a032a1bae3cae570/src/lib/DPoP.ts#L25-L35 replaces https://github.com/solid/identity-token-verifier/blob/0cbb50406717496ecc900d1e3171b2f7ee946a31/src/lib/DPoP.ts#L25
Contact
Email: security@inrupt.com
Web: inrupt.com/security
NSS Pod takeover from WebID impersonation
Advisory ID: NRPT-2021-001
Date
Published: 2021 February 04 18:30 UTC
Last Update: 2021 February 04 18:30 UTC
Severity
Any user Pod on an NSS server (versions <= 5.3.1) can be taken over from the network by any other user if they create a new account on that same NSS, due to a flaw in the ‘bring your own WedID’ feature.
Summary
When a user registers a new account using the Advanced External WebId feature, an NSS server accepts any WebID with a solid:oidcIssuer in the associated profile document pointing to that same server.
A malicious user on any NSS service can take a WebID that already has a solid:oidcIssuer value pointing to that NSS service and create a new account in the “bring your own WebId” feature to target an existing WebID, and therefore take over access to a Pod owned by a targeted WebID.
Workarounds
None
Fixes
Update NSS to remove the ‘bring your own WebId’ feature. This update is available in version 5.6.3.
Contact
email: security@inrupt.com
Source
Inrupt would like to thank Stijn Taelemans from Digita for reporting this vulnerability.
NSS Secret Key Disclosure
Advisory ID: NRPT-2020-002
Date
Published: 2020 Aug 24 15:20 UTC
Last Update: 2020 Aug 24 15:20 UTC
Severity
A secret key of the Node Solid Server (NSS) was exposed in a public configuration file, where it could be used to impersonate the server and access, modify or delete user data. After the server is patched, to rotate and protect its key, all users should rotate their passwords.
Summary
An Inrupt security review found the NSS secret key exposed to the public in an OIDC configuration file (CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere).
Any person on the Internet who viewed the NSS public OIDC configuration file could use the secret key material to impersonate the NSS server to issue tokens for user data with full read, modify or delete permissions.
The vulnerable version of NSS exposing the key material was published June 16th, 2020. A security review August 22, 2020 found the key, a patch was written August 23 and a new version of NSS was tested and upgraded August 24 with the release of this advisory.
The vulnerability affects NSS versions 5.3.0 or later. Inrupt Enterprise Solid Server is not affected.
Workarounds
None
Fixes
Server patch for NSS
User password reset
Everyone with a user account on NSS (i.e. anyone who has a Pod) should reset their password after the server has been upgraded to version 5.5.1 (https://inrupt.net/account/password/reset). It is a good safety practice to always maintain unique passwords between different accounts.
Contact
email: security@inrupt.com
Source
Inrupt security
Authentication Token Capture-Replay
Advisory ID: NRPT-2020-001
Date
Published: 2020 May 15 16:00 UTC
Last Update: 2020 May 15 16:00 UTC
Severity
Resources that otherwise would not be accessible without proper authentication can be accessed by capturing and replaying a valid token.
Summary
A weakness was reported in the Solid Authentication Specification, requiring a change to the Solid authentication token. The current token, if captured, can be replayed (CWE-294: Authentication Bypass by Capture-replay).
Workarounds
None
Fixes
The authentication panel put forward a proposal, which was approved after review and the Authentication Specification has been updated. The change brings a new safer token for the specification to address security concerns.
The following steps have been taken to help developers migrate ASAP to the safer token:
Inrupt.net will be upgraded to the latest version of NSS with its support for the new safer token, on the week of 05/25/2020.
Contact
email: security@inrupt.com
Source
Inrupt would like to thank Justin Richer, Bespoke Engineering for reporting this vulnerability.
