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

背景

FileSender是一款专为安全传输大文件设计的开源Web应用程序。该项目最初于2007年在泛欧研究教育网络GÉANT的特别会议上提出，主要目标是通过可信中介实现与私人受众的无痛大文件共享。该开源项目的治理结构隶属于Commons Conservancy基金会。

FileSender主要使用PHP构建，采用MySQL或PostgreSQL进行数据库管理。多年来，它已发展支持多种功能，包括用户认证、文件加密、审计追踪、访客访问和可定制用户界面。

需要特别指出的是，FileSender支持客户端加密。这意味着用户在上传时可以选择加密要传输的文件，这个过程以数据块形式进行，整个处理在浏览器内使用自选密码完成。这些加密的数据块上传到FileSender实例，下载者使用密码在本地解密。如果从实例中窃取任何数据，都将受到密码保护。

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

由于我们旨在识别有影响力的漏洞，这成为了深入检查的绝佳目标。特别是因为SURF（以SURFfilesender品牌提供该服务的组织）支持协调漏洞披露原则。

未授权漏洞

FileSender通常由认证用户使用来发送文件，因此我们希望找到不需要任何认证的漏洞，并找到影响所有在线FileSender实例的方法。

为了映射所有未授权路径，我们启动Burp Suite，对浏览器进行中间人攻击（或尝试使用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下载仓库（链接来自存在漏洞的最新版本，我提供链接以便您自己查看漏洞工作原理，我们使用commit 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


/**
 * 从路径传输反序列化异常
 *
 * @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日：发布博客

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

研究人员发现Filesender存在未授权服务器端模板注入漏洞，攻击者可利用此漏洞获取数据库凭证和云存储密钥，导致用户上传文件泄露。该漏洞影响荷兰多所高校，涉及敏感数据安全。

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

背景

未授权漏洞

有哪些配置变量？

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

讨论

时间线