前言

本文是关于如何在安全断言标记语言(Security Assertion Markup Language,SAML)中查找Bug的系列文章中的第二篇。本文将研究SAML漏洞,以及如何使用BurpSuite插件SAML Raider测试这些漏洞。如果您对于SAML和XML签名还没有一个大体的知识脉络,那么请查看我们介绍基础知识的第I部分。

SAML RAIDER

本文的第一个知识点是学习SAML Raider。SAML Raider是一款具有强大功能的SAML测试工具。SAML Raider的创建者Roland Bischofberger和Emanuel Duss将该插件描述为用于测试SAML基础架构的Burp Suite扩展。它包含两个核心功能:操作SAML消息以及X.509证书管理系统的能力。
在本文中,我们将使用SAML Raider演示如何测试每个漏洞。我们将从安装开始。
如果您已经熟悉如何使用SAML Raider,请直接跳到XML签名包装。

安装SAML RAIDER

打开Burp Suite并单击Extender选项卡
单击BApp Store子选项卡
向下滚动并单击扩展列表中的SAML Raider
单击“安装”按钮


安装完成后,我们将看到一个名为“SAML Raider Certificates”的新选项卡。


上面提到的选项卡是SAML Raider执行证书管理的地方,我们下一步将对此进行讨论。

X.509证书管理器

内置在SAML Raider中的证书管理器非常好用。它允许我们执行以下操作:
导入和导出X.509证书
显示X.509证书信息
导入和导出私钥
克隆X.509证书和证书链
编辑和自签署现有的X.509证书
我们花点时间测试一下这些功能。
首先,我们需要X.509证书。我们可以使用OpenSSL快速地生成一个。

openssl req -x509 -newkey rsa:4096 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -nodes
═══════════════════════════════════════════════════════════════════════════════════════════

Generating a 4096 bit RSA private key
...........++
...........................................................................................................................++
writing new private key to '/tmp/key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

现在我们有了证书,让我们按照下面描述的步骤将其导入SAML Raider。


完成后,我们将在顶部窗格中看到导入的证书,在底部窗格中看到有关证书的所有相关信息。
导出就像导入一样简单,所以我们不会花时间进行演示。让我们来看看克隆和编辑。克隆证书非常简单。我们需要做的就是突出显示要克隆的证书,然后单击上面窗格左侧的“Clone(克隆)”按钮。完成后,我们同时拥有导入的证书和原始版本的几乎完全相同的副本。原始和克隆之间只有两个不同点——模块和签名。我们可以通过首先导出克隆的证书,然后运行下面的diff命令来进行验证。

diff <(openssl x509 -in /tmp/cloned-cert.pem -text -noout) <(openssl x509 -in /tmp/cert.pem -text -noout)

除了克隆功能,我们可以根据自己的喜好更改证书的字段,然后单击“Save and Self-Sign”。自签名操作的功能类似于“克隆”(Clone),但需要注意的是,新证书包含了之前更改的字段。


在流程完成后,我们拥有一个有效期为1000年的证书。在执行下面讨论的一些攻击时,管理证书的能力开始发挥作用。

SAML消息编辑器

除了证书管理器之外,SAML Raider还提供了动态操作SAML消息的能力。在本节中,我们将研究截取请求,以及截取请求后该如何处理它们。
SAML Raider的创建者捆绑了一个方便的脚本来对扩展进行一些轻量级测试。我们将使用该脚本生成SAML响应,方便我们可以在burp中检查和操作。
首先,我们需要脚本。即使我们已经通过burp安装了SAML Raider,我们需要的脚本也在repo中。当我们的测试完成时,克隆repo并将其全部删除是最简单的。

git clone https://github.com/SAMLRaider/SAMLRaider.git

克隆了repo后,我们可以转到脚本目录。

cd SAMLRaider/scripts/samltest

在那之后,随着burp运行和拦截,我们可以运行samltest。

./samltest

如果burp处于运行状态并进行拦截,我们将在burp中看到等待我们的SAML响应。


截获后,我们可以在SAML Raider选项卡中查看SAML响应。


我们试着篡改一些数据。我们将拉到到SAML响应的底部,找到AttributeValue标签中包含的bowser@saml.lan值。


我们将bowser改为mario


篡改完成后,我们将在响应上进行转发。一旦它被转发,我们会看到它返回给我们的侦听器-先前启动的samltest脚本。脚本打印出XML,我们可以看到Mario@saml.lan。

...
<AttributeStatement>
  <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">
    <AttributeValue>bowser@saml.lan</AttributeValue>
  </Attribute>
  <Attribute Name="http://schemas.xmlsoap.org/claims/Group">
    <AttributeValue>Domänen-Benutzer</AttributeValue>
  </Attribute>
  <Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <AttributeValue>mario@saml.lan</AttributeValue>
  </Attribute>
</AttributeStatement>
...

编辑SAML消息时,Ctrl+Z不能撤消错误。有一个“Reset Message”按钮,用于将SAML消息恢复到其原始值。

SAML中继器

最后一点值得注意的是,SAML Raider在Burp的Repeater选项卡中添加了一个选项卡。在Repeater选项卡中操作SAML消息对于不断修改同一消息非常有用。

XML签名包装

我们将讨论的第一个攻击是XML签名包装(XSW)。这里有一份白皮书概述了攻击的详细情况。巧合的是,这篇论文也系统地介绍了SAML Raider插件。如果你想深入了解更多信息,白皮书相信是你的第一选择。
XSW基本前提是,包含XML签名的XML文档可以分两步处理:一步用于数字签名的验证,另一步用于使用XML数据的实际应用程序。考虑以下两个步骤以及用于获取单个XML元素的方法:
XML签名验证:
应用程序定位<ds:Signature><ds:Reference>元素。
应用程序使用<ds:Reference>的URL属性来确定对哪个XML元素进行了签名。
应用程序验证签名的xml元素。
验证后,同一应用程序尝试使用签名数据作为其正常操作的一部分。
应用程序的XML解析器使用自上而下的基于树的导航来定位其所需的XML元素

通常,这两种方法都应该定位到相同的XML元素,但在签名包装的情况下,攻击者会将签名的内容移动到不同的位置,并将其替换为攻击者控制的XML元素,该元素不会使XML文档无效。我们希望XML解析器找到攻击者控制的元素,而不是经过验证的元素。
现在我们已经了解了XSW的基本概念,让我们看看执行XSW的不同方法。下面介绍的每个XML签名包装攻击都与打包到SAML Raider中的8个攻击直接对应。了解了这一点,我们将了解攻击是如何工作的,以及如何使用SAML Raider执行攻击。

简要回顾

在开始之前,让我们回顾一下正常的SAML响应的简化结构。这里的关键组件是响应及其ID、签名及其引用的URL属性以及断言的主题。

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
  <saml:Issuer>...</saml:Issuer>
  <ds:Signature ...>
    <ds:SignedInfo>
      <ds:CanonicalizationMethod .../>
      <ds:SignatureMethod .../>
      <ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>...</ds:SignatureValue>
    <ds:KeyInfo>...</ds:KeyInfo>
  </ds:Signature>
  <samlp:Status>...</samlp:Status>
  <saml:Assertion ...>
    <saml:Issuer>...</saml:Issuer>
    <ds:Signature ... >...</ds:Signature>
    <saml:Subject>
      <saml:NameID ...>...</saml:NameID>
      <saml:SubjectConfirmation ...>
        <saml:SubjectConfirmationData .../>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions ...>...</saml:Conditions>
    <saml:AuthnStatement ...>...</saml:AuthnStatement>
    <saml:AttributeStatement>...</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

回想一下,当标识提供者(IDP)返回服务提供者(SP)时,我们会收到SAML响应(下面流程图中的步骤6)。

XML签名包装攻击-1

XSW-1处理SAML响应。它复制SAML响应和断言,然后将原始签名作为复制的响应的子元素插入到XML中。假设XML解析器在签名验证后在文档顶部找到并使用复制的响应,而不是原始的签名响应.

XML签名包装攻击-2

与XSW-1类似,XSW-2处理SAML响应。XSW-1和XSW-2是唯一处理响应的两种攻击方式。-1和-2之间的关键区别在于,XSW-2使用的签名类型是分离的签名,其中XSW-1使用封装签名。恶意响应的位置保持不变。

XML签名包装攻击-3

XSW-3是包装断言元素的XSW的第一个示例。SAML Raider将复制的Assertion作为根Response元素的第一个子元素插入。原始断言是复制的断言的兄弟节点。

XML签名包装攻击-4

XSW-4类似于-3,除了在这种情况下,原始断言成为复制的断言的子节点。

XML签名包装攻击-5

XSW-5是断言包装的第一个实例,我们看到签名和原始断言不在三种标准配置中的任何一个(封装/分离)。在这种情况下,复制的断言封装签名。

XML签名包装攻击-6

XSW-6将其复制的断言插入到与-4和-5相同的位置。这里有趣的一点是,复制的断言封装了签名,而签名又封装了原始断言。

XML签名包装攻击-7

XSW-7插入一个扩展元素,并将复制的断言作为子元素添加。扩展是具有限制性较小的架构定义的有效XML元素。本白皮书的作者针对OpenSAML库开发了此方法。OOpenSAML使用模式验证来正确地将签名验证期间使用的ID与处理的断言的ID进行比较。作者发现,在复制的断言与原始断言的ID相同的情况下,如果复制的断言是具有较少限制的模式定义的元素的子元素,则可以绕过此特定对策。

XML签名包装攻击#8

XSW-8使用另一个限制性较小的XML元素来执行XSW#7中使用的攻击模式的变体。这一次,原始断言是限制较少的元素的子元素,而不是复制的断言。

XML签名包装方法

SAML Raider可以很容易地执行签名包装攻击。第一步是制定拦截规则拦截SAML消息。首先转到Proxy选项卡,然后是Options子选项卡。然后,创建或编辑具有与下面的参数匹配的规则。


有了规则,我们就可以开始拦截了,而且我们只捕获包含SAMLResponse参数的http请求。
一旦拦截了SAML响应,我们将通过按Ctrl+r或右键单击请求并使用上下文菜单单击Send to Repeater,将请求发送到Burp的Repeater。
要执行多个XSW攻击,我们需要保留原始请求。在某些情况下,中继器中的SAML Raider选项卡无法使用“重置消息”按钮将已被篡改的SAML响应恢复到其原始状态。这就是为什么我们将原始文件保存在代理中,并继续将原始文件发送到Repeater。
一旦我们在Repeater中收到请求,我们就可以打开SAML Raider选项卡。

接下来,使用SAML Raider选项卡中的下拉列表并实现其中一种XSW攻击就变得毫不费力。

在使用签名包装攻击后,可以单击go发送更改后的SAML响应。
如果要尝试其他XSW攻击,则需要将原始消息重新发送到中继器。然后应用我们想要尝试的下一个XSW攻击。我们这样做是为了确保基本消息保持一致,并且在执行其他攻击时不会留下以前攻击的痕迹。

如果尝试XSW的过程中导致访问服务提供商,请立即注销并重复此过程。使用有效的XSW,尝试篡改任何看起来像用户标识的可能参数的属性(例如,将user1更改为admin,等等)。

未完待续:

原文:https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖