Ahacker1-Securesaml

**Name of the Vulnerable Software and Affected Versions** SignXML versions prior to 4.0.4 **Description** 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. **Recommendations** For versions prior to 4.0.4, update to version 4.0.4 or later to resolve the issue. As a temporary workaround, consider disabling the `verify` function with `require x509=False` and `hmac key` set until a patch is available. Restrict access to the `XMLVerifier` class to minimize the risk of exploitation. Avoid using the `hmac key` parameter in the affected `verify` function until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** SignXML versions prior to 4.0.4 **Description** 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. **Recommendations** For versions prior to 4.0.4, consider explicitly limiting the expected signature algorithms using the `signxml.XMLVerifier.verify(expect config=...)` setting to prevent algorithm confusion attacks. As a temporary workaround, consider restricting the set of accepted signature algorithms to HMAC only, if possible, until a patch is available. Update to SignXML version 4.0.4 or later, as it restricts the set of accepted signature algorithms to HMAC only when `hmac key` is specified.

**Name of the Vulnerable Software and Affected Versions** samlify versions prior to 2.10.0 **Description** 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. **Recommendations** For versions prior to 2.10.0, update to version 2.10.0 to secure your application and prevent the Signature Wrapping attack. As a temporary workaround, consider restricting access to the SAML single sign-on functionality until the update is applied.

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.

**Name of the Vulnerable Software and Affected Versions** SimpleSAMLphp SAML2 library versions prior to 4.6.14 SimpleSAMLphp SAML2 library versions prior to 5.0.0-alpha.18 **Description** 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. **Recommendations** For SimpleSAMLphp SAML2 library versions prior to 4.6.14, update to version 4.6.14 or later. For SimpleSAMLphp SAML2 library versions prior to 5.0.0-alpha.18, update to version 5.0.0-alpha.18 or later. As a temporary mitigation measure, consider removing the `LIBXML DTDLOAD` | `LIBXML DTDATTR` options from the `$options` variable. Additionally, check for the presence of the string `<!DOCTYPE` inside the XML before parsing it, although this is not a complete fix.

**Name of the Vulnerable Software and Affected Versions** SimpleSAMLphp xml-common versions prior to 1.19.0 **Description** 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. **Recommendations** For versions prior to 1.19.0, remove the `LIBXML DTDLOAD | LIBXML DTDATTR` options from `$options` to mitigate the issue. Additionally, as a defense-in-depth measure, check for the string `<!DOCTYPE` inside the XML before parsing it. However, note that this is not a complete fix, as there might be parser differentials that could load a DOCTYPE. Upgrade to version 1.19.0 or later to secure the handling of XML structures.

**Name of the Vulnerable Software and Affected Versions** SSOReady versions prior to 7f92a06 **Description** 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. **Recommendations** To resolve the issue, upgrade to SSOReady version 7f92a06 or later by updating your SSOReady Docker images from `sha-...` to `sha-7f92a06`. There are no known workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Ruby-SAML versions prior to 1.17.0 Ruby-SAML versions 1.13.0 through 1.16.0 GitLab versions prior to 17.3.3, 17.2.7, 17.1.8, 17.0.8, and 16.11.10 **Description** 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. **Recommendations** For Ruby-SAML versions prior to 1.17.0: Update to version 1.17.0 or later. For Ruby-SAML versions 1.13.0 through 1.16.0: Update to version 1.17.0 or later. For GitLab versions prior to 17.3.3, 17.2.7, 17.1.8, 17.0.8, and 16.11.10: Update to the respective latest version or apply the security patch. As a temporary workaround, consider enabling two-factor authentication for all user accounts and setting the SAML 2FA bypass parameter to 'do not allow' until a patch is applied.