sign and/or encrypt SAML assetions, hack MITM

Wed Feb 28 23:16:48 UTC 2024

Hi Jehan,

The default for the Shibboleth IDP is to sign the Response, not the Assertion.

It looks like both the SAML Response and the SAML Assertion are being signed.  This is okay, but it is not necessary to sign both.  Since you are modifying the SP config using relying-party.xml anyway, you could set signResponses=false to eliminate the double signing.

If the SP wants the assertion signed, they should include that flag in their metadata (see the bottom of https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/3169288205/ProfileConfiguration-SAMLAssertion).

Andy

________________________________
From: jehan Procaccia tem <jehan.procaccia at tem-tsp.eu>
Sent: Wednesday, February 28, 2024 12:58 PM
To: Shib Users <users at shibboleth.net>
Cc: Morgan, Andrew J <morgan at oregonstate.edu>
Subject: Re: sign and/or encrypt SAML assetions, hack MITM

[This email originated from outside of OSU. Use caution with links and attachments.]

Hello,

some news about the hack I was facing (MITM allowing to impersonate because of signature not verified)

the  SP Vendor did corrected it's code, and now does check the signature of SAML reponse, they are using a library ( https://www.componentspace.com/ for their DotNet code) .

Now changing on the fly the NamedID brakes the signature and fails the login process :-)

howerver, I still have a question regarding the overrides for that SP in relying-party.xml of my IDP, now I had to force " p:signAssertions="true" [1] in order for the SSO flow to succeed

Isn't it the default behavior for the IDP to SignAssertions ?

[1]

<bean id="IMTOP9" parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://vendorsp.int.Fr<https://vendorsp.int.fr/>'}}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:signAssertions="true" p:encryptAssertions="false" p:checkAddress="false" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" p:postAuthenticationFlows="#{ {'attribute-release'} }" />
                </list>
            </property>
        </bean>

Below [2] is the final response with the succeed login assertion, why is there 2 occurences of signatures !? I am wondering if forcing p:signAssertions="true" in relying-party overrides doesn't generate that 2nd signature and hence if I finally correctly corrected that signature initial failure (MITM) ?

Thanks .

jehan

<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://spvendor.int.fr/DN/Cor/Login.aspx?"<https://spvendor.int.fr/DN/Cor/Login.aspx?> ID="_559afb4625da7388a1875db8d8abfcd5" InResponseTo="_41e01d0f-6da3-4c1e-8ad2-b506729f3c48" IssueInstant="2024-02-28T20:17:52.809Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp4mt.int.fr/idp/shibboleth</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"<http://www.w3.org/2000/09/xmldsig#>><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"<http://www.w3.org/2001/10/xml-exc-c14n#>/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"<http://www.w3.org/2001/04/xmldsig-more#rsa-sha256>/><ds:Reference URI="#_559afb4625da7388a1875db8d8abfcd5"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"<http://www.w3.org/2000/09/xmldsig#enveloped-signature>/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"<http://www.w3.org/2001/10/xml-exc-c14n#>/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"<http://www.w3.org/2001/04/xmlenc#sha256>/><ds:DigestValue>eqkNtL+bgLqmt5bzxnP8SWpF+/0pWyF05WWLoe9Lpsk=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>UsW9wqtigxJCkPei65OCChDnn1m1g0fn1NC+3iR8YGSzkDL+gcEYovMrD1L3Lr3Sd9o8qjacnfrNpPrL5UbS0D0bvkP5Kmq3aaFxTO5wKrRZ4CcxHjOFn5AcYn+osKeZCAjcNKFmmFKABII4I3vVgSpaQ9cAQ+8whoK+3wf2e7gFyMHphtgS1DAcnplHBNbmBkSeKAuz7ikc8JR5Pmth1pUi9fEovmCs2Fz/SL6zwJRpjK4V/wgehM90/xT8S3+aS7TEz1HWd5LhyK7xhCvZH4eKvnxv4e3qDUPkOZhhUiLjEARtJ1edvhM3kNW2K5y/T1rbx4AkI8IDjs/zMPwe/l51et9P9aNSU3naH8NJcacztTJKoq2LblmivSiYjiIuSuXhR2S3Q9quYkEjMl+GhXzsR6gnqFCMGPinewb+DdgO21psJatcxQd0fbXAsBd+D7q2E0DJFQxJ7VvmOR8k/67YQguhiM/5/ldPULrvysxV4psCGfpmj6TMpdZ4xvFB</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIENzCCAp+gAwIBAgIUFuvD0n2MY1kb97i5Fpj58CXbK4cwDQYJKoZIhvcNAQELBQAwHjEcMBoG
A1UEAwwTaWRwNG10LmltdGJzLXRzcC5ldTAeFw0yMTA2MDIxODA2NTJaFw00MTA2MDIxODA2NTJa
MB4xHDAaBgNVBAMME2lkcDRtdC5pbXRicy10c3AuZXUwggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAw

.... removed lines ....

CDu47TK2tz6cz5nAl0zc2lXQAYp/Ozi6P60iB8tThCfWl5xKXKGxt76V+BmdeUMGIvWDivyave40
nLu+SrEG56xu1QCaeivDj6YgUJon3Il7DnTFYriiHIDmwSCp8lK71NzJsxwoE7T2pgGySV5qhgTq</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_ddb8bd5505c6f6aa452e7238e5c19ef8" IssueInstant="2024-02-28T20:17:52.809Z" Version="2.0"><saml2:Issuer>https://idp4mt.int.fr/idp/shibboleth</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"<http://www.w3.org/2000/09/xmldsig#>><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"<http://www.w3.org/2001/10/xml-exc-c14n#>/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"<http://www.w3.org/2001/04/xmldsig-more#rsa-sha256>/><ds:Reference URI="#_ddb8bd5505c6f6aa452e7238e5c19ef8"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"<http://www.w3.org/2000/09/xmldsig#enveloped-signature>/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"<http://www.w3.org/2001/10/xml-exc-c14n#>/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"<http://www.w3.org/2001/04/xmlenc#sha256>/><ds:DigestValue>/2LlBZ/gtYHQwsNlbCANPC7OtLS4kwzsZYw+fmoG30Y=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>aZXGpM0E6PPplFqu9w0yHjS3CILLKR+tEITyokiLoZjjOucbhblytIpBlEtU1TQLlthkbmIJ3vS9EM9hHWMwRBEKb6DpfCBvTs4ie2Br+/gnggk5wkZgcTxYNLrDgLVN58XW0pSsdnXXj0wDXESKAXxycsoU6RV8Tx9eX3+AvpPgyllD2mrmfCQGiepLrHEOLW9fnx07ulWZLf3CeVIiQtMXN0jg7UpPSljIizAQCblA6Vu1WoF6XQ1k73EPJpDGqTMKtTskA563WwWFYkXWd5kU1hcT4cpsBB9/xsAYd/U22rENIiUaUJkmMCIuUFlBsf+J3Ao60w5PyesKmr7m8D/HyE0FN6njKi3uLr9O1JvYw5iQB+6+1Mck4feJZiNmj/BJMRPcQrOaui3hPsi44XTBxnzzXhR1p07Trhjd1LQyuwaKNjj18SWnq5315/jZTrXbIBs0p0AxyVTtISits3v3LJSGLfNmjQAE/zwUzHvA1aE6ZhcaL9UUrMnXWYDW</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIENzCCAp+gAwIBAgIUFuvD0n2MY1kb97i5Fpj58CXbK4cwDQYJKoZIhvcNAQELBQAwHjEcMBoG
A1UEAwwTaWRwNG10LmltdGJzLXRzcC5ldTAeFw0yMTA2MDIxODA2NTJaFw00MTA2MDIxODA2NTJa
MB4xHDAaBgNVBAMME2lkcDRtdC5pbXRicy10c3AuZXUwggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAw

.... removed lines ....

CDu47TK2tz6cz5nAl0zc2lXQAYp/Ozi6P60iB8tThCfWl5xKXKGxt76V+BmdeUMGIvWDivyave40
nLu+SrEG56xu1QCaeivDj6YgUJon3Il7DnTFYriiHIDmwSCp8lK71NzJsxwoE7T2pgGySV5qhgTq</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">proc</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData Address="157.159.52.134" InResponseTo="_41e01d0f-6da3-4c1e-8ad2-b506729f3c48" NotOnOrAfter="2024-02-28T20:22:52.814Z" Recipient="https://spvendor.int.fr/DN/Cor/Login.aspx?"<https://spvendor.int.fr/DN/Cor/Login.aspx?>/></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2024-02-28T20:17:52.809Z" NotOnOrAfter="2024-02-28T20:22:52.809Z"><saml2:AudienceRestriction><saml2:Audience>https://spvendor.int.fr<https://spvendor.int.fr/></saml2:Audience></saml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2024-02-28T20:17:52.801Z" SessionIndex="_039112ee44587b2570bbabf55b4626fd"><saml2:SubjectLocality Address="157.159.52.134"/><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>je.proca at int.fr<mailto:je.proca at int.fr></saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>proc</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>Je</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="eduPersonPrimaryAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.5" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>staff</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="displayName" Name="urn:oid:2.16.840.1.113730.3.1.241" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>Je PROCA</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>PROCA</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>proc at tets.eu<mailto:proc at tets.eu></saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion></saml2p:Response>

On 21/02/2024 21:34, Morgan, Andrew J via users wrote:
The vendor should use well-known SAML SP software.  Don't trust anyone to write their own SAML SP.  Unfortunately, I have no idea what SP software to recommend for them except the Shibboleth SP.

Andy
________________________________
From: users <users-bounces at shibboleth.net><mailto:users-bounces at shibboleth.net> on behalf of jehan.procaccia at tem-tsp.eu<mailto:jehan.procaccia at tem-tsp.eu> <jehan.procaccia at tem-tsp.eu><mailto:jehan.procaccia at tem-tsp.eu>
Sent: Wednesday, February 21, 2024 12:07 PM
To: users at shibboleth.net<mailto:users at shibboleth.net> <users at shibboleth.net><mailto:users at shibboleth.net>
Subject: Re: sign and/or encrypt SAML assetions, hack MITM

[This email originated from outside of OSU. Use caution with links and attachments.]

On 21/02/2024 16:57, Peter Schober via users wrote:
> Morgan, Andrew J via users <users at shibboleth.net><mailto:users at shibboleth.net> [2024-02-21 16:20 CET]:
>> If you are able to modify the assertion without the SP rejecting it,
>> then that SP is not validating the signature.  Personally, I would
>> not use SAML with an SP that does not validate the signature.  As
>> you have found, anyone can modify the assertion to impersonate
>> another user - critical security bug.  Have you reported this issue
>> to the vendor's security contact?
Yes Morgan, we have reported the flow to the vendor, and are activelly
working on a correction . That's why I search for best-practice Doc  on
how to instruct them to do the right thinks, any pointer to that will be
greatly appreciated .
> Testing for this on a larger scale isn't trivial (and might include
> legal aspects) but an activity within GÉANT has recently started to
> look into this:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.geant.org%2Fdisplay%2FGWP5%2FScalable%2Btesting%2Bfor%2Binsecure%2BSAML%2Bsignature%2Bvalidation&data=05%7C02%7Cmorgan%40oregonstate.edu%7C03cb1f9bcf8a4ae3eb8008dc3318b10a%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638441428344213736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mKjesR%2By6vFQOt9Y3WxP6hyg%2B4Y8jPwRj%2BdHyWInpT4%3D&reserved=0<https://wiki.geant.org/display/GWP5/Scalable+testing+for+insecure+SAML+signature+validation>
>
Thanks again Peter for that link, it describe my problem, even more , it
focuses on properly validate the signature.

in my case it is worst, there is no signature check at all, I'll care
about the authenticity of the signature in the second step .

regards , jehan .

>
> -peter
--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C02%7Cmorgan%40oregonstate.edu%7C03cb1f9bcf8a4ae3eb8008dc3318b10a%7Cce6d05e13c5e4d6287a84c4a2713c113%7C0%7C0%7C638441428344221440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=55ew17NywXC2egkjJynEDz%2BMlj027NXNPeJwrzJgZc0%3D&reserved=0<https://shibboleth.atlassian.net/wiki/x/ZYEpPw>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240228/f6b403c9/attachment.htm>