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就像皮肤上的湿疹，它告诉我们有些事情正在发生，我们应该更仔细地查看。

eyJtZXNzYWdlIjoidHJhbnNmZXJfcHJlc3VtZWRfZXhwaXJlZCIsInVpZCI6IjY3MGE4N2M0YmQ0ODAiLCJkZXRhaWxzIjpudWxsfQ==

解码后

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

那么，如果我们将消息改为“xxxxx”呢？

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

编码后

eyJtZXNzYWdlIjoieHh4eHgiLCJ1aWQiOiI2NjYzM3h4eHh4eHh4eHg1NjdlNTc1MiIsImRldGFpbHMiOm51bGx9

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

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

是时候下载源代码并快速查看一下了。我们从以下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存储桶的访问令牌和秘密，可以使用以下一行代码请求它：

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团队容易受到这个漏洞/功能的影响是有道理的。我们设置工具并运行命令：

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日博客发布

CVE-2024-45186：Filesender未认证SSTI漏洞泄露MySQL与S3凭据及配置变量

本文详细分析了Filesender中的未认证服务器端模板注入(SSTI)漏洞CVE-2024-45186，该漏洞导致MySQL数据库凭据、S3访问密钥等敏感配置信息泄露，可能致使用户上传文件（包括加密文件）被窃取，影响荷兰多所大学。

CVE-2024–45186: Filesender中的未认证SSTI漏洞暴露MySQL和S3凭据及其他配置变量，可能泄露所有（有时加密的）用户上传文件。荷兰大学受影响。

背景

未认证漏洞

我们有哪些配置变量？让我们阅读手册：

额外内容：从Github泄露上述漏洞的补丁

讨论

时间线