sign and/or encrypt SAML assetions, hack MITM

[jehan.procaccia at tem-tsp.eu]

hi,

On 21/02/2024 13:21, Peter Schober via users wrote:
> jehan.procaccia at tem-tsp.eu  <jehan.procaccia at tem-tsp.eu>  [2024-02-21 10:35 CET]:
>> 2) in the Metadata of the SP (/**WantAssertionsSigned="true") *
> Again, this is actually telling the IDP "This SP has a bug and cannot
> process signed Responses, please sign the Assertion instead".
>
> Setting this it's not necessary to signal to the IDP "please sign, I
> don't like to be sent SAML Responses/Assertions without any
> authenticity/integrity at all" as that should be the norm, not
> something you need explicit signalling for.
>
OK then, so no need to override relying-party with 
|<beanparent="SAML2.SSO"*p:signAssertions="true"*|

nor /Metadata of the SP (WantAssertionsSigned="true")/

as it the default behaviour of the SP to sign (which indeed I saw with 
BURP interceptions)

>> 3) in the SP code implementation, it should verifiy the signature and hence
>> sees that the NameID value modification by the MITM broke the signature.
> Did you say you removed the signature? Nothing broken, then?

yes removing the signature on the fly (MITM) allowed us to impersonate 
on the SP, so this SP does not verify the signature.

it is up to the SP code (dotNet ) to check the signature, then I must 
instruct the Vendor to do that,

in order to help them to patch their code, is there a best-practice / 
doc of workflows ,  to do a correct authenticity/integrity of SAML 
exchanges which I can direct them to ?

>> Moreover, which certificate should sign ?
> The key the IDP publishes for that purpose, usually via its metadata?

Yes , IDP keys are in the Metadata, and there is one for encrypt and 
another one for signing , as defaulted from IDP4 install 
(idp.properties) [1]

[1]

/idp.signing.key=%{idp.home}/credentials/idp-signing.key
idp.signing.cert=%{idp.home}*/credentials/idp-signing.crt*
idp.encryption.key=%{idp.home}/credentials/idp-encryption.key
idp.encryption.cert=%{idp.home}/credentials/idp-encryption.crt/

but the vendor SP doesn't provide certificate in its very minimalist 
Metadata [2]

[2] /*
*/

/<md:EntityDescriptor cacheDuration="PT604800S" 
entityID="https://vendor-sp.int.fr" validUntil="2030-10-18T09:55:33Z">
     <md:SPSSODescriptor AuthnRequestsSigned="false" 
*WantAssertionsSigned="false"* 
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
         <md:AssertionConsumerService 
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://vendor-sp.int.fr/SpDotNet/Core/Log.aspx?" index="1"/>
     </md:SPSSODescriptor>
</md:EntityDescriptor>
/

I guess that we must remove from that SP metadata the 
*WantAssertionsSigned="false" *! or is doesn't matter as long as the IDP 
sign it anyway ?/**/

>> finnaly it is safe not to encrypt SAML assertions as long a
>> signatures are well verified ?
> So definitively encrypting Responses/Assertions is safer/more secure,
> it's widely supported (depending on whether you work more in
> vendor-world or more in the open source or academic community) and
> clearly the better choice -- assuming there even is a choice.
> If the SP doesn't support it your only choice often comes down to not
> using that SP's services. And whether that's an actual choice you have
> possibly mostly depends on your relationship with your own management
> and/or IT security / risk management team(s).

We are academic, but vendor not, and we need that SP services , so 
that's why I want to help them doing the right thing .

at least , if not encrypted, *sign* the SAML exchange so that if a MITM 
occurs , the impersonate fails, which is not the case right now ...

thanks , Jehan .

> HTH,
> -peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240221/d46de81f/attachment.htm>