CVE-2025-24895: AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass

February 18, 2025

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library cie-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

Click to open external image

As shown in the diagram, the IdP, after verifying the user’s credentials, generates a signed SAML response, this is propagated to the SP by the user’s browser and the SP, after verifying the signature, can extract the data needed to build the user’s session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in cie-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
//...SNIP...
SignedXml signedXml = new SignedXml(signedDocument);
if (identityProvider is not null)
{
bool validated = false;
foreach (var certificate in identityProvider.X509SigningCertificates){
var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
signedDocument.GetElementsByTagName("ds:Signature") :
(signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
signedDocument.GetElementsByTagName("ns2:Signature") :
signedDocument.GetElementsByTagName("Signature");
signedXml.LoadXml((XmlElement)nodeList[0]);
validated |= signedXml.CheckSignature(publicMetadataCert, true);
}
return validated;
}
else{
XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
signedDocument.GetElementsByTagName("ds:Signature") :
signedDocument.GetElementsByTagName("Signature");
signedXml.LoadXml((XmlElement)nodeList[0]);
return signedXml.CheckSignature();
}
//...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://demo.spid.gov.it/validator
</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#response_id">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
<!-- DIGEST -->
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
<!-- SIGNATURE -->
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
<!-- CERTIFICATE -->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://demo.spid.gov.it/validator
</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#assertion_id">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
<!-- DIGEST -->
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
<!-- SIGNATURE -->
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
<!-- CERTIFICATE -->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:AttributeStatement>
<saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
AGID-001
</saml:AttributeValue>
</saml:Attribute>
<!-- ... SNIP ... -->
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Click to open external image

References

Code Behaviors & Features

Detect and mitigate CVE-2025-24895 with GitLab Dependency Scanning

Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Learn more about Dependency Scanning →