FileSender未授权SSTI漏洞曝光MySQL与S3凭证，荷兰大学数据面临风险

本文详细分析了FileSender系统中存在的未授权服务器端模板注入漏洞(CVE-2024-45186)，该漏洞可导致MySQL数据库凭证、S3存储密钥等敏感配置信息泄露，进而可能暴露用户上传文件。影响包括荷兰多所大学在内的教育机构。

CVE-2024–45186：FileSender未授权SSTI漏洞暴露MySQL和S3凭证

背景

FileSender是一个开源Web应用程序，专为安全传输大文件而设计。FileSender的想法诞生于2007年，在欧洲研究和教育社区网络GÉANT的一次特别工作组会议上。其主要目标是通过可信中介与私人受众轻松共享任意大文件。该开源项目的治理已组织为Commons Conservancy基金会内的一个项目。

FileSender主要使用PHP构建，并利用MySQL或PostgreSQL进行数据库管理。多年来，它已发展支持各种功能，如用户身份验证、文件加密、审计跟踪、访客访问、可自定义用户界面。

需要提及的一个重要事实是支持客户端加密。这意味着在上传期间，用户可以选择加密要传输的文件；这是逐块进行的，整个过程在浏览器内使用自选密码处理。这些加密的块被上传到FileSender实例，下载者使用密码在本地解密这些块。如果从实例中窃取任何数据，它将受到密码保护。

目前，FileSender被全球需要可靠方式安全发送大文件的教育机构、研究组织和企业广泛使用。我所在的医院，阿姆斯特丹大学医学中心，和阿姆斯特丹大学就是其中之一，已使用15年。

由于我们的目标是识别有影响力的错误，这可能是一个值得仔细检查的绝佳目标。特别是，因为以SURFfilesender品牌提供该服务的SURF支持协调漏洞披露原则。

未授权漏洞

FileSender通常由经过身份验证的用户用于发送文件，因此我们希望找到一个不需要任何身份验证的错误，并找到一种方法来影响所有在线的FileSender实例。

为了映射所有未经身份验证的路径，我们启动Burp Suite，对我们的浏览器进行MITM攻击（或尝试Caido），并尝试FileSender中存在的所有功能！

最有趣的端点之一是用于下载文件的端点。显然，接收者可以是任何人（因为允许任何电子邮件地址），这意味着有未经身份验证的功能可供测试。

经过一些测试，我发现如果文件过期（默认7天后将被删除），将返回错误：

[按回车或单击以全尺寸查看图像]

重定向中的Base64，该值隐藏了什么？

URL中的Base64就像皮肤上的湿疹，它告诉我们正在发生一些事情，我们应该仔细看看。

[按回车或单击以全尺寸查看图像]

1

eyJtZXNzYWdlIjoidHJhbnNmZXJfcHJlc3VtZWRfZXhwaXJlZCIsInVpZCI6IjY3MGE4N2M0YmQ0ODAiLCJkZXRhaWxzIjpudWxsfQ==

解码后：

1

{"message":"transfer_presumed_expired","uid":"670a87c4bd480","details":null}

那么，如果我们将消息更改为"xxxxx"呢？

1

{"message":"xxxxx","uid":"66633xxxxxxxxxx567e5752","details":null}

编码后：

1

eyJtZXNzYWdlIjoieHh4eHgiLCJ1aWQiOiI2NjYzM3h4eHh4eHh4eHg1NjdlNTc1MiIsImRldGFpbHMiOm51bGx9

[按回车或单击以全尺寸查看图像]

我们看到字符串被注入到模板中，并被{ }字符包围。这闻起来像是潜在的服务器端模板注入。

因此，我们能够注入到模板标签中，如果令牌不存在，它不会渲染模板标签。我们还有什么其他选择？

是时候下载源代码并快速查看一下。我们从这个URL下载仓库（链接来自易受攻击的最新版本，我链接它以便您自己查看错误的工作原理，我们使用提交05b4226ef40392fdd8831b9054c858527c0249d9）。

[按回车或单击以全尺寸查看图像]

将代码下载为ZIP并解压缩。

现在我们需要代码来替换那个base64编码的字符串。

弄清楚这一点的最快方法是寻找解码这些字符串的本机PHP函数base64_decode。

[按回车或单击以全尺寸查看图像]

在VSCodium中打开解压后的文件夹，按CTRL + F，搜索函数base64_decode。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

/**
 * Unerialize exception from path transmission
 *
 * @param string $serialized
 *
 * @return StorableException
 *
 * @throws DetailedException
 */
public static function unserialize($serialized)
{
    $exception = (array)json_decode(base64_decode($serialized));
            
    array_walk_recursive($exception, function(&$value) {
        $value = preg_replace('`\{(tr:)*(cfg|conf|config):([^}]+)\}`', '', $value);
    });
    if (!array_key_exists('message', $exception)) {
        throw new DetailedException('not_an_exception', $exception);
    }
            
    return new self($exception);
}
}

在那里，我们第一次看到称为cfg|conf|config模板标签的东西。代码试图删除任何出现的{cfg:something}字符串，有趣！由于我们的消息中没有任何{}字符，此代码不会将其替换为空字符串。正如xxxx错误所示，在代码的某处它用{}封装了我们的输入，那么我们是否能够泄漏配置值？

我们有什么配置变量？

让我们阅读手册：https://github.com/filesender/filesender/blob/5c00bf7605ac7a24800bc92c78cd97eca45be5de/docs/v2.0/admin/configuration/index.md

[按回车或单击以全尺寸查看图像]

数据库用户名、密码和数据库名称是其中几个。

如果我们现在使用消息"cfg:db_username"会怎样？它会把它放在{}里面并渲染吗？

[按回车或单击以全尺寸查看图像]

哎哟！我们能够转储FileSender实例中设置的配置变量。未经身份验证。

这意味着，如果我们能够获取用户名、密码和数据库主机+端口，我们可能能够进行身份验证。大多数数据库配置正确，并未暴露给公共互联网。然而，我过去见过许多部署的PHP应用程序在同一主机上运行https://www.phpmyadmin.net/实例以允许轻松的数据库管理。这种泄漏与这样的工具结合可能是致命的。因为访问数据库意味着访问所有令牌以及可能所有用户上传的文件。

还有更多吗？是的。文件的云托管，即S3或Azure。再次让我们阅读文档：https://github.com/filesender/filesender/blob/5c00bf7605ac7a24800bc92c78cd97eca45be5de/docs/v2.0/cloud/index.md

S3访问密钥和密钥也使用配置变量设置。

[按回车或单击以全尺寸查看图像]

将我们的异常设置为base64编码值：{“message”:“cfg:cloud_s3_key”,“uid”:“66633xxxxxxxxxx567e5752”,“details”:null}

现在的问题是，我们实际上能否访问荷兰大学员工和学生上传的文件？

如果某人获得了S3存储桶的访问令牌和密钥，可以使用以下一行命令请求它：

1

AWS_ACCESS_KEY_ID=thekeyvalue AWS_SECRET_ACCESS_KEY=thesecretvalue aws ls s3://thebucketnamevalue --endpoint-url=https://theendpointusedtoproxytos3

[按回车或单击以全尺寸查看图像]

所有文件暴露。如果用户设置了密码，其中一些可能被加密，但如果没有设置密码，则可能暴露。请注意右侧的滚动条，我在几秒钟后中止了传入的列表。

我们现在证明了这个错误泄漏了暴露上传文件的凭证，未经身份验证。泄漏文件的影响可能存在，因为S3上传的集成，我没有再次检查当时是否存在相同的SSTI，但基于提交，我强烈怀疑是这种情况。

[按回车或单击以全尺寸查看图像]

六年前，提交了支持S3上传的代码。

以上所有内容都已负责任地披露给FileSender团队和SURF CERT。是时候修补错误并部署修复程序了！

奖励：从Github泄漏上述错误的补丁

2024年8月2日，trufflehog发布了一些伟大的研究；https://trufflesecurity.com/blog/trufflehog-now-finds-all-deleted-and-private-commits-on-github

长话短说，如果你能暴力破解提交ID，你可以看到任何公共Github仓库的隐藏提交。由于FileSender托管在Github上，FileSender团队容易受到这个错误/功能的影响是有道理的。我们设置工具并运行命令：

1

trufflehog github-experimental — repo https://github.com/filesender/filesender.git — object-discovery

喝了几杯茶后，我们得到了一个长长的隐藏git提交列表，你猜怎么着：

为FileSender中发现错误所做的隐藏补丁之一，在某个隐藏分支/分叉上提交。补丁在提交消息中泄漏了我们的错误！

先前的错误序列化导致用户控制的异常数据可能被用于模板注入，允许配置转储，这将异常存储在会话中（超出用户控制），为其分配uid，以便漂亮的错误页面可以从会话中拉回详细信息。

除了了解最初报告的错误（转储配置值）之外，我们现在还了解到修复方法是将消息存储在用户会话中。在我看来，这是一个适当的修复，因为我们无法影响存储到会话中的数据。

是时候进行另一个报告并尝试加速修补过程了，我们应该考虑错误可能被泄漏，因为任何人在运行trufflehog工具几小时后都可以看到这个补丁。

讨论

这个错误报告显示了安全设计的重要性，幸运的是FileSender实例有一个称为客户端加密的功能。任何使用适当安全密码的人都会受到保护免受此攻击。然而，此选项不是强制性的，因此用户可以选择使用此加密选项。

此外，它显示了让不同人员探测您的基础设施的重要性。不要停止于渗透测试或某些审计，让群众测试您的资产并允许他们安全地报告发现的任何漏洞。

在报告错误时，FileSender团队在通知所有受影响的组织，试图让每个人都打上补丁方面做了惊人的工作。此外，他们对发现的问题保持透明，并在博客文章中披露。

每个人都有错误，唯一重要的是你多快找到它们并修补它们。

您的组织依赖开源吗？资助这些项目并帮助它们由像我这样的研究人员持续测试。可以考虑挑战（获得固定数量的赏金并为挑战期间发现的任何错误付费）或设置标志（即上传文件、创建账户、设置软件的测试实例）并为获取标志（窃取文件、以管理员身份登录、接管实例等）提供赏金。没有人认领标志或赏金？增加它直到有人认领。

时间线

  • 2024年6月7日：发现SSTI错误，发现SURF实例受影响，通知SURF CERT
  • 2024年6月10日：与FileSender核心开发人员通话，解释错误
  • 2024年6月13日：首次热修复部署
  • 2024年7月3日：FileSender制作了更稳健的补丁，将敏感配置变量隔离到新的配置文件中
  • 2024年7月15日：新补丁导致活动部署问题，因此需要更多测试
  • 2024年8月2日：Trufflehog发布了描述如何泄漏提交的研究
  • 2024年8月3日：与FileSender团队共享使用该研究泄漏的补丁提交
  • 2024年8月8日：FileSender发布带有补丁的新版本
  • 2024年9月10日：FileSender发布CVE-2024–45186博客描述漏洞
  • 2024年10月13日：撰写此博客，与FileSender团队共享草稿
  • 2024年10月16日：SURF反馈，更新博客
  • 2024年10月17日：博客发布
comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次