sign and/or encrypt SAML assetions, hack MITM

[jehan.procaccia at tem-tsp.eu]

Hello

we have a Service Provider who asked us not to encrypt SAML assertion in 
order for the SSO workflow to succeed

as discribed in : 
https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631697/SecurityConfiguration

|<beanparent="RelyingPartyByName"c:relyingPartyIds="https://sp.example.org">||<propertyname="profileConfigurations">||<list>||<beanparent="SAML2.SSO"p:signAssertions="true"p:encryptAssertions="false"/>|

and indeed SSO + attributes (authN+Z) works fine.

However there is a serious security hack possible in that case, we can 
intercept the http flows with BURP as a proxy acting as a Man In The Middle

by removing the signature xml elements in the final SAML success login 
assertion  and  changing nameID of the user who just connected (me for 
example),  with the target user uid,  enables us to impersonate that 
target uid . Finally I am connected as the targeted user without knowing 
its password :-(

where did we missed something ?

1) on the IDP (4) => force signed assertions , what is the default 
behaviour, where is it set ?

2) in the Metadata of the SP (/**WantAssertionsSigned="true") *
*/

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.

4) a combination or all of 1), 2), 3) must be done ?

Moreover, which certificate should sign ?

A) it it up to the IDP to sign SAML with it's private key and SPs 
readding the IDP public key (from emtadata) verify the signature

B) or the IDP sign the assertion with the public key of the SP (from 
metadata again) and verify with it's private key ?

finnaly it is safe not to encrypt SAML assertions as long a signatures 
are well verified ?

Thanks for your help .

Regards .

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