SAML存在漏洞影响多款产品

AlexFrankly 2018-3-2 最新漏洞 0 0

一、前言

本文介绍了一个新的漏洞,该漏洞可以影响基于SAML的单点登录(single sign-on,SSO)系统。具备访问认证权限的攻击者可以利用这个漏洞,在不知道受害者密码的前提下,让SAML系统以受害者身份进行认证。

作为Duo Security的高级研究团队,Duo Labs发现有多个厂商受此漏洞影响,如下所示:

 
OneLogin - python-saml - CVE-2017-11427
OneLogin - ruby-saml - CVE-2017-11428
Clever - saml2-js - CVE-2017-11429
OmniAuth-SAML - CVE-2017-11430
Shibboleth - CVE-2018-0489
Duo Network Gateway - CVE-2018-7340

如果用户需要使用基于SAML的SSO方案,我们建议用户更新受影响的软件以修补此漏洞。如果你是Duo Security的客户,正在使用Duo Network Gateway(DNG),你可以参考我们的产品安全公告了解更多信息。

 

二、SAML Responses简介

SAML的全程是Security Assertion Markup Language(安全声明标记语言),是单点登录系统常用的一种标准。Greg Seador写了一篇很好的教学指南来介绍SAML,如果你对此不甚了解,我强烈建议你阅读这篇指南。

为了理解这个漏洞,我们需要了解SAML Response对服务提供商(Service Provider,SP)的意义以及具体处理过程,这是一个重要概念。Response处理起来有许多细节之处,但可以简化为如下步骤:

1、用户向身份提供商(Identity Provider,IdP)发起认证请求,IdP(比如Duo或者GSuite)会生成经过签名的SAML Response。用户浏览器随后会将response转发给某个SP(如Slack或者Github);

2、SP验证SAML Response的签名;

3、如果签名有效,则通过SAML Response中用于身份标识的某个字符串(如NameID)来识别出需要对哪个用户进行认证。

一个非常简单的SAML Response结构如下所示:

<SAMLResponse>
    <Issuer>https://idp.com/</Issuer>
    <Assertion ID="_id1234">
        <Subject>
            <NameID>user@user.com</NameID>
        </Subject>
    </Assertion>
    <Signature>
        <SignedInfo>
            <CanonicalizationMethod Algorithm="xml-c14n11"/>
            <Reference URI="#_id1234"/>
        </SignedInfo>
        <SignatureValue>
            some base64 data that represents the signature of the assertion
        </SignatureValue>
    </Signature>
</SAMLResponse>

上面这个示例省略了许多信息,但省略的这些信息对于这个漏洞而言并不重要。上述XML数据中,最重要的两个元素为Assertion以及Signature。Assertion元素表达的意思是:“Hey,我是IdP,认证了user@user.com这个用户”。Assertion元素会对应一个签名,作为Signature元素的一部分存放在XML结构中。

如果Signature元素准确无误,应该能阻止对NameID的篡改。由于SP很有可能会使用NameID来判断需要对哪个用户进行身份认证,因此该签名就能阻止攻击者将他们自己的NameID信息从attacker@user.com修改为user@user.com。如果攻击者能够在不破坏签名的前提下修改NameID字段,那么这将是非常糟糕的一件事情(敲黑板,划重点)。

 

三、XML规范化

与XML签名有关的另一个方面是XML规范化(canonicalization)。XML规范化可以让逻辑上相等的两个XML文档在字节上拥有相同的表现形式。比如:

 <A X="1" Y="2">some text<!-- and a comment --></A>

以及

 < A Y="2" X="1" >some text</ A >

这两个XML文档拥有不同的字节表现形式,但传达的是相同的意思(也就是说这两者逻辑上相同)。

XML规范化操作先于签名操作进行,这样可以防止XML文档中一些无意义的差异导致不同的数字签名。这点很重要,所以我在这里强调一下:多个不同但相似的XML文档可以具备相同的签名。大多数情况下这是一件好事,具体哪些差异比较重要由规范化算法所决定。

在上面那个SAML Response中,你可能会注意到CanonicalizationMethod这个元素,该元素指定了签名文档之前所使用的规范化算法。XML签名规范中列出了几种算法,但实际上最常用的算法貌似是http://www.w3.org/2001/10/xml-exc-c14n#(我将其缩写为exc-c14n)

exc-c14n还有另一种变体,即http://www.w3.org/2001/10/xml-exc-c14n#WithComments。这款变体并不会忽略注释信息,因此前面我们给出的两个XML文档会得到不同的规范化表示形式。这两种算法的区别也是非常重要的一点。

 

四、XML API

该漏洞之所以存在,原因之一就在于不同的XML库(如Python的lxml或者Ruby的REXML)存在一些微妙且意料之外的处理方法。比如,考虑如下NameID XML元素:

 <NameID>kludwig</NameID>

如果你想从该元素中提取用户身份信息,在Python语言中,你可能会使用如下代码:

from defusedxml.lxml import fromstring
payload = "<NameID>kludwig</NameID>"
data = fromstring(payload)
return data.text # should return 'kludwig' 

这段不难理解吧,.text方法会提取出NameID元素所对应的文本。

现在,如果我稍微修改一下,往该元素中添加一点注释,会出现什么情况呢:

 
from defusedxml.lxml import fromstring
doc = "<NameID>klud<!-- a comment? -->wig</NameID>"
data = fromstring(payload)
return data.text # should return ‘kludwig’?

如果你觉得即使添加了注释我们也能得到一样的结果,那么你和我还有很多人看到结果后都会大吃一惊,事实上lxml中的.text API返回的是klud!这是为什么呢?

我认为这里lxml的处理方式在技术层面上是正确的,虽然并不是那么直观。如果我们将XML文档看成一棵树,那么XML文档看上去如下所示:

element: NameID
|_ text: klud
|_ comment: a comment?
|_ text: wig 

lxml并没有读取第一个text节点结束后的text节点。而没有添加注释的节点如下所示:

 
element: NameID
|_ text: kludwig

这种情况下,程序解析完第一个text节点后就不再处理也非常合理。

表现出类似行为的另一个XML解析库为Ruby的REXML库。根据get_text方法的文档描述,我们就能理解为何这些XML API会表现出这种行为:

[get_text] 会返回第一个子Text节点,如果不存在则返回nil。该方法会返回实际的Text节点,而非String字符串内容。 

如果所有的XML API都遵循这种处理方式,那么在第一个子节点后就停止提取文本虽然看起来并不直观,但可能不会造成任何问题。不幸的是情况并非如此,某些XML库虽然包含几乎相同的API,但提取文本的方式却并不相同:

import xml.etree.ElementTree as et
doc = "<NameID>klud<!-- a comment? -->wig</NameID>"
data = et.fromstring(payload)
return data.text # returns 'kludwig' 

我也碰到过一些实现方法,这些方法并没有利用XML API来实现这一功能,而是自己进行文本提取,简单地提取出第一个子节点中的文本,这也是子字符串文本提取的另一种方法。

 

五、漏洞说明

现在已经有3个因素能够触发该漏洞:

1、SAML Response中包含用来标识认证用户的字符串;

2、(大多数情况下)XML规范化处理会删除注释信息,不用于签名验证中,因此往SAML Response中添加注释并不会破坏签名有效性。

3、当包含注释信息时,XML文本提取过程可能只会返回XML元素中文本字符串的子串。

因此,当攻击者具备user@user.com.evil.com账户的访问权限时,就可以修改自己的SAML断言,在SP处理时将NameID修改为user@user.com。现在,只要在之前的SAML Response中添加7个字符,我们就能构造出攻击载荷,如下所示:

<SAMLResponse>
    <Issuer>https://idp.com/</Issuer>
    <Assertion ID="_id1234">
        <Subject>
            <NameID>user@user.com<!---->.evil.com</NameID>
        </Subject>
    </Assertion>
    <Signature>
        <SignedInfo>
            <CanonicalizationMethod Algorithm="xml-c14n11"/>
            <Reference URI="#_id1234"/>
        </SignedInfo>
        <SignatureValue>
            some base64 data that represents the signature of the assertion
        </SignatureValue>
    </Signature>
</SAMLResponse> 

六、如何影响

现在说一下具体影响。

出现这种行为并不是一件好事,但也并非总是能被成功利用。SAML IdP以及SP有各种配置选项,因此这一漏洞所能造成的实际影响范围也因人而异。

比如,如果某些SAML SP使用email地址并且验证域名是否位于白名单中,那么这种SP与那些使用任意字符串作为用户标识符的SP相比就更加安全一些。

对于IdP而言,向用户开放账户注册功能可能会使问题变得更加严重。手动管理用户账户注册会多一层安全屏障,使漏洞利用起来更加困难。

 

七、缓解措施

如何缓解这个漏洞在某种程度上取决于用户与SAML的具体关系。

Duo软件的用户

Duo已经发布了1.2.10版Duo Network Gateway的安全更新。如果你将DNG用作SAML服务提供商,尚未更新到1.2.10或者更新版本(目前1.2.10是最新版本),我们建议您及时升级。

大家可以参考Duo的产品安全公告(PSA)了解此漏洞的更多细节。

运行或维护IdP或者SP的用户

最好的缓解措施就是确保处理SAML的库不受到此问题影响。我们发现了多个SAML库要么利用了不甚直观的XML API,要么自己错误实现了文本提取功能,但我相信还有更多的库没有很好地处理XML节点中的注释。

另一种可能的缓解措施就是默认采用不会忽略注释的规范化算法,比如http://www.w3.org/2001/10/xml-exc-c14n#WithComments。使用这种规范化算法后,攻击者添加的注释会破坏签名的有效性,但我们无法修改具体使用的规范化算法标识,想修改的话需要IdP以及SP的支持,这可能不是一种通用的缓解措施。

此外,如果你的SAML SP强制使用了双因素身份认证机制,这种情况就比较安全,因为该漏洞只能让攻击者绕过用户的第一层身份认证机制。请注意,如果你的IdP同时负责第一层以及第二层身份认证,那么该漏洞很有可能会同时绕过这两层保护。

维护SAML处理库的用户

此时最显而易见的缓解措施是确保所使用的SAML库在处理带有注释的XML元素时,可以成功提取出该元素的全部文本。我发现大多数SAML库都具备某种形式的单元测试功能,并且想要更新测试也是非常方便的一件事情(比如提取像NameIDS之类的属性,在文档签名之前添加注释)。如果测试能够继续通过,那么一切顺利。否则,你可能就受到此漏洞影响。

另一种可能的缓解措施就是更新所使用的库,对于任何处理过程(如文本提取)都要在签名验证之后使用规范化的XML文档,这样就能防护此漏洞以及XML规范化过程所带来的其他漏洞。

维护XML解析库的用户

从我个人角度来看,这么多程序库受到此漏洞影响表明许多用户认为XML内部文本API能够正常处理注释数据,而这种现象也敦促我们去修改那些API的处理机制。然而,我并不认为XML库开发者需要因此做出太大改动,他们可以采取比较合理措施,比如保持API现状,然后在文档中做出相应说明。

另一种缓解措施就是改进XML的标准。经过研究后,我并没有发现能够规范正确行为的任何标准,我们可能需要指定相关的这些标准如何协同工作。

 

八、时间线

大家可以参考此处链接了解我们的漏洞披露策略。对于这个漏洞,由于影响多个厂商,我们决定与CERT/CC一起协商披露时间,具体时间线如下:

2017-12-18:联系CERT/CC,提供漏洞信息。

2017-12-20:CERT/CC及时跟进,询问了一些细节。

2017-12-22:回答CERT/CC提出的问题。

2018-01-02至2018-01:通过邮件与CERT/CC进一步讨论该问题。

2018-01-24:CERT/CC完成内部分析流程,通知受影响的厂商。

2018-01-25:厂商确认CERT/CC的报告。我们与CERT/CC以及相关厂商进一步沟通,进一步解释该问题以及其他攻击方法。

2018-01-29:CERT/CC确认了可能受此漏洞影响的其他厂商并与之联系。

2018-02-01:Duo Labs为每个受影响的厂商保留了CVE编号。

2018-02-06:Duo检查并确认了CERT/CC的漏洞技术备注草案。

2018-02-20:最后确认所有受影响的厂商已经做好漏洞披露准备。

2018-02-27:漏洞披露。

感谢CERT/CC帮助我们披露次漏洞,感谢CERT/CC联系的所有相关组织及人员能够快速响应此漏洞。

转载请注明来自华盟网,本文标题:《SAML存在漏洞影响多款产品》

喜欢 (0) 发布评论