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
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
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
Workarounds
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: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:
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:
Get a list of all team members in these teams:
References
For more information
If you have any questions or comments about this advisory feel free to email us at vulnerability-report@wire.com