Googleは、developers.google.comやその他のドキュメントサイトを支える共通プラットフォームであるDevSiteで、文書化されていないリモートコード実行脆弱性を発見したセキュリティ研究者Simon Köckに、9万ドルの報奨金を支払った。Köckは8月6日に問題を報告し、Googleは翌日に報告を受理、8月27日に報奨金に同意したが、修正がサーバーに適用されたのは10月7日だった。
Googleはこの脆弱性を、深刻度評価で最高レベルのS0に分類した。Köckには、通常のアプリケーション層におけるRCE脆弱性に対する基本報奨金7万5,000ドルに加え、報告の質が例外的だったことによる20%の増額が支払われた。
3つのミスがエクスプロイトチェーンを形成
DevSiteは、廃止されたoauth2clientライブラリのシリアライズ済みOAuth2WebServerFlowオブジェクトを、FlaskセッションCookie内に保存していた。これによりOAuthクライアントシークレットが露出したが、さらに深刻だったのは、同じシークレットがFlaskセッションの署名鍵としても使われていたことだ。
KöckはCookieの署名をローカルで再現し、サーバーが受け入れる偽造セッションを作成できた。OAuthフローではセッションデータのデシリアライズにpickleを使用していたため、署名済みの悪意あるpickleペイロードでオブジェクトを置き換え、リモートからのPythonコード実行を実証できた。
研究者は、sleepコマンドによって応答を遅延させるペイロードを使って実行を確認した。このペイロードは、実際のコマンドの実行やファイル、認証情報、内部サービスへのアクセスを意図的に行う前に停止するものだった。本人の説明によると、影響を受けた7つのドメインすべてで偽造セッションが受け入れられた一方、概念実証テストはdevelopers.google.com、docs.partner.android.com、web.devの3ドメインで実施された。
影響範囲は完全には確定していない
Köckは、サーバーがGoogleのドキュメントコンテンツを変更したり、インストールコマンドやダウンロードリンクを置き換えたりできるかどうかを実証していない。これは、ソフトウェアサプライチェーン攻撃につながる可能性のあるシナリオだった。また、偽造セッションによってユーザーになりすましたり、そのデータにアクセスしたりできるかどうかもテストしていない。
@brutecatとして知られる研究者Arvin Shivramは、内部のApp Engineアプリケーションが通常、サービス間通信のためのGoogle内部システムであるStubbyにアクセスできる可能性があると指摘した。Köckは、このプロセスにそのアクセス権があった場合、影響は大幅に拡大し得ると述べたが、DevSiteの権限やバックエンドサービスへのアクセス範囲については検証していない。
なぜこのニュースが重要なのか
この事例は、リスクが単一のミスから生じたのではなく、3つの慣行が重なった結果だったことを示している。すなわち、機密性の高いシークレットをCookie内に露出させたこと、それを署名鍵として再利用したこと、そして信頼できないデータに対して安全でないデシリアライゼーションを使用したことだ。この連鎖のどれか1つを修正するだけでもエクスプロイト経路を断てたため、シークレットの分離とセッションデータでのpickleの拒否は、任意の改善ではなく基本的な対策となる。
一方、修正までにおよそ2か月を要したことは、Googleが回答していない運用上の疑問を提起している。同社は、暫定的な緩和策を適用したか、Köckによれば7つのドメインが使用していた異なる2つの署名鍵をローテーションしたか、既存のセッションを無効化したかを明らかにしていない。また、修正公開前に脆弱性が悪用された可能性について、フォレンジック調査の結果も公表していない。記事の更新時点で、The New Stackからのコメント要請にも回答していなかった。
ニュースの出典
The New Stack - Software Development
原文を開く ↗