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，进行中间人攻击（或尝试Caido），并尝试FileSender中存在的所有功能！

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

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

[按回车或点击查看完整尺寸图像]

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

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

[按回车或点击查看完整尺寸图像]

eyJtZXNzYWdlIjoidHJhbnNmZXJfcHJlc3VtZWRfZXhwaXJlZCIsInVpZCI6IjY3MGE4N2M0YmQ0ODAiLCJkZXRhaWxzIjpudWxsfQ==

解码后： {"message":"transfer_presumed_expired","uid":"670a87c4bd480","details":null}

那么，如果我们将消息更改为"xxxxx"呢？ {"message":"xxxxx","uid":"66633xxxxxxxxxx567e5752","details":null}

编码后： 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

/**
 * 从路径传输反序列化异常
 *
 * @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 设计
本站总访问量次 本站访客数人次