HackerOne供应链攻击实战：依赖混淆与Ruby Gem投毒案例剖析

无意中看到一位安全研究员在 HackerOne 平台上挖掘漏洞的思路，感觉非常巧妙，值得记录下来。说实话，如果没看过这个案例，我自己可能很少会从这个角度去思考问题。

这个漏洞的本质属于供应链攻击。过去可能觉得这类攻击主要出现在红蓝对抗的特定场景中，但实际上，在漏洞赏金项目的挖掘过程中，它同样是一个非常“靠谱”的切入点。

让我们先来看看原文作者（下文称“研究员”）的描述和思路。

Wait a minute... Technically Github Enterprise is ＂open source＂. And it probably hasn't been picked clean because that's a lesser known fact... Let's do it! So I followed the same methodology, scraped out the packages and sent them off to intruder to find...

Nothing. Just more 404s. As I was already about to give up, I had a thought: ＂Is dependency confusion a thing in Ruby?＂ After a bit of googling, I found an article telling me that it was! This felt super promising since it's a lesser known language + a lesser known code base. The more I can find myself in these lesser known places, the more successful I'll be. Let's do this for a third time!

For a third time, following the same methodology, I extracted a list of packages from the Gemfile and Gemfile.lock files that I could find. And after using Burp Intruder to send all, I found 126 hits for 404s! Now my blood is pumping and I need to operationalize, how can I get this done? I was roughly going to:

1. Develop a ruby gem payload that executes code and uses DNS exfiltration (an idea I stole from the previous article) to get my data out.
2. Configure my interactsh listener to receive wildcard DNS requests.
3. Write a script to decode the incoming payloads in order to extract the information from the domain name.
4. Write a script to take a list of ruby gems, generate a template based on the payload
5. Write a script to build all of the gems
6. Write a script to push all of the gems to rubygems.org
7. Sit back and wait for profit.

整体梳理下来，核心思路其实非常清晰。关键点在于“依赖解析顺序设计错误”。研究员采取的策略是，逐个检查目标代码仓库（repo）中引用的第三方包（package）在公共仓库（如 RubyGems.org）上是否处于“空位”状态（返回404状态码）。如果某个包名在公网上不存在，那么就存在“投毒”的可能，即攻击者可以抢先注册这个包名，并上传包含恶意代码的版本。

（这是一个重要的前提，但并非所有404都意味着漏洞存在。例如，如果目标仓库的包管理器配置了强制从私有镜像源拉取依赖，那么即使公网上有恶意包，也不会被加载。不过，这仍然是一个值得尝试的挖掘方向。）

看到这个案例的第一反应是：我们公司内部的代码仓库是否也存在类似问题？于是立刻写了个小脚本去验证了一下。结果还不错，依赖管理比较规范，没有发现太多混乱的依赖引用。这大概要归功于团队里其他安全同事和开发大佬们前期打下的良好基础。

坦白说，本文并没有涉及太多深奥的逆向工程或漏洞利用的技术细节，因为原研究员的记录也主要以文字描述为主。但好在整个攻击链条的思路非常直观易懂——最难的部分往往不是执行，而是“想到”这个切入点。这种在软件供应链上游寻找薄弱环节的安全测试方法，对于开阔渗透测试思路很有帮助。

如果你对这类涉及开源代码分析和依赖安全的攻防技术感兴趣，欢迎在 云栈社区 的安全板块与更多同行交流讨论。