Ahacker1-Securesaml

Two domain-ownership flaws exist when the SSO plugin is active. If domain verification is disabled, automatic organization assignment accepts unverified provider domains. This allows an authenticated organization owner or administrator to register an SSO provider for any domain, causing users with matching email domains to be added to the attacker's organization with default member permissions. If domain verification is enabled, a race condition occurs between the 'verify-domain' and 'update-provider' endpoints, which can apply a completed DNS proof to an incorrect domain. When combined with implicit account linking, this allows an attacker-controlled identity provider to be linked to an existing user account. The organization plugin must also be enabled for the organization assignment path to be exploited.

The issue concerns a potential timing attack when verifying signatures with X509 certificate validation turned off and HMAC shared secret set. This could allow users to reconstruct the correct HMAC for any data by comparing the user-supplied hash with the correct HMAC, potentially leaking information about the correct HMAC. The `signxml.XMLVerifier.verify` function is used with `require x509=False` and `hmac key` set.

The issue concerns a potential algorithm confusion attack when verifying signatures with X509 certificate validation turned off and HMAC shared secret set. This could allow an attacker to supply a signature unexpectedly signed with a key other than the provided HMAC key, using a different signature algorithm, unless the user explicitly limits the expected signature algorithms.

A Signature Wrapping attack has been found in samlify, allowing an attacker to forge a SAML Response to authenticate as any user. An attacker would need a signed XML document by the identity provider. This issue affects all versions prior to 2.10.0, posing a high-priority risk for SAML-based SSO systems. No active exploits have been reported.

Name of the Vulnerable Software and Affected Versions: SimpleSAMLphp SAML2 library versions prior to 4.17.0 and 5.0.0-alpha.20 Description: The issue is related to a signature confusion attack in the HTTPRedirect binding. An attacker with any signed SAMLResponse via the HTTP-Redirect binding can cause the application to accept an unsigned message. This can lead to impersonation of any user within the SP. The attack exploits the fact that the contents processed might not be the same as the data that is actually verified. Microsoft Azure AD/Entra and likely ADFS sign the LogoutResponse via this SimpleSign format in HTTP Redirect binding, which can be used to extract a valid Signature. Recommendations: For versions prior to 4.17.0, update to version 4.17.0 or later. For versions prior to 5.0.0-alpha.20, update to version 5.0.0-alpha.20 or later. As a temporary workaround, consider restricting access to the HTTPRedirect binding to minimize the risk of exploitation. Avoid using the `SAMLRequest` parameter in the affected API endpoint until the issue is resolved.

The SimpleSAMLphp SAML2 library is vulnerable to an XML External Entity (XXE) attack when loading untrusted XML documents, such as the SAMLResponse. This allows an attacker to induce an XXE, potentially leading to the reading of file contents from the local file system or internal network. The `LIBXML DTDLOAD` option in the `$options` variable, defined in the `DOMDocumentFactory.php` file, enables this vulnerability. An attacker can bypass the `NONET` option by using PHP filters, such as `php://filter/convert.base64-encode/resource=http://URL` or `php://filter/convert.base64-encode/resource=FILE`, to induce network connections and steal targeted files. Remote Code Execution (RCE) may also be possible using the `php://expect` or `php://phar` wrappers, although this has not been fully tested.

The issue arises when loading an untrusted XML document, such as the SAMLResponse, allowing an attacker to induce an XML External Entity (XXE) attack. This could potentially enable an attacker to read file contents from the local file system or internal network. Although there are options like NONET, an attacker can bypass them using PHP filters. The vulnerability may also lead to remote code execution (RCE) using certain PHP wrappers, but this has not been fully tested.

The issue concerns XML signature bypass attacks. An attacker can exploit differential behavior between XML parsers to carry out signature bypass if they have access to certain IDP-signed messages. Users of the public hosted instance of SSOReady are unaffected. The vulnerability was discovered by a security researcher and its precise mechanism is not publicly disclosed to prevent potential attacks on other SAML implementations.

The vulnerability is related to the Ruby SAML library, which is used for implementing the client side of a SAML authorization. The issue arises from the library's failure to properly verify the signature of the SAML Response, allowing an unauthenticated attacker with access to any signed SAML document to forge a SAML Response or Assertion with arbitrary contents. This enables the attacker to bypass the authentication mechanism and potentially gain unauthorized access to sensitive data and critical systems. The vulnerability is actively being exploited, and users are advised to update their GitLab installations to the latest version.