sign and/or encrypt SAML assetions, hack MITM

[Morgan, Andrew J]

Hi Jehan,

We have several SPs that don't support encrypted assertions, and we disable encryption for those SPs.  The IDP will still sign the response or assertion, which prevents tampering with the contents without detection.

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?


​Andy Morgan, Identity & Access Management
Oregon State University | University Information and Technology

________________________________
From: users <users-bounces at shibboleth.net> on behalf of jehan.procaccia at tem-tsp.eu <jehan.procaccia at tem-tsp.eu>
Sent: Wednesday, February 21, 2024 1:35 AM
To: Shib Users <users at shibboleth.net>
Subject: sign and/or encrypt SAML assetions, hack MITM


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

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

<bean parent="RelyingPartyByName" c:relyingPartyIds="https://sp.example.org<https://sp.example.org/>"> <property name="profileConfigurations"> <list> <bean parent="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/2e49f1fa/attachment.htm>