sign and/or encrypt SAML assetions, hack MITM
jehan.procaccia at tem-tsp.eu
jehan.procaccia at tem-tsp.eu
Tue Mar 5 19:15:32 UTC 2024
Hi
finally this thread conviced the SP vendor to honor not only assertion
signature, but also Responses signatures .
As I understood from this thread, it is better to Sign responses, so,
what should I do ?:
1) set in that SP metadata a "/Want*Response*Signed="true"/ ? (if this
directive exist ? , didn't found that on shibboleth Doc, only
/Want*Assertions*Signed)/
2) as the IDP signs by default responses, maybe the best solution is to
set nothing regarding signature in SP medatada ?
3) as I still have to override for that SP in/relying-party.xml/ the
fact that it doesn't encrypt Assertion => /p:encryptAssertions="false"/
, should I set there |signResponses="true" , or again it it not
necessary as the IDP does this (signResponses) by default ?
|
Thanks .
jehan
On 29/02/2024 00:16, Morgan, Andrew J wrote:
> 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
> <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/ <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
> <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
> <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/20240305/3de75623/attachment.htm>
More information about the users
mailing list