GCP - IAM Privesc
IAM
IAM に関する詳細情報は以下で確認できます:
pageGCP - IAM, Principals & Org Policies Enumiam.roles.update
(iam.roles.get
)
iam.roles.update
(iam.roles.get
)上記の権限を持つ攻撃者は、あなたに割り当てられたロールを更新し、他のリソースに追加の権限を付与することができます。
以下は、特権エスカレーションの環境を自動化するスクリプトと、この特権を悪用するためのPythonスクリプトがあります。詳細については、元の研究をご覧ください。
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)上記の権限を持つ攻撃者は、サービスアカウントに属するアクセストークンをリクエストすることができます。そのため、自分よりも権限の高いサービスアカウントのアクセストークンをリクエストすることが可能です。
こちらに特権エスカレーションの環境を自動化するスクリプトがあり、この特権を悪用するためのPythonスクリプトはこちらです。詳細については、元の研究をご覧ください。
iam.serviceAccountKeys.create
iam.serviceAccountKeys.create
上記の権限を持つ攻撃者は、サービスアカウント用のユーザー管理キーを作成することができます。これにより、そのサービスアカウントとしてGCPにアクセスすることが可能となります。
こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。
iam.serviceAccountKeys.update
はSAのキーを変更するためにはiam.serviceAccountKeys.create
権限も必要です。
iam.serviceAccounts.implicitDelegation
iam.serviceAccounts.implicitDelegation
サードパーティのサービスアカウントに対して**iam.serviceAccounts.getAccessToken
権限を持つサービスアカウントでiam.serviceAccounts.implicitDelegation
権限を持っている場合、implicitDelegationを使用してそのサードパーティのサービスアカウントのためのトークンを作成**できます。説明を助けるための図は以下の通りです。
こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。
ドキュメントによると、委任はgenerateAccessToken()メソッドを使用してトークンを生成するためにのみ機能します。
iam.serviceAccounts.signBlob
iam.serviceAccounts.signBlob
上記の権限を持つ攻撃者は、GCP内で任意のペイロードに署名できます。そのため、対象となるSAの未署名JWTを作成し、それをブロブとして送信してSAに署名させることが可能です。詳細についてはこちらを参照してください。
こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらおよびこちらにあります。詳細については、オリジナルの研究を参照してください。
iam.serviceAccounts.signJwt
iam.serviceAccounts.signJwt
上記の権限を持つ攻撃者は、正しく形成されたJSON Web Token(JWT)に署名できます。前の方法との違いは、GoogleにJWTを含むブロブに署名させるのではなく、すでにJWTを期待するsignJWTメソッドを使用することです。これにより使用は簡単になりますが、JWTの署名のみが可能であり、任意のバイトを署名することはできません。
こちらに脆弱性環境の作成、悪用、クリーニングを自動化するスクリプトがあります。また、この特権を悪用するためのPythonスクリプトはこちらにあります。詳細については、オリジナルの研究を参照してください。
iam.serviceAccounts.setIamPolicy
iam.serviceAccounts.setIamPolicy
上記の権限を持つ攻撃者は、サービスアカウントにIAMポリシーを追加できます。これを悪用して、サービスアカウントを偽装するために必要な権限を自分に付与することができます。以下の例では、興味深いSAにroles/iam.serviceAccountTokenCreator
ロールを付与しています。
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs権限は、AWSのiam:PassRole権限のようなものです。Compute Engineインスタンスの起動などのタスクを実行するために不可欠であり、Service Accountを「actAs」する権限を付与することで、安全な権限管理が確保されます。これがないと、ユーザーが不当なアクセス権を取得する可能性があります。また、iam.serviceAccounts.actAsを悪用するには、各種の権限セットが必要な異なる方法があり、他の方法とは異なります。
サービスアカウントの偽装
サービスアカウントを偽装することは、新しいかつより良い権限を取得するのに非常に役立ちます。別のサービスアカウントを偽装する方法には、次の3つの方法があります:
RSAプライベートキーを使用した認証(上で説明済み)
Cloud IAMポリシーを使用した認可(ここで説明)
GCPサービス上でジョブを展開する(ユーザーアカウントの侵害によりより適用される)
iam.serviceAccounts.getOpenIdToken
iam.serviceAccounts.getOpenIdToken
上記の権限を持つ攻撃者は、OpenID JWTを生成することができます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の認可を必ずしも持っているわけではありません。
この興味深い投稿によると、JWTの受信者(トークンを使用して認証するサービス)を示す必要があり、Googleによって署名されたJWTがサービスアカウントとJWTの受信者を示します。
アクセス権を持っている場合、次のようにOpenIDTokenを生成できます:
その後、それを使用してサービスにアクセスできます:
いくつかのサービスは、この種のトークンを使用した認証をサポートしています:
Google Cloud Endpoints(Google OIDCを使用する場合)
サービスアカウントを代表してOpenIDトークンを作成する例はこちらにあります。
参考文献
最終更新