Skip to content

Improper Verification of Cryptographic Signature

Critical
comawill published GHSA-9jg9-9g37-4424 Mar 16, 2022

Package

wire-server (wire)

Affected versions

<=2022-01-18 or <=2.122.0

Patched versions

>=2022-01-27 or >=2.123.0

Description

Impact

It was possible to craft DSA Signatures to bypass SAML SSO and impersonate any Wire user with SAML credentials. In teams with SAML, but without SCIM, it was possible to create new accounts with fake SAML credentials.

Details

Under certain conditions that can be established by an attacker, an upstream library for parsing, rendering, signing, and validating SAML XML data was accepting public keys as trusted that were provided by the attacker in the signature. As a consequence, the attacker could login as any user in any Wire team with SAML SSO enabled. If SCIM was not enabled, the attacker could also create new users with new SAML NameIDs.

How to reproduce

wire only accepts RSA certificates and signatures; DSA and other methods are ignored or rejected from the SAML XML metadata. However, if an attacker provides a DSA public key in the signature itself, it will be bypassed around the Wire application logic and handed to the hsaml2 library. hsaml2 maintains a pair of an optional RSA and an optional DSA key. Wire worked under the assumption that one could pass hsam2 an RSA key and an empty slot for the DSA key. However, this has the effect that the DSA key from the signature itself will be added to the pair. DSA has precedence over RSA, so the signature validation will be successful if (and only if) the attacker provided a DSA public key matching the own signature.

In order to exploit this vulnerability, the attacker needs to know the SSO login code (distributed to all team members with SAML credentials and visible in the Team Management app), the SAML EntityID identifying the IdP (a URL not considered sensitive, but usually hard to guess, also visible in Team Management), and the SAML NameID of the user (usually an email address or a nick).

Wire is using a fork of hsaml2, but our fork had the same problem. We made sure that the upstream hsaml2 received our patches to resolve this vulnerability.

Patches

  • The issue has been fixed in wire-server 2022-01-27 and is already deployed on all Wire managed services.
  • On premise instances of wire-server need to be updated to 2022-01-27, so that their backends are no longer affected.

Workarounds

  • No workaround known

Mitigations

For cloud teams using SAML IdP

If you are an admin of a team running in the Wire cloud, you are running on the latest release and are not vulnerable any more. In addition, if you have a SAML IdP configured, in order to identify and check for any potential breaches in the past, you can choose to instruct all team members to check the device list and remove all suspicious / unknown devices. Our instruction "How can I verify my own devices?" shows an easy way of identifying all of your devices.

For on-prem Installations using SAML IdP

If you are an on-prem site admin and have deployed a patched version (>2022-01-27), you can additionally remove cookies on your system and force all or some users to login within the next 15 minutes (or whenever they come back online). This will cause interruptions to ongoing calls.

This can be done in two ways:

1. Reset all cookies for all users

Open a cqlsh on brig's cassandra and type:

truncate brig.user_cookies;
2. Reset only cookies of users authenticated with SAML (in environments with many non-SAML Teams)

Use a list of users to reset the cookies only for these users on brig's cassandra:

delete from brig.user_cookies where user in (c0d64244-8ab4-11ec-8fda-37788be3a4e2, ...);

You can either download the member CSV lists in the team management app as the team admin of those teams using SAML and extract the userIDs, or you can generate the list via cqlsh (cassandra for spar and galley).

Extract all TeamIDs which use SAML by running the following CQL query on spar's Cassandra:

copy spar.idp (team) TO 'teams_with_idp.csv' with header=true;

Get a list of all team members in these teams:

-- to get users from selected teams:
select user from galley.team_member where team in (f2207d98-8ab3-11ec-b689-07fc1fd409c9, ...);
-- to get all users and cross-reference the two CSV files locally to get to the members of the relevant teams:
copy galley.team_member (team, user) TO 'users_with_idp.csv' with header=true;

References

For more information

If you have any questions or comments about this advisory feel free to email us at vulnerability-report@wire.com

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CVE ID

CVE-2022-23610

Weaknesses

No CWEs