Show plain JSON{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:wire:wire-server:*:*:*:*:*:*:*:*", "matchCriteriaId": "F06AABCA-64EC-470D-8089-83AE0BBFE5A6", "versionEndExcluding": "2021-08-16", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "descriptions": [{"lang": "en", "value": "Wire-server is the backing server for the open source wire secure messaging application. In affected versions it is possible to trigger email address change of a user with only the short-lived session token in the `Authorization` header. As the short-lived token is only meant as means of authentication by the client for less critical requests to the backend, the ability to change the email address with a short-lived token constitutes a privilege escalation attack. Since the attacker can change the password after setting the email address to one that they control, changing the email address can result in an account takeover by the attacker. Short-lived tokens can be requested from the backend by Wire clients using the long lived tokens, after which the long lived tokens can be stored securely, for example on the devices key chain. The short lived tokens can then be used to authenticate the client towards the backend for frequently performed actions such as sending and receiving messages. While short-lived tokens should not be available to an attacker per-se, they are used more often and in the shape of an HTTP header, increasing the risk of exposure to an attacker relative to the long-lived tokens, which are stored and transmitted in cookies. If you are running an on-prem instance and provision all users with SCIM, you are not affected by this issue (changing email is blocked for SCIM users). SAML single-sign-on is unaffected by this issue, and behaves identically before and after this update. The reason is that the email address used as SAML NameID is stored in a different location in the databse from the one used to contact the user outside wire. Version 2021-08-16 and later provide a new end-point that requires both the long-lived client cookie and `Authorization` header. The old end-point has been removed. If you are running an on-prem instance with at least some of the users invited or provisioned via SAML SSO and you cannot update then you can block `/self/email` on nginz (or in any other proxies or firewalls you may have set up). You don't need to discriminate by verb: `/self/email` only accepts `PUT` and `DELETE`, and `DELETE` is almost never used."}, {"lang": "es", "value": "Wire-server es el servidor de respaldo de la aplicaci\u00f3n de mensajer\u00eda segura de c\u00f3digo abierto Wire. En las versiones afectadas es posible activar el cambio de direcci\u00f3n de correo electr\u00f3nico de un usuario con s\u00f3lo el token de sesi\u00f3n de corta duraci\u00f3n en el encabezado \"Authorization\". Como el token de corta duraci\u00f3n s\u00f3lo sirve como medio de autenticaci\u00f3n por parte del cliente para peticiones menos cr\u00edticas al backend, la posibilidad de cambiar la direcci\u00f3n de correo electr\u00f3nico con un token de corta duraci\u00f3n constituye un ataque de escalada de privilegios. Dado que el atacante puede cambiar la contrase\u00f1a despu\u00e9s de establecer la direcci\u00f3n de correo electr\u00f3nico a uno que ellos controlan, el cambio de la direcci\u00f3n de correo electr\u00f3nico puede resultar en una toma de control de la cuenta por el atacante. Los tokens de corta duraci\u00f3n pueden ser solicitados desde el backend por los clientes de Wire que usan los tokens de larga duraci\u00f3n, tras lo cual los tokens de larga duraci\u00f3n pueden ser almacenados de forma segura, por ejemplo en el llavero de los dispositivos. Los tokens de vida corta pueden usarse entonces para autenticar al cliente ante el backend para las acciones que se realizan con frecuencia, como el env\u00edo y la recepci\u00f3n de mensajes. Mientras que los tokens de corta duraci\u00f3n no deber\u00edan estar disponibles para un atacante per se, son usados con m\u00e1s frecuencia y en forma de encabezado HTTP, lo que aumenta el riesgo de exposici\u00f3n a un atacante en relaci\u00f3n con los tokens de larga duraci\u00f3n, que son almacenados y transmiten en cookies. Si est\u00e1 ejecutando una instancia on-prem y aprovisiona a todos los usuarios con SCIM, no est\u00e1 afectado por este problema (el cambio de correo electr\u00f3nico est\u00e1 bloqueado para usuarios de SCIM). El inicio de sesi\u00f3n \u00fanico de SAML no est\u00e1 afectado por este problema y se comporta de forma id\u00e9ntica antes y despu\u00e9s de esta actualizaci\u00f3n. La raz\u00f3n es que la direcci\u00f3n de correo electr\u00f3nico usada como SAML NameID es almacenada en una ubicaci\u00f3n diferente en la base de datos de la que es utilizada para contactar con el usuario fuera de Wire. Las versiones 2021-08-16 y posteriores proporcionan un nuevo endpoint que requiere tanto la cookie de cliente de larga duraci\u00f3n como el encabezado \"Authorization\". El antiguo endpoint ha sido eliminado. Si est\u00e1 ejecutando una instancia on-prem con al menos algunos de los usuarios invitados o aprovisionados por medio de SAML SSO y no puede actualizar, entonces puede bloquear \"/self/email\" en nginz (o en cualquier otro proxy o firewall que haya configurado). No es necesario discriminar por verbo: \"/self/email\" s\u00f3lo acepta \"PUT\" y \"DELETE\", y \"DELETE\" casi nunca es usado"}], "id": "CVE-2021-41100", "lastModified": "2024-11-21T06:25:28.137", "metrics": {"cvssMetricV2": [{"acInsufInfo": false, "baseSeverity": "HIGH", "cvssData": {"accessComplexity": "LOW", "accessVector": "NETWORK", "authentication": "NONE", "availabilityImpact": "PARTIAL", "baseScore": 7.5, "confidentialityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0"}, "exploitabilityScore": 10.0, "impactScore": 6.4, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "nvd@nist.gov", "type": "Primary", "userInteractionRequired": false}], "cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 7.4, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 2.2, "impactScore": 5.2, "source": "security-advisories@github.com", "type": "Secondary"}, {"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 9.8, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 5.9, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2021-10-04T19:15:08.510", "references": [{"source": "security-advisories@github.com", "tags": ["Mitigation", "Third Party Advisory"], "url": "https://github.com/wireapp/wire-server/security/advisories/GHSA-9rm2-w6pq-333m"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Mitigation", "Third Party Advisory"], "url": "https://github.com/wireapp/wire-server/security/advisories/GHSA-9rm2-w6pq-333m"}], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-285"}], "source": "security-advisories@github.com", "type": "Secondary"}, {"description": [{"lang": "en", "value": "CWE-613"}], "source": "nvd@nist.gov", "type": "Primary"}]}