委任しすぎるDeleFriend

身の回りには様々なシステムがあります。
古き良き時代、各種アプリケーションはそのそれぞれが単体で便利で多くの人がアプリケーションを単体で使うというものだったように思います。
時間の経過とともにパラダイムシフトが起こり、アプリケーションはどんどん分割され、部品化が進んできました。

利用者の操作している画面の見え方は、従来と大きく変わっていないような場合でも、その裏側の機構は細分化された部品で構成されているようなことになっています。
HTTPS処理だけを実行する部品、HTTPでの入出力だけを処理する部品、認証だけを処理する部品、データ保持だけを実行する部品、計算だけを実行する部品、などといった具合です。
そして、これらの機能は、なんらかのAPIで接続されます。
APIはApplication Programming Interfaceで、ソフトウェアコンポーネント同士が互いに情報をやりとりするのに使用するインタフェースの仕様です。
サブルーチン、データ構造、オブジェクトクラス、変数などを分割して構成することができるようになります。
APIの動作においても、その実行時の権限は重要です。
誤った権限で動作することは、たとえば、見えるべきではない人の情報を見ることができるようになってしまうなどの問題へと繋がります。

権限の処理をうまく処理する機構の一つに、委任というものがあります。
たとえば、Google社はGoogleのドメイン全体の委任ということが実行できる機能を提供しています。
この機能により、Google Cloud Platform (GCP) ID オブジェクトと Google Workspace (GWS)アプリケーション間の包括的な委任が可能になります。
言い方を変えると、GCP IDは、他のWorkspaceユーザーに代わって、Gmail、Googleカレンダー、GoogleドライブなどのGoogle SaaSアプリケーション上でタスクを実行できるようになります。

こういった機構を有効に活用できると、利用者にとって利便性の高いアプリケーションを構成することができます。
しかしこの便利さは、そこで使用される要素のすべてが必要十分に安全であることが前提となっています。

Google Workspaceドメイン全体の権限の委任において、設計上の欠陥と考えられる問題が確認されています。
ドメイン委任設定がサービスアカウントIDオブジェクトに関連付けられた特定の秘密キーではなく、サービスアカウントリソース識別子(OAuth ID)によって決定されるという設計上の点がポイントとなっています。
この仕様を悪用すると、こんなことが可能となってしまいます。

既存のドメイン全体の委任権限を持つGCPサービスアカウントリソースへの新しい秘密鍵を作成するためのアクセス権を持つIAM IDを利用して新しい秘密鍵を作成し、それを使用してAPI呼び出しを実行できます。
ターゲットのGCPプロジェクトへの権限の低いアクセス権しか持たないアカウントが、アクセスできないはずのサービスを利用できてしまうということになります。
もっと平易に例えると、誰かが勝手にあなたのGmail、ドライブ、カレンダーなどのGoogleサービスから機密データを抜き取る可能性があるという話です。

この問題の存在を概念実証するコードも作成されています。
そしてGitHubで公開されています。

日々、アプリケーションやOSの脆弱性対策を実施することは重要です。
しかし、そういったことにとどまらず、身の回りに存在する様々な設定が、機能面ということではなく、安全面で考えた時に妥当に設定されているのかといった、設定内容の安全性についても意識する必要があるということに思えます。

参考記事（外部リンク）：DeleFriend: Severe design flaw in Domain Wide Delegation
could leave Google Workspace vulnerable for takeover
www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover