• Asserting Party，即断言签发方，是签发断言的业务系统。

• Relying Party，即断言依赖方，是消费断言的业务系统。

• Principal，即认证主体，一般通过Web浏览器与两个业务系统进行交互。

• AuthnRequest，AuthnRequest由断言依赖方向认证主体签发，主要包含了断言依赖方的需要的一些信息。

• Response，Response由断言签发方向认证主体签发，包含了最为重要的断言（Assertion）信息。

• Assertion，Assertion包含了认证主体的名称、id、所属组等重要认证信息。

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

• 用户通过Web浏览器访问受保护资源

• 资源提供方(SP)向用户发出SAML断言请求，该请求包含了需要用户进行身份验证的相关信息

• 用户的身份提供方(IdP)接收到请求，并请求用户提供身份验证信息

• 用户提供身份验证信息给身份提供方

• 身份提供方向用户颁发SAML断言，该断言包含有关用户身份的信息

• 用户将SAML断言发送回资源提供方

• 资源提供方验证SAML断言的有效性，如果断言有效，则向用户授权访问所请求的资源

• 用户被授权访问资源

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

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

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

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

本地文件包含（LFI）Payload

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

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

Xslt payload

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

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

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

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

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]中根据签名算法验证了签名的合法性，这也就是漏洞在未授权情况下利用的核心原因。

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来实现认证绕过和权限提升。

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

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

重点有以下几个步骤：

首先是使用get_idp_cert获取ipd签名密钥，这里利用了data.mdb文件的特征字符定位到idp私钥的偏移，通过私钥的固定数据结构获取长度，再利用其读取取到私钥内容。

然后是伪造管理用户Assertion，这个工具通过编写一个SAML响应模板，并且响应中的Assertion部分填写的都是管理员的属性，在ID、签发时间、域名等动态参数做了标记，然后进行填充，就得到了一个伪造的SAML响应。

最后最关键的部分就是对伪造的SAML响应进行签名，这里利用的是第三方库，通过之前获取的Idp私钥对伪造的SAML响应签名，参数中的cert1和cert2是可选项。

最后生成的SAML响应就可以发送到断言消费接口（ACS）进行认证。

点击“阅读原文”获取《身份攻击-SAML》直播PPT，提取码：xmr3

直播回放点击

https://www.bilibili.com/video/BV1Mc411E7YP/?spm_id_from=333.999.0.0&vd_source=e15c532cbd7c40422d7126dc8e187632