一、介绍
在这篇博文中,我们将分析CVE-2024-45409,这是一个影响Ruby-SAML, OmniAuth-SAML库的关键漏洞,它有效地影响了GitLab。此漏洞允许攻击者绕过SAML身份验证机制,并通过利用SAML响应处理方式中的缺陷获得未经授权的访问。这个问题的出现是由于用于保护SAML断言的数字签名的验证存在弱点,从而允许攻击者操纵SAML响应并绕过关键的安全检查。
二、SAML消息验证
SAML是一种广泛使用的协议,用于在身份提供者(idp)和服务提供者(sp)之间交换身份验证和授权数据。确保这种交换安全性的一个关键部分是通过数字签名和摘要验证来验证数据的完整性和真实性。
在本节中,我们将首先解释SAML签名和摘要验证是如何工作的,然后探索Ruby-SAML中可以用来规避签名验证的绕过。
三、SAML签名是如何工作的?
在典型的SAML响应中,Assertion元素保存关键的安全信息,例如经过身份验证的用户的详细信息。为了确保此信息未被篡改,对其进行了数字签名。
1.断言元素和摘要计算
Assertion元素包含安全凭证,并且通过计算断言的规范化内容的摘要(散列)来保护该元素的完整性。在计算此摘要之前,将从断言中删除签名节点。然后将此摘要包含在签名元素的SignedInfo块中。
2.签名元素和签名信息块
Signature元素包含一个SignedInfo块,它包含:
-
指向断言的引用URI。
-
DigestValue,表示断言块的摘要,计算后存储在此块中。
一旦将摘要包含在SignedInfo块中,就使用IdP的私钥对整个SignedInfo进行签名,并将结果放置在SignatureValue元素中。
下面是该结构的一个简化的XML示例:
<Assertion ID="_abc123"> <Signature> <SignedInfo> <Reference URI="#_abc123"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <DigestValue>abc123DigestValue</DigestValue> </Reference> </SignedInfo> <SignatureValue>SignedWithPrivateKey</SignatureValue> </Signature> <!-- Assertion contents --></Assertion>
四、摘要和签名如何确保完整性?
对断言的任何修改都会导致其哈希值发生变化。然而,由于“SignedInfo”元素中包含原始哈希值,并且该值是用IdP的私钥进行签名的,因此攻击者无法在不使签名失效的情况下更改“SignedInfo”块。这一机制确保服务提供商(SP)在验证响应时能够检测到对断言的未经授权修改。
签名验证流程
当服务提供商(SP)接收到SAML响应时,将执行两项关键检查:
-
摘要验证:SP会计算断言(移除签名节点后)的摘要,并将其与“SignedInfo”块中的摘要值进行比较。如果两者不匹配,则表明断言已被篡改。
-
签名验证:SP使用IdP的公钥来验证“SignedInfo”块上的签名。如果签名有效,则确认IdP已对消息进行了合法签署,且消息未遭篡改。
五、Ruby-SAML旁路
在Ruby-SAML库中,在实际签名验证之前会发生几次验证,包括模式验证和对断言数量的检查。然而&