博客
2024 年 3 月 15 日
密码重置漏洞、Hacker One 和谦卑
作者：马丁·埃姆德
你有没有把意大利面条扔到墙上？这很有趣、很粘，几乎不会引起恐慌。另一方面，HackerOne 报告则有相反的效果。与湿意大利面条不同，清理工作是我们安全团队要做的更多工作。
运行漏洞赏金计划意味着会收到一系列传入报告，并非所有报告都是正确的，都必须经过审核。在收到足够数量的听起来很糟糕但最终毫无结果的报告之后，它可能看起来像扔出的意大利面条（一种看看会发生什么的方法）。虽然我们尝试对每份报告进行彻底、公正的评估，但很难对任何给定的报告保持开放的心态。
死胡同报告浪费了 RubyGems 安全团队的时间，并减慢了我们解决更紧迫安全问题的速度。我曾经花了几天时间处理一个漏洞，结果是：在 BurpSuite 中单击该复选框会使这种方法失效。
但有时，黑客会找到一个非常真实的安全问题。这是一个关于我差点关闭的最新错误报告的故事，我假设这是另一个误报，以及我如何意识到自己错了。
检测到 MFA 旁路？
2023 年 12 月 22 日，我们收到了 RubyGems.org 密码重置表单上的多因素身份验证 (MFA) 旁路报告。该报告声称只使用通过电子邮件发送的密码重置令牌就可以重置受 MFA 保护的用户的密码，从而大大降低了 MFA 的价值。大多数报告往往声称具有相似的严重性级别，准确性各不相同。然而，那并不是报告中包含的屏幕截图在我看来确切的样子。
在屏幕录制中，报告者显示了以下内容
- 使用一个工具来存储对未受 MFA 控制的攻击者控制用户执行的有效密码重置的完整响应。
- 使用相同的工具对受害者（启用 MFA 的用户）的请求进行中间人 (MITM) 攻击。
- 在返回它之前，用保存的响应替换掉受害者的 MFA 挑战响应。
- 将页面中的每个
user_id替换为受害者的user_id（主要针对我知道无关紧要的地方，这增加了怀疑）。 - 允许 MITM 完成，向攻击者返回完整的密码编辑页面，但会交换受害者的用户 ID。
- 使用意在用于攻击者用户的表单，但使用受害者的用户 ID，将密码提交给受害者。
我困惑了，老实说，还有点恼火。该报告毫无道理，他针对该页面所做的更改似乎无关。从屏幕录制中，我不清楚提交的是哪个帐户或哪个用户的密码已更新。我没有看到登录或任何用户的用户资料。我认为交换响应主体只是发送回攻击者的会话 Cookie，因此照常登录攻击者用户并无视受害者。到处交换用户 ID 显得尤其愚蠢，并且进一步引起了我的怀疑。
此外，攻击者使用 MITM 来执行该漏洞。很少有应用程序对 MITM 免疫，攻击者可以未经加密地访问受害者的请求和响应（HTTPS 应该让这不可能发生）。
我有很多借口来解释为什么我无法立即看到该漏洞，以让我对我的怀疑感到释然，但总而言之，我是不屑一顾的。我多次“索要更多信息”来回应黑客。我指出为什么该方法似乎在利用 MITM 或发回用户的 Cookie 会授权该用户的原因。
调查
幸运的是，报告人对我的要求很响应，而我愿意被证明是错的。该报告于 12 月 22 日上午 5:30 提交，同一天晚上 7:30，我们已经来回沟通了几个小时。在第 3 次屏幕录制并在与 AWS 资助的驻场软件工程师 塞缪尔·吉丁斯 讨论后，我们终于得出了漏洞的证明。该报告发现了真正的问题。
该漏洞的运作方式如下：密码重置表单（我们的 Rails 应用程序中的 edit 操作）受到 MFA 和电子邮件令牌的良好保护。您无法在未验证您的 MFA 凭据的情况下呈现该表单。但是，表单上的提交操作（我们的 Rails 应用程序中的 update 操作）只检查电子邮件令牌，而不关心您是否先前提交了有效的 MFA。糟糕。黑客所做的所有看似毫无意义的更改都是为了呈现表单，以便可以在未通过 MFA 检查的情况下提交表单。
验证后，我打开了一个 GitHub 安全建议，该建议允许创建私有分叉。对于开源项目来说，这是避免在修补漏洞之前泄露漏洞的关键步骤。
在 埃里克·赫斯科维奇 和 约瑟夫·希马内克 的进一步帮助下，我们在 提交 0b3272a 中合并并部署了修复程序2024 年 1 月 7 日。该漏洞已发布并分配 CVE-2024-21654。我们没有理由相信该漏洞被利用过，因为它需要受损的电子邮件令牌。
思考
此报告为我提供了一次宝贵的教训。有效的安全研究可以来自完全不熟悉您的应用的黑客。
我最初认为是一个幼稚的误报，结果却是一个真正的安全问题。回想当初报告被验证时我是多么怀疑，这让我感到惭愧。我想要、甚至预期报告是复杂的，用先进的技术或明确的脚本漏洞打消我的疑虑。现实是，您不能根据自己的最初印象否决一份报告。
提交报告的黑客依靠手头的工具来解释问题。我期望 RubyGems.org 维护人员采取的方法，即对我们的代码有更全面的了解，对于这个记者来说是行不通的。在我看来，通过 MITM 手动编辑 copypasta 的迂回方法仍然是一种有效的利用 rubygems.org 的方式。
当漏洞报告谈到“一个老练的黑客”时，它可能只是被黑者的自尊心的一个掩护。正如我现在所经历的，一种明显“不老练”的攻击仍然可以复杂到足以绕过安全保护。
我希望这个故事能帮助您理解密码重置过程如何形成一种独特的攻击面，并且挑战您自己的什么才算是好的漏洞报告的认识。高质量的报告有时看起来像低投入的“面条投掷”。
我要感谢这位愿意透露姓名，但耐心地坚持不懈的漏洞报告者。
您现在可以采取什么措施支持 RubyGems.org 的安全性
在您浏览此处时，我鼓励您通过一次性密码立即在 RubyGems.org 上启用多重身份验证。更好的是，启用我们最近发布的密码密钥支持。如果没有一次性密码或密码密钥，您的帐户安全性只与您的电子邮件安全性相当。
我们邀请任何对安全性感兴趣的人挑战 RubyGems.org 以及 RubyGems/Bundler 库。请务必先阅读我们的政策！您可以在RubyGems Hacker One 计划中找到它。请不要中断 RubyGems.org 服务或干扰 RubyGems 用户。我们的漏洞赏金计划得到了互联网漏洞赏金的支持，这使我们能够奖励那些帮助让我们的服务对每个人都更安全的的黑客。
响应此类安全报告需要大量时间和资源。对于维护工程师在验证和修复类似漏洞上花费时间，每年会花费 Ruby Central 数千美元。我们慷慨的支持者和赞助商确保我们可以支持 RubyGems 生态系统的安全性并响应此类报告。如果您尚未为支持 RubyGems 而尽一份力，请考虑 通过少量捐款直接支持我们。如果您在工作中使用 Ruby，请向您的雇主了解赞助 Ruby Central 的机会。帮助我们确保 RubyGems 安全可靠。