Google DevSiteの脆弱性、リモートコード実行を許す恐れ

Googleの開発者向けサーバーで、攻撃者がサインインしなくてもコードを実行させられる状態になっていました。

セキュリティ研究者のSimon Köck氏は、GoogleのDevSiteプラットフォームに認証用シークレットが露出する脆弱性を発見しました。この脆弱性を悪用すると、攻撃者は信頼されたセッションを偽造できます。安全でないデータ処理と組み合わせれば、サーバー上でのリモートコード実行も可能でした。

Googleはすでにこの問題を修正し、発見の報奨としてKöck氏に9万ドルを支払いました。今回の事例は、二つのセキュリティ上の弱点が組み合わさることで、認証情報の露出がはるかに深刻な侵害につながり得ることを示しています。

検証に使う鍵をCookieが運んでいた

Köck氏はdevelopers.google.comのOAuthサインインのプロセスを調べていた際、約1,200バイトのFlaskセッションCookieに気づきました。訪問者はGoogleのサインインページへリダイレクトされる前に、このCookieを受け取っていました。

Köck氏によると、デコードしたCookieにはOAuthのクライアントIDとクライアントシークレットが含まれていました。DevSiteの実装では、この露出したシークレットでFlaskセッションCookieに署名することもできました。そのため攻撃者は、アプリケーションが有効と認める偽のCookieを作成できました。

これとは別の欠陥がOAuthコールバックにもありました。セッションに保存されたオブジェクトを復元するためにPythonのpickle.loads()を使っており、 安全でないデシリアライゼーションによって攻撃者が制御する命令を実行できてしまう処理でした。偽造したCookieを使えば、悪意ある命令をこの関数に送り込めたことになります。

研究者はOSコマンドを実行せずに脆弱性を検証するため、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氏に9万ドルを支払いました。DevSiteのエンジニアは、公開に先立つ10月7日に修正を完了しています。

Köck氏は、開示の準備をした時点でも、露出したOAuthクライアントシークレットは有効なままだったと報告しています。ただし、その値は公開していません。 

Googleは、同氏の説明にある修正内容を公には詳しく説明していません。そのため、修正がセッション処理の変更によるものか、安全でないデシリアライゼーションの除去によるものか、あるいは別の対策によるものかは分かりません。認証情報が有効だったと報告されていることは、元の攻撃が引き続き成立していたことを意味するものではありません。

セキュリティ担当者は自社のセッション処理を見直すべき

この脆弱性はGoogleのDevSiteの実装に固有のものですが、ほかのWebアプリケーションにも起こり得るセキュリティリスクを浮き彫りにしています。

開発者は、アプリケーションがセッションデータをどのように保存し、ブラウザから受け取った情報をどう処理しているかを見直す必要があります。署名付きCookieは不正な改変を防げますが、内容を暗号化するとは限らず、安全でないデシリアライゼーションを安全にするものでもありません。

セキュリティ担当者は、次の点を優先して確認すべきです。

• セッションCookieに認証情報が露出していないか点検する。アプリケーションがブラウザに公開している情報を確認し、埋め込まれたシークレットを取り除きます。こうした確認は、特にインターネットに公開するサービスについて、定期的な アプリケーションセキュリティレビューに組み込みます。
• 安全でないデータ処理を洗い出す。ユーザーが影響を与え得る情報からオブジェクトを復元するコード、とりわけpickle.loads()などの関数を調べます。リスクのあるデシリアライゼーションの経路は、検証済みのデータ形式やサーバー側のレコードに置き換えます。
• 共有している認証情報を見直す。署名鍵やその他のセキュリティ上重要な認証情報を使い回しているサイトを特定します。必要に応じて鍵を分離し、露出したシークレットのローテーションと影響を受けたセッションの無効化の手順を整えます。
• 公開エンドポイントをテストし、アプリケーションの権限を制限する。コードレビューに加えて、ログイン前に送られるリクエストも Webアプリケーションのセキュリティテストの対象にします。アプリケーションのプロセスに与える権限を絞り、機密性の高い業務情報や連携システムへのアクセスを抑えます。

DevSiteの事例は、単独では対処可能に見える弱点も、組み合わさるとはるかに危険になり得ることを示しています。開発者にとって認証の保護とは、ログイン処理だけでなく、セッション確立後にアプリケーションが信頼するデータを守ることでもあります。

関連するサイバーセキュリティニュース：SonicWallの顧客は、重大な脆弱性が開示から48時間以内に攻撃者に悪用され始めたため、パッチ適用の猶予がわずかしかありませんでした。