FileSender未授权SSTI漏洞致MySQL与S3凭证泄露，荷兰高校数据面临风险

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

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

背景

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

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

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

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

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

未授权漏洞

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

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

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

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

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

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

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

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

1

eyJtZXNzYWdlIjoidHJhbnNmZXJfcHJlc3VtZWRfZXhwaXJlZCIsInVpZCI6IjY3MGE4N2M0YmQ0ODAiLCJkZXRhaWxzIjpudWxsfQ==

解码后：

1

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

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

1

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

编码后：

1

eyJtZXNzYWdlIjoieHh4eHgiLCJ1aWQiOiI2NjYzM3h4eHh4eHh4eHg1NjdlNTc1MiIsImRldGFpbHMiOm51bGx9

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

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

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

是时候下载源代码并快速查看。我们从以下URL下载仓库（链接来自存在漏洞的最新版本，我链接它以便您自己查看漏洞的工作原理，我们使用commit 05b4226ef40392fdd8831b9054c858527c0249d9）。

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

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

现在我们需要用于替换该base64编码字符串的代码。

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

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

在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

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

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

如果我们现在使用消息"cfg:db_username"会怎样？它会将其放入{}中并渲染吗？

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

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

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

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

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

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

将我们的异常设置为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

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

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

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

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

六年前完成了支持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 设计
本站总访问量次 本站访客数人次