Vulnerabilidades do WSO2 Identity Server

The WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in multi-factor authentication (MFA). This allows unused OTPs to remain valid indefinitely, presenting an opportunity for malicious actors to conduct brute force attacks by repeatedly guessing the OTP. The absence of automatic expiration for OTPs grants attackers an unlimited timeframe to attempt guessing the correct code. A successful brute force attack can lead to an MFA bypass, resulting in the unauthorized takeover of a user's account and compromising the security and privacy of both the individual and the system.

When an Event Publisher output adapter is configured with irrelevant properties, the affected products log these properties. This logging occurs without sufficient validation or sanitization of the property values. A malicious actor with access to the 'wso2carbon' log files could retrieve sensitive information, such as user credentials or other confidential data, that was inadvertently logged due to misconfiguration, potentially leading to unauthorized access.

The system accepts authentication requests without sufficient validation to enforce tenant isolation when using Email OTP, SMS OTP, or Magic Link as first-factor authenticators. This failure to adequately separate user data between tenants can lead to the exposure of personally identifiable information. Successful exploitation allows an attacker to disclose personally identifiable information of users in different tenants, resulting in privacy violations and potential regulatory non-compliance. This may include unauthorized access to user details such as mobile numbers.

The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks. Specifically, it utilizes the HTTP GET method for these operations, and while the SameSite=Lax cookie attribute is employed for mitigation, this mechanism is bypassed as it permits cookies to be sent with cross-origin top-level navigation requests, including GET requests. This allows an attacker to trick an authenticated user's browser into unknowingly executing unintended actions. An attacker can exploit this vulnerability to perform unauthorized state-altering requests on behalf of authenticated users. This could lead to consequences such as data modification, account changes, or other actions that could result in data compromise or loss of user control over their account. However, this attack is only feasible if the Carbon console and related services are exposed to the public internet, which is not recommended according to WSO2's security guidelines.

When secondary user stores are configured, the implicit-association resolver incorrectly initializes from a secondary user store and bypasses the primary user store during search and uniqueness checks. This allows a subject to be associated with an unintended local account if the same lookup claim (e.g., username or email) exists in both the primary and a secondary store. If duplicate claim values exist across user stores, this issue can lead to identity confusion due to incorrect implicit associations when using an external Identity Provider (IDP). Legitimate user accounts in the primary user store may fail to associate correctly with their corresponding external IDP accounts, potentially restricting access if the secondary account has fewer privileges. Deployments are not affected if no secondary user stores are configured, implicit association is disabled, or claim values are globally unique.

Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system. This allows for the persistence of these codes, enabling them to be potentially reused. If an attacker possesses both the authorization code and the associated client credentials (client ID and client secret), they can leverage these unused codes to obtain access tokens on behalf of users who have already been deleted. This may lead to unauthorized access to sensitive resources and services, contingent on the scopes originally authorized for the compromised authorization code.

The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input. This weakness allows arbitrary unvalidated data to be included within user claims, which are then used by downstream processes. Allowing unvalidated input into user claims can lead to various security risks. Malicious or malformed data injected during signup could be processed by other parts of the application, potentially enabling attacks such as content manipulation, redirection, user interface inconsistencies, unauthorized actions, and data exposure. The actual impact depends on how the compromised data is consumed and the privileges associated with the affected users.

The affected product accepts user-supplied input within a URL parameter without enforcing expected sanitization or encoding before rendering it within the response. This condition allows for the injection of malicious JavaScript payloads. An attacker can leverage this vulnerability to cause the user's browser to redirect to a malicious website, modify the user interface of the webpage, or retrieve sensitive information from the browser. However, the impact is mitigated for session hijacking as all session-related sensitive cookies are protected by the httpOnly flag.

The software accepts user-supplied input via a URL parameter without adequate output encoding before reflecting it back to the user's browser. This condition allows an attacker to inject malicious script content into pages served by the application. By leveraging this weakness, an attacker can cause the user's browser to redirect to a malicious website, modify the UI of the webpage, or retrieve information from the browser. However, the impact is mitigated by the use of httpOnly flags on session-related cookies, preventing session hijacking.

The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segregate user roles during account creation when a federated user shares a username with a local user. This allows the provisioning process to overwrite existing roles of local users with roles assigned to the federated user. Exploitation requires a federated identity provider (IDP) with silent JIT provisioning enabled and an attacker's knowledge of a local user's username. When these conditions are met, a malicious individual can leverage the JIT provisioning process to modify the roles of local users. The overwritten roles are limited to those defined within the federated IDP, typically granting minimal access rights unless explicitly configured otherwise by the federated IDP administrator.

The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker to infer the existence of registered user accounts. The discovery of valid usernames can increase the risk of brute-force and social engineering attacks. Attackers can leverage this information to craft targeted phishing campaigns or other malicious activities aimed at tricking users into divulging sensitive data, potentially damaging the organization's reputation and leading to regulatory non-compliance and financial consequences.

The authentication endpoint accepts user-supplied input without enforcing expected validation constraints, leading to a lack of proper output encoding. This allows for the injection of malicious JavaScript payloads, enabling reflected cross-site scripting. An attacker can leverage this vulnerability to redirect the user's browser to a malicious website, modify the user interface of the web page, retrieve information from the browser, or cause other harmful actions. However, due to the protection of session-related cookies with the httpOnly flag, session hijacking is not possible.

Active access tokens are not revoked or invalidated when a user account is locked within WSO2 Identity Server. This failure to enforce revocation allows previously issued, valid tokens to remain usable, enabling continued access to protected resources by locked user accounts. The security consequence is that a locked user account can maintain access to protected resources through the use of existing, unexpired access tokens. This creates a security gap where access control policies are bypassed, potentially leading to unauthorized data access or actions until the tokens naturally expire.

The authentication endpoint fails to encode user-supplied input before rendering it in the web page, allowing for script injection. An attacker can leverage this by injecting malicious scripts into the authentication endpoint. This can result in the user's browser being redirected to a malicious website, manipulation of the web page's user interface, or the retrieval of information from the browser. However, session hijacking is not possible due to the httpOnly flag protecting session-related cookies.