Security Advisories

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.

DATE ID COMMENTS
August 06, 2021 NRPT-2021-003 Enterprise Solid Server microservices privilege escalation
March 05, 2021 NRPT-2021-002 Verification flaw in Solid identity-token-verifier
February 04, 2021 NRPT-2021-001 Pod takeover from WebID impersonation 
August 24, 2020 NRPT-2020-002 NSS Secret Key Disclosure
May 15, 2020 NRPT-2020-001 Authentication Token Capture-Replay

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

  1. Requires Node.js version 10 or greater
  2. Upgrade to version 5.5.1 released August 24, 2020 or a later version (https://github.com/solid/node-solid-server and https://www.npmjs.com/package/solid-server)
  3. Delete server file to force key rotation: provider.json
  4. Restart the server

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:

  • A new client library named solid-auth-fetcher has been released to support the new token structure. 
  • A new version of an existing client library, named solid-auth-client 2.0, is available now to provide support for code delayed in migration to the safer token.
  • Node Solid Server (NSS) has been updated to support the new safer token. NSS will maintain support for the existing token until further notice.

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.