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.
November 16, 2022 NRPT-2022-002: 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
November 16, 2022 NRPT-2022-001: 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
August 06, 2021 NRPT-2021-003: 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
March 05, 2021 NRPT-2021-002: 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
February 04, 2021 NRPT-2021-001: 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.
August 24, 2020 NRPT-2020-002: 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
May 15, 2020 NRPT-2020-001: 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.
