「なんちゃってRails2Shell」がRubyサーバーを直撃

Ruby on Railsに存在する重大な脆弱性が、理論上の脅威から実際の攻撃手段へと急速に姿を変えました。VulnCheckは先日、CVE-2026-66066の悪用が実際に行われていることを検知しました。サイバーセキュリティ業界では、この深刻な欠陥を通称「KindaRails2Shell」と呼んでいます。攻撃者はシンガポール、イスラエル、英国に戦略的に設置されたハニーポットを狙いました。興味深いことに、この悪意ある活動はすべてフランスにある単一のIPアドレスから発信されていました。侵害に成功した後、攻撃者はイスラエルに設置されたコマンドサーバーとの通信を確立しています。

Active Storageの脆弱性

この危険な問題はActive Storageに直接影響を及ぼします。Active StorageはRuby on Railsに組み込まれたファイルアップロード処理用の仕組みです。脆弱性の影響を受けるアプリケーションは、画像処理全般に「libvips」ライブラリを利用しています。これにより、信頼できないユーザーでも自由にさまざまな画像をアップロードできてしまいます。特に重要な点として、Rails 7以降ではこの構成でlibvipsがデフォルトで動作します。この深刻な欠陥にはCVSSスコア9.5(10点満点)という危険な評価が付けられました。その結果、攻撃者は認証済みアカウントを一切必要とせずに、サーバーを完全に乗っ取ることが可能になります。

ファイルタイプの不整合を突く攻撃手法

KindaRails2Shellの核心的な仕組みは、システムを構成する各コンポーネントがファイルタイプの定義について一貫性を欠いている点を悪用するところにあります。直接アップロードの際、Railsはクライアントが明示的に宣言したコンテンツタイプをそのまま受け入れてしまうことがあります。しかしlibvipsは後になって、ファイルの実際の署名を独自に評価します。特別に細工されたオブジェクトは複数のフォーマットハンドラーを渡り歩きます。最終的に、HDF5ライブラリがサーバー上の外部ファイルにアクセスしてしまいます。その結果として、システムは攻撃者が選んだファイルの中身を画像のピクセルデータへと変換してしまいます。そして、この汚染されたピクセルデータをそのまま外部に返してしまうのです。サードパーティ製の実証コード(PoC)が出回り始めたのを受け、Railsの開発チームはこの攻撃チェーンを詳細に解説する資料を公開しました。

真の脅威:アプリケーションの機密情報の窃取

この脆弱性の本当の危険性は、単に個別のファイルを読み取られることだけにとどまらず、アプリケーションの重要な機密情報が露出してしまう点にあります。攻撃者は環境変数や設定ファイルを悪用し、「secret_key_base」を抜き出すことができます。さらに、Railsのマスターキー、データベースのパスワード、クラウドストレージのキー、重要なサードパーティサービスのトークンまで盗み取ることも可能です。「secret_key_base」を奪われることは、致命的な事態を意味します。この秘密鍵があれば、攻撃者はRailsがアプリケーション自身によって正式に署名されたものとして信頼するデータを、自在に偽造できてしまうからです。最終的に、この一連の攻撃チェーンは安全でないMarshalデシリアライゼーションを容易に引き起こし、これが必然的に壊滅的なリモートコード実行へとつながります。

発見の経緯と重要なパッチ

EthiackおよびGMO Flatt Securityの研究者RyotaK氏が、それぞれ独立にこの脆弱性を発見しました。Railsの開発チームは7月29日、重要なパッチを公開しています。この重要な更新は、Active Storageのバージョン7.2.3.2、8.0.5.1、8.1.3.1にそれぞれ対応するものです。さらに、安全な運用のためにはlibvipsバージョン8.13以降を利用することが必須となります。古いビルドには、信頼できないファイルに関連する危険な操作をブロックするために不可欠な機能が、そもそも備わっていません。

実攻撃への急速なエスカレーション

初期の研究段階から実際の攻撃へと移行する速さは、ある意味で予想通りのものでした。8月上旬までに、VulnCheckはすでに実働する攻撃コードを準備していました。その後、インターネットからアクセス可能な脆弱なRailsインスタンスが7,100件以上存在することを特定しています。同社は攻撃コードとあわせて、Sigma、Suricata、Snort、YARA向けの包括的な検知ルールも作成しました。さらに、明白な悪用の試みを検知するために特化したネットワークダンプも提供しています。それから数週間のうちに、VulnCheckのハニーポットは実際の悪意あるトラフィックの捕捉を開始しました。

重要な対応手順

パッチ適用前にサーバーが攻撃を受けやすい状態にあった場合、単にRailsを更新するだけでは不十分です。開発者たちは、管理者に対して、アクセスされた可能性のあるすべての機密情報を根本的に漏洩済みとみなすよう強く推奨しています。管理者は「secret_key_base」、マスターキー、データベースの認証情報、各種クラウドストレージのキー、そしてすべての外部サービストークンを至急交換する必要があります。さらに、「secret_key_base」を変更すると、既存のすべてのユーザーセッションが強制的に終了します。この重要な操作により、これまでに署名済みのデータはすべて即座に無効化されます。

すでに更新を済ませたシステムの検証を支援するため、Railsチームは専用の診断ツールを公開しました。これらのツールは、脆弱性にさらされていた期間を正確に特定するのに役立ちます。また、Active Storageやオブジェクトストレージ環境内に残るKindaRails2Shellの痕跡を検索する機能も備えています。この攻撃は極めて特異な痕跡を残します。処理された画像バリアントには、盗み出されたサーバー上のバイトデータがピクセルデータの中に文字通り埋め込まれている可能性があるのです。したがって、管理者は最新リリースがインストールされていることを確認する必要があります。あわせて、KindaRails2Shellが最初に公表されてから実際の悪用が初めて確認されるまでの、恐るべき1か月間の空白期間に攻撃者による侵害が成功していなかったかどうかも、必ず確認しなければなりません。

翻訳元: https://meterpreter.org/kindarails2shell-vulnerability-active-attacks/

本記事は meterpreter.org の記事を翻訳・要約したものです。