Googleの開発者向けサーバーでは、攻撃者がログインしなくてもコードを実行させられる状態になっていた。
セキュリティ研究者のSimon Köck氏は、GoogleのDevSiteプラットフォームに、認証用シークレットを露出させ、攻撃者による信頼済みセッションの偽造を可能にする脆弱性を発見した。この欠陥は安全でないデータ処理と組み合わさることで、サーバー上でのリモートコード実行を可能にしていた。
Googleはその後この問題を修正し、発見の報奨金としてKöck氏に$90,000を支払った。この事例は、2つのセキュリティ上の弱点が組み合わさると、露出した認証情報がはるかに深刻な侵害につながり得ることを示している。
検証に使われる鍵をCookieが保持していた
developers.google.comのOAuthサインインプロセスを調べていたKöck氏は、約1,200バイトのFlaskセッションCookieに気づいた。訪問者には、Googleのサインインページへリダイレクトされる前にこのCookieが渡されていた。
Köck氏によると、復号したCookieにはOAuthクライアントIDとクライアントシークレットが含まれていた。DevSiteの実装では、露出したシークレットをFlaskセッションCookieへの署名にも使えたため、攻撃者はアプリケーションが有効なものとして受け入れるCookieを作成できた。
OAuthコールバックには別の欠陥も存在した。セッションに保存されたオブジェクトの再構築にPythonのpickle.loads()を使っており、攻撃者が制御する命令を実行できる 危険なデシリアライズを通じた処理だった。そのため、偽造Cookieに悪意のある命令を関数へ送り込むことができた。
研究者は、オペレーティングシステムのコマンドを実行せずに脆弱性を検証するため、time.sleep()のペイロードを用意した。サーバーの応答は約3秒、5秒、8秒遅延し、要求した時間と一致した。署名を改変したCookieは拒否されたため、サーバーがテスト用の関数を実行したという同氏の発見を裏付ける結果となった。
他の4つの開発者向けサイトでも偽造セッションを受け入れた
さらにテストしたところ、復元した鍵は4つの追加プロパティでも機能した。firebase.google.com、developer.android.com、source.android.com、docs.partner.android.comでは有効なセッションが受け入れられた。Köck氏は、各ホストについて個別にコード実行テストを行ったことは記録していない。
Googleはこの脆弱性をS0のリモートコード実行問題に分類し、Köck氏に$90,000を支払った。DevSiteのエンジニアは、一般公開に先立つ10月7日に修正を完了した。
Köck氏は、情報開示の準備を進めた時点でも、露出したOAuthクライアントシークレットは有効なままだったと報告した。ただし、その値は明らかにしていない。
Googleは、同氏の報告で説明された修正措置の詳細を公表していない。そのため、セッション処理の変更、安全でないデシリアライズの削除、その他の対策のいずれが修正に含まれていたのかは不明だ。報告された認証情報の状態だけでは、元の攻撃が引き続き悪用可能だったとは断定できない。
セキュリティチームは自社のセッション処理を見直すべきだ
この脆弱性はGoogleのDevSite実装に固有のものだったが、他のWebアプリケーションにも及び得るセキュリティリスクを浮き彫りにしている。
開発者は、アプリケーションがセッションデータをどのように保存し、ブラウザーから受け取った情報をどのように処理するかを見直すべきだ。署名付きCookieは不正な改変を防げるが、内容を暗号化したり、安全でないデシリアライズを安全にしたりするとは限らない。
セキュリティチームは、次の項目を優先的に確認すべきだ。
- セッションCookieに露出した認証情報がないか確認する。アプリケーションがブラウザーからアクセス可能にしている情報を確認し、埋め込まれたシークレットを削除する。これらの確認を定期的な アプリケーションセキュリティレビューに組み込み、特にインターネットに公開されているサービスを対象にする。
- 安全でないデータ処理を見つける。ユーザーが影響を与えられる情報からオブジェクトを再構築するコード、特にpickle.loads()などの関数を調べる。リスクの高いデシリアライズ経路は、検証済みのデータ形式またはサーバー側のレコードに置き換える。
- 共有された認証情報を見直す。署名鍵やその他のセキュリティ上重要な認証情報を使い回しているWebサイトを特定する。適切な場合は鍵を分離し、露出したシークレットをローテーションして影響を受けたセッションを無効化する手順を確立する。
- 露出したエンドポイントをテストし、アプリケーションの権限を制限する。ログイン前に行われるリクエストを Webアプリケーションセキュリティテストに含め、コードレビューと併せて実施する。アプリケーションプロセスに付与する権限を制限し、機密性の高い業務情報や接続先システムへのアクセス可能性を減らす。
DevSiteの事例は、単独では対処可能に見える弱点も、組み合わさるとはるかに危険になり得ることを示している。開発者にとって認証の安全確保とは、ログイン処理だけでなく、セッション確立後にアプリケーションが信頼するデータも保護することを意味する。
サイバーセキュリティーの最新ニュース：SonicWallの顧客は、攻撃者が重大な脆弱性の悪用を開始した後、開示から48時間以内という、パッチ適用の猶予が短い状況に直面した。