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

背景

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

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

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

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

未授权漏洞

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

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

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

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

1

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

Base64解码后：

1

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

如果我们将消息更改为"xxxxx"：

1

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

编码后：

1

eyJtZXNzYWdlIjoieHh4eHgiLCJ1aWQiOiI2NjYzM3h4eHh4eHh4eHg1NjdlNTc1MiIsImRldGFpbHMiOm51bGx9

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

源代码分析

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

是时候下载源代码并快速查看。我们从GitHub下载代码库（链接来自易受攻击的最新版本）。

解压ZIP文件后，我们需要找到用于替换base64编码字符串的代码。

最快的方法是寻找解码这些字符串的本机PHP函数base64_decode：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


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}字符串，有趣！由于我们的消息中没有任何{}字符，此代码不会将其替换为空字符串。

配置变量泄露

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

糟糕！我们能够转储FileSender实例中设置的配置变量。无需认证。

这意味着如果我们能够获取用户名、密码和数据库主机+端口，我们可能能够进行认证。大多数数据库配置正确，不会暴露给公共互联网。然而，我过去见过许多部署的PHP应用程序在同一主机上运行phpMyAdmin实例以方便数据库管理。这种泄露与此类工具结合可能是致命的。

还有更多吗？是的。云文件托管，即S3或Azure。S3访问密钥和密钥也使用配置变量设置。

将我们的异常设置为base64编码值：

1

{"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

所有文件都暴露了。如果用户设置了密码，其中一些可能被加密，但如果未设置密码，则可能暴露。

补丁泄露

2024年8月2日，trufflehog发布了一些重要的研究：TruffleHog现在可以找到GitHub上所有已删除和私有的提交。

长话短说，如果您可以暴力破解提交ID，您可以看到任何公共GitHub仓库的隐藏提交。由于FileSender托管在GitHub上，FileSender团队很可能容易受到此错误/功能的影响。

运行命令后，我们得到了一个隐藏的git提交列表，其中一个隐藏的补丁包含了我们的错误！

时间线

2024年6月7日：发现SSTI漏洞，发现SURF实例受影响，通知SURF CERT
2024年6月10日：与FileSender核心开发人员通话，解释漏洞
2024年6月13日：部署第一个热修复
2024年7月3日：FileSender制作了更强大的补丁，将敏感配置变量隔离到新配置文件中
2024年8月2日：Trufflehog发布研究，描述如何泄露提交
2024年8月8日：FileSender发布带有补丁的新版本
2024年9月10日：FileSender发布CVE-2024-45186博客描述漏洞
2024年10月17日：博客发布

讨论

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

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

在报告漏洞时，FileSender团队在通知所有受影响的组织、尝试让每个人打补丁方面做了出色的工作。他们还对发现的问题保持透明，并在博客文章中披露。

每个人都有漏洞，唯一重要的是您多快找到它们并修复它们。