通过报告生成进行服务器入侵：案例研究

White Oak Security 的渗透测试人员在安全评估过程中经历了各种各样的安全漏洞，从普通漏洞到奇特漏洞。在最近的一次 Web 应用程序渗透测试中，我发现了一个有趣且不寻常的漏洞，我想分享一下，希望它可以帮助其他人在自己的应用程序或安全评估中发现类似的问题。

我重新创建了易受攻击的网络服务器中的漏洞，以保护客户端机密性并省略不必要的信息，同时尽可能忠实地重现发现问题的情况。

应用程序

评估重点关注一款为公司客户生成状态报告的 Web 应用程序，其用途在此不再赘述。用户可以在系统中更新其联系信息，并提供状态以供公司员工稍后查看。

以下是用户网站的简单复制：

用户输入他们的个人资料信息和状态，然后提交显示页面中显示的更改：

本页还提供该报告的 PDF 版本：

作为枚举过程的一部分，我们查看应用程序返回的文档的元数据。在本例中，PDF 文件显示该 PDF 是使用名为“wkhtmltopdf”的应用程序生成的，版本为0.12.3（https://github.com/wkhtmltopdf/wkhtmltopdf/releases/0.12.3/）：

这揭示了一些有用的信息，首先，PDF 是使用 HTML 作为输入格式生成的，还有用于创建它们的库或程序的名称和版本。检查该软件的网站后发现，PDF 生成器已经过时，如果处理未经清理的 HTML，可能会导致服务器被接管：

有趣的是，在处理 HTML 页面作为输入时，JavaScript 是默认启用的：

这种情况有望给我们的评估带来回报，因此我开始研究可以利用的途径。

开发

我开始探索该应用程序，尝试将 HTML 注入用户状态更新的各个字段。不幸的是，任何注入标签的尝试都会导致整个字段从结果页面和报告中删除：

然而，经过反复试验后，很明显，仅包含结束标签（在本例中即</b>）将导致字段的内容被保留，但结束标签却被神秘地删除：

这表明对 HTML 起始标签（即<b>）进行了更严格的过滤。现在剩下的就是确定过滤器的触发因素是什么以及如何绕过它。进一步的反复试验表明，任何带有起始括号 (<) 和紧随其后的字母的标签都是删除所有内容的触发因素。起始括号后面的任何其他字符都将保留：

进一步探究发现，对左括号后的第一个字符进行 HTML 编码允许 HTML 标签传递到应用程序并生成 PDF：

现在我们成功绕过了过滤，但是我们能做什么呢？我能够注入一个带有本地主机地址的 iframe 标签，从而显示默认的 Apache 服务器页面：

不幸的是，尝试在 iframe 中加载本地文件失败，输出中出现空白框：

但是，wkhtmltopdf的默认设置为我们提供了另一种选择。回想一下，正如主网站上所记录的那样，JavaScript 解释默认处于启用状态。这使我们能够使用 JavaScript 的 XMLHTTPRequest 功能从本地主机请求文件。

我改用更大的状态字段以获得更好的可见性，并使用 XMLHTTPRequest JavaScript 方法调用 /etc/passwd，这导致文件嵌入到生成的 PDF 文档中：

此时，我们已经证明我们能够从远程攻击者的角度查看服务器本地的文件。但是，请求的文件嵌入在 PDF 中，这不是特别优雅。为了证明这种漏洞在现实世界中具有更大的潜力，我决定创建一个有效载荷，将文件泄露到第三方主机，在本例中是 Burp Collaborator 服务器。请注意，在评估期间，我们使用了一个独立的 Collaborator 服务器，但出于本文的目的，我们使用了公共 Burp Collaborator 服务器。

XMLHTTPRequest 有效负载像以前一样发出请求以获取本地文件，然后将该调用的结果存储在文本字段中，然后对 Collaborator 服务器进行二次调用以窃取数据：

Collaborator 服务器成功接收了生成的请求，并将相关数据 URL 编码为 GET 请求参数：

从这一点开始，攻击者可以轻松地将文件内容解码为文本形式：

虽然在这种情况下可能会有更高效、更有效或更隐蔽的泄露方法，但本博客中详细介绍的方法成功地展示了此漏洞的影响。应用程序的低权限用户能够使用一组相当简单的步骤来破坏服务器：

1. 通过 PDF 元数据识别网站正在使用的 PDF 生成器的版本

2. 通过不断的反复试验来制作输入过滤器绕过

3. 将 JavaScript XMLHTTPRequest 调用注入到由存在漏洞的 PDF 生成库解释的文本字段中

从这一发现中，我们学到了两个重要的教训。首先，应该使用经过全面测试的库来过滤用户输入。就像常用的短语“永远不要自己动手加密”一样，人们永远不应该“自己动手”进行输入清理，因为有太多边缘情况需要覆盖。在这种情况下，该网站使用了一个正则表达式过滤器，如果字母字符跟在开括号 (<) 后面，则将字段的内容设置为空字符串。正则表达式可能类似于此（对于 PHP）：

$tagfilter =“/<[az]/i”；

正如我们在上例中看到的，绕过这个漏洞很容易。有许多可用于网站的清理库，它们可以更可靠地检测和删除恶意输入。

第二个教训是始终保持基本库的更新。在本例中，PDF 生成器既过时，又存在已知的严重漏洞。它还默认处理 HTML 输入中的 JavaScript 代码。因此，一旦绕过 HTML 过滤，攻击者就可以包含恶意 JavaScript 并窃取敏感文件。为了解决这个问题，网站所有者应该：

1. 保持 PDF 生成库为最新（或者在这种情况下，由于没有最近更新，则完全替换该库）。或者，如果易受攻击的库绝对必要，也可以手动修补这些库。

2. 关闭库的 JavaScript 解释，除非业务用途必不可少

3. 阻止对未知或不受信任的 URL 的出站 HTTP 请求，这可以防止数据泄露，尽管这不会阻止 PDF 文件输出

希望这个故事很有趣，并为其他渗透测试人员提供他们可能没有考虑过的利用想法或方法。我还希望它能让应用程序所有者和开发人员了解如何修复这些问题以及这些漏洞可能造成的影响。