Oracle、クラウドコードエディタの重大なバグを修正

出典：Tada Images / Shutterstock

クラウド統合は、ツールへの容易なアクセス、共有セッション、統一されたワークフローを約束します。しかし、Oracle Cloud Infrastructure（OCI）Code Editorで新たに発見された脆弱性が示すように、これらは重大なセキュリティギャップを密かに露呈させることもあります。

Tenableの研究者は、Code EditorがCloud Shellコマンドライン環境とどのように連携しているかを分析する中で、現在は修正済みの重大なリモートコード実行（RCE）の脆弱性を特定しました。

密接な統合

Code EditorはOCIの統合開発環境であり、開発者はブラウザから離れることなく、クラウド環境上で直接コードの作成、編集、管理ができます。これにより、ローカル開発ツールのダウンロード、インストール、設定が不要になります。Code Editorは、Resource ManagerやFunctions、Data Scienceなど他のOCI開発者サービスと統合されています。また、コマンドやスクリプトの実行にはCloud Shellを利用します。

Oracle Cloud Shell自体は、ブラウザベースのコマンドラインインターフェースで、Oracle Cloudリソースへの事前認証済みアクセスを提供します。Code EditorとCloud Shellは、OCI内で同じ基盤となるファイルシステムとユーザーセッションデータを共有しており、どちらの環境で編集・作成されたファイルも即座にもう一方からアクセス可能です。

Tenableは、これら密接に統合されたOCIサービスに潜む脆弱性や攻撃経路を探ることにしました。「Code Editorは研究者やユーザーからサンドボックス化された隔離空間とみなされがちですが、Resource ManagerやFunctions、Data Scienceとの深い連携はそれとは異なることを示唆しています」とTenableのセキュリティ研究者Liv Matanは今週のブログで述べています。「私たちの直感は単純でした。開発者が簡単にファイルをアップロードできるなら、攻撃者もできるのでは？」その答えは、すぐに「イエス」だと判明しました。

Tenableの研究者はまずCloud Shellとそのファイルアップロード機構に潜むセキュリティ問題を調査しましたが、問題を示唆するものは見つかりませんでした。そこで彼らはCode Editorに注目し、Cloud Shellと共有されているファイルアップロードエンドポイントに問題を発見しました。

具体的には、この脆弱性はCode Editor内でファイルのアップロードやダウンロードを処理するルーターに、クロスサイトリクエストフォージェリ（CSRF）チェックが欠如していたことに起因しています。

CSRFチェックは、悪意のあるウェブサイトがユーザーのブラウザを騙して、ログイン中の他のWebアプリやサイト上で操作を実行させるのを防ぐために不可欠です。Tenableは、このルーターが認証クッキーの扱いにおいて安全性がなく、CSRFリクエストに対する保護が全くなかったことを発見しました。つまり、ユーザーがOCIにログインしていれば、どんなウェブサイトからでもエンドポイントを呼び出してユーザーの代わりに操作ができてしまう状態でした。

開かれた扉

「本質的には、攻撃者は認証済みのOracle Cloud Infrastructureユーザーが自分の作成したウェブページを訪れると、そのユーザーのCloud Editorに気付かれずに悪意あるファイルをアップロードできてしまうのです」とMatanは述べています。「Code Editorは裏でCloud Shellのファイルシステムを使っているため、アップロードされたファイルは被害者のCloud Shellにアップロードされます。」

Tenableは、攻撃者が被害者のCloud Shellの乗っ取りに成功した場合、Resource ManagerやFunctions、Data Scienceなど他の密接に統合されたOCIサービスにもすぐに移動できることを発見しました。「つまり、Cloud Shellのファイルアップロードを狙った単純なCSRF攻撃が、すぐに多面的な脅威へと発展し、シェルだけでなく、その周囲の開発者ツール全体を危険にさらすのです」とMatanは指摘します。この脆弱性により、攻撃者は被害者のOCI上の権限を使って機密データへアクセスしたり、許可されていないリソースをデプロイしたり、統合されたOCIサービス間を横断的に移動することが可能になりました。必要なのは、ユーザーがOCIアカウントに認証された状態で悪意のあるウェブサイトを訪れることだけでした。

Oracleはその後、CSRF保護を強制することでこの脆弱性にパッチを適用しました。これにはカスタムトークンヘッダーの要求が含まれており、カスタムヘッダーのないリクエストは即座に拒否されるため、もはやこの脆弱性は悪用できなくなったとMatanは述べています。

この脆弱性は、クラウドプロバイダーがサービスを積み重ねて構築する中で、しばしば見落とされがちな、密接に統合されたジェンガのようなクラウド環境に潜むリスクを浮き彫りにしています。このような環境では、1つのサービスが侵害されると、その上に構築されたサービスも同じリスクや脆弱性を引き継ぐ可能性があります。「この気づきは、現代のクラウドセキュリティ研究における重要な教訓です。統合は単なる利便性ではなく、脆弱性の潜在的な入口にもなり得るのです」とMatanは述べています。