[原创]IAM的主流身份验证方法之SAML协议-企业安全-看雪-安全社区|安全招聘|kanxue.com

[原创]IAM的主流身份验证方法之SAML协议

2023-5-10 18:06 4953

[原创]IAM的主流身份验证方法之SAML协议

中安网星

2023-5-10 18:06

4953

一、SAML协议介绍

SAML(Security Assertion Markup Language)是一种基于XML的开放式标准，用于在不同的安全域之间交换认证和授权数据。

1.SAML发展历史

SAML协议由结构化信息标准促进组织(OASIS)安全服务技术委员会在2002年提出，已经经历了1.0、1.1、2.0三个版本。目前国内外的主流云服务平台、SaaS应用以及一些常见软件系统，例如阿里云、AWS、Saleforce、Jira、Confluence、Sonarqube等，都支持通过SAML协议实现单点登录。

2.SAML相关概念

Asserting Party，即断言签发方，是签发断言的业务系统。
Relying Party，即断言依赖方，是消费断言的业务系统。
Principal，即认证主体，一般通过Web浏览器与两个业务系统进行交互。
AuthnRequest，AuthnRequest由断言依赖方向认证主体签发，主要包含了断言依赖方的需要的一些信息。
Response，Response由断言签发方向认证主体签发，包含了最为重要的断言（Assertion）信息。
Assertion，Assertion包含了认证主体的名称、id、所属组等重要认证信息。

3.SAML Web SSO

在SAML Web SSO场景中，认证有以下几个流程：

用户通过Web浏览器访问受保护资源
资源提供方(SP)向用户发出SAML断言请求，该请求包含了需要用户进行身份验证的相关信息
用户的身份提供方(IdP)接收到请求，并请求用户提供身份验证信息
用户提供身份验证信息给身份提供方
身份提供方向用户颁发SAML断言，该断言包含有关用户身份的信息
用户将SAML断言发送回资源提供方
资源提供方验证SAML断言的有效性，如果断言有效，则向用户授权访问所请求的资源
用户被授权访问资源

二、SAML协议攻击面

SAML是一个基于XML的认证协议，由于XML数据格式灵活、处理复杂，导致实现过程非常容易造成逻辑漏洞，并且XML本身也存在XXE、XSLT等安全风险，这一攻击面也由SAML所继承。

1.XXE攻击

XXE（XML External Entity Injection）攻击是OWASP TOP10中的常客，其本身是XML的攻击面，但由于SAML基于XML，也就继承了这一攻击面。

XXE漏洞的主要原因是XML解析器在没有禁用外部实体（ External Entity）的情况下，攻击者可以向被处理的XML文档中并且实体定义中可以包含一些控制服务器行为的指令。

XXE的常规攻击方式有以下两种：

本地文件包含（LFI）Payload

]>
&xxe;

服务端请求伪造（SSRF）Payload

]>

2.XSLT攻击

XSLT攻击指的是一种利用XSLT（Extensible Stylesheet Language Transformations）漏洞的攻击方式。XSLT是一种用于将XML文档转换为其他格式的语言，例如HTML或PDF。攻击者可以利用XSLT漏洞来执行恶意代码或获取敏感信息。

在SAML中造成XSLT的原因是SAML签名前使用了多个transform对签名内容进行一系列处理，每一个transform定义了数据处理算法，如

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>规定的是规范化算法<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>表示的是数字签名算法

在w3c组织定义的transform算法中

<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">可以用来实现XSLT转换，如果服务端没有任何校验就对SAML签名进行验证就会产生XSLT漏洞。

Xslt payload

3.XSW攻击

XSW是一种基于XML文件格式变换的攻击手法，因为XML签名的验证和断言使用通常是在两个不同的函数进行处理，如果两个模块对同一个数据有不同的处理方式，那么就可以利用这种攻击来对Response进行伪造。

4.SAML重放

SAML重放攻击主要是由于实现中没有防止重放的安全机制如随机参数、过期时间等，攻击者在截获SP签发的断言后，可以利用截获的断言向SP进行验证，获取访问权限。

5.Golden SAML

Golden SAML是一种伪造SAML断言的权限维持攻击手法，攻击者首先通过攻陷Idp服务窃取Idp签名密钥，在得到签名密钥后即可对信任该Idp的服务签署任意用户的断言获取其访问权限。这种攻击手法与黄金票据较为类似。

三、SAML漏洞案例

1.XXE

在一些漏洞众测write-up中经常可以看到XXE漏洞案例，在下图中作者通过某云服务平台SAML配置后台，通过配置Idp元数据功能插入XXE payload造成本地文件泄露。

2.CVE-2022-47966

CVE-2022-47966影响Zoho ManageEngine系列多个产品，CVSS评分高达9.8，主要原因是这些产品都使用了xmlsec 1.4.1去验证SAML签名，而这一版本的xmlsec组件包含有多个漏洞。下面是SAML签名的示例。

SP在接收到用户传入的Response后首先会对断言的的签名进行验证，通常有以下几个步骤：

1)检查断言完整性，对断言进行格式转换（规范化、数字签名格式），计算hash摘要与DigestValue内容进行对比，如果结果不同说明签名被篡改。

2)利用Idp公钥解密SignatureValue，与DigestValue进行对比，如果结果不同说明断言不是由信任的Idp签发。

3)以上两个步骤同事满足时说明签名是合法的。

以上3个步骤中1和2的处理顺序是可以互换的，但是在步骤1中对断言进行转换会产生XSLT注入漏洞，如果按照这个顺序处理会造成未授权命令执行漏洞。

下图中xmlsec1.4.1对签名进行检查的逻辑，在[1]处首先检查了签名内容的完整性，也就是上述步骤1的内容，在[2]中根据签名算法验证了签名的合法性，这也就是漏洞在未授权情况下利用的核心原因。

3.CVE-2022-41912

CVE-2022-41912是crewjam/saml由go语言实现的saml库中存在的一个认证绕过的漏洞，这个漏洞是由于使用了两种不同方式处理Response导致的签名验证绕过。解析SAML响应的代码如下，首先在A代码部分利用golang原生的xml反序列化函数将SAML响应反序列化到Response结构中，在B代码又利用etree来将Response反序列化为Document对象。然后在C代码块将这两对象传入validateXMLResponse函数中。

跟进这个函数，在红框部分将responseEL变量传入validateSigend进行签名验证，通过后返回resp.Assertion，注意这里的responseEL和resp分别是上一步骤通过etree和go反序列化得到的结果。这里验证的是responseEL返回的却是resp的逻辑是这个漏洞的关键。

根据validateSigned函数，这里的处理逻辑是利用findChild函数从responseEL中找到Assertion，再从Assertion中找到Signature元素，两个元素不为空且Assertion合法性验证通过的话就通过验证。

回头再看一下最开始反序列化的地方利用go原生反序列化得到的Response结构定义如下，在这个结构中只有一个Assertion对象，如果处理的Response含有多个Assertion元素时，按照golang的处理，这里会取到最后一个Assertion。

再看一下findChild的实现，这里的逻辑是遍历所有子元素，如果命名空间和标签名匹配上就马上返回这个元素，所以在含有多个Assertion的情况下在validateSigned中得到的第一个Assertion。

作者给出的payload如下，SAML响应中包含两个Assertion其中第一个合法，第二个是伪造的Assertion。

最后处理的逻辑就是验证第一个Assertion，由于是合法的，可以通过验证，但是返回的是第二个也就是伪造的Assertion，如果通过验证的是一个低权限用户，那么就可以伪造一个高权限的用户Assertion来实现认证绕过和权限提升。

4.vcenter_saml_login

vcenter_saml_login是一个vCenter后利用工具，主要场景是拿到vCenter服务器root权限之后需要登录vCenter web控制台进行下一步攻击。

这个工具中也利用了SAML签名，我们可以结合SAML协议流程来分析一下这个工具的利用过程。首先看参数，target指定vCenter服务器的ip，path参数指定的是data.mdb文件，data.mdb是vCenter中用于存储ldap数据的文件，而vCenter用于SAML签名的私钥就存储在ldap数据库中。