<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jehan,</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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?</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div><span style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Andy Morgan, Identity & Access Management</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Oregon State University | University Information and Technology</span></div>
</div>
<div id="appendonsend"></div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of jehan.procaccia@tem-tsp.eu <jehan.procaccia@tem-tsp.eu><br>
<b>Sent:</b> Wednesday, February 21, 2024 1:35 AM<br>
<b>To:</b> Shib Users <users@shibboleth.net><br>
<b>Subject:</b> sign and/or encrypt SAML assetions, hack MITM</span>
<div> </div>
</div>
<p><span style="color: rgb(215, 63, 9);">[This email originated from outside of OSU. Use caution with links and attachments.]</span></p>
<p>Hello</p>
<p>we have a Service Provider who asked us not to encrypt SAML assertion in order for the SSO workflow to succeed</p>
<p>as discribed in : <a href="https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631697/SecurityConfiguration" class="x_moz-txt-link-freetext OWAAutoLink" style="margin-top: 0px; margin-bottom: 0px;" data-auth="Verified" id="OWA3500a713-56e4-5336-2c12-8749467f860e" data-loopstyle="linkonly">
https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631697/SecurityConfiguration</a></p>
<p><code><bean parent="RelyingPartyByName" c:relyingPartyIds="<a href="https://sp.example.org/" class="x_moz-txt-link-freetext OWAAutoLink" style="margin-top: 0px; margin-bottom: 0px;" data-auth="Verified" id="OWA90bb846a-487f-1f4f-cb79-b2214d12cc0e" data-loopstyle="linkonly">https://sp.example.org</a>">
<property name="profileConfigurations"> <list> <bean parent="SAML2.SSO" p:signAssertions="true" p:encryptAssertions="false" /></code></p>
<p>and indeed SSO + attributes (authN+Z) works fine.</p>
<p>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</p>
<p>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 :-(</p>
<p>where did we missed something ?</p>
<p>1) on the IDP (4) => force signed assertions , what is the default behaviour, where is it set ?</p>
<p>2) in the Metadata of the SP (<span style="font-size: 13px;"><b><i> </i></b><i>WantAssertionsSigned="true")</i></span></p>
<p>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.</p>
<p>4) a combination or all of 1), 2), 3) must be done ?</p>
<p>Moreover, which certificate should sign ? </p>
<p>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</p>
<p>B) or the IDP sign the assertion with the public key of the SP (from metadata again) and verify with it's private key ?</p>
<p>finnaly it is safe not to encrypt SAML assertions as long a signatures are well verified ?</p>
<p>Thanks for your help .</p>
<p>Regards .</p>
<p>jehan .</p>
</body>
</html>