GCP - IAM Privesc
IAM
IAMに関する詳細情報は以下を参照してください:
GCP - 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
上記の権限を持つ攻撃者は、Service Accountのユーザー管理キーを作成することができ、これによりそのService AccountとしてGCPにアクセスすることが可能になります。
自動化スクリプトはこちらで見つけることができ、pythonスクリプトはこちらで見つけることができます。詳細についてはオリジナルの研究を確認してください。
iam.serviceAccountKeys.update
はSAのキーを変更するためには機能しないことに注意してください。なぜなら、そのためにはiam.serviceAccountKeys.create
の権限も必要だからです。
iam.serviceAccounts.implicitDelegation
iam.serviceAccounts.implicitDelegation
もし、あるService Accountに対して**iam.serviceAccounts.implicitDelegation
の権限を持っていて、そのService Accountが第三のService Accountに対してiam.serviceAccounts.getAccessToken
の権限を持っている場合、implicitDelegationを使用してその第三のService Accountのトークンを作成する**ことができます。以下の図はその説明を助けるためのものです。
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Frhinosecuritylabs.com%2Fwp-content%2Fuploads%2F2020%2F04%2Fimage2-500x493.png&width=768&dpr=4&quality=100&sign=eb0da8c5&sv=1)
ドキュメントによると、gcloud
の委任はgenerateAccessToken()メソッドを使用してトークンを生成する場合にのみ機能することに注意してください。ここではAPIを直接使用してトークンを取得する方法を示します:
自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのPythonスクリプトはこちらで見つけることができます。詳細についてはオリジナルの研究を参照してください。
iam.serviceAccounts.signBlob
iam.serviceAccounts.signBlob
上記の権限を持つ攻撃者は、GCPで任意のペイロードに署名することができます。したがって、SAの署名されていないJWTを作成し、それをblobとして送信してターゲットのSAに署名させることが可能です。詳細についてはこちらを参照してください。
自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのPythonスクリプトはこちらおよびこちらで見つけることができます。詳細についてはオリジナルの研究を参照してください。
iam.serviceAccounts.signJwt
iam.serviceAccounts.signJwt
上記の権限を持つ攻撃者は、正しく形成されたJSON Webトークン(JWT)に署名することができます。前の方法との違いは、JWTを含むblobに署名させる代わりに、すでにJWTを期待しているsignJWTメソッドを使用することです。これにより使用が簡単になりますが、任意のバイトではなくJWTにのみ署名できます。
自動化スクリプトはこちらで見つけることができ、この権限を悪用するためのPythonスクリプトはこちらで見つけることができます。詳細についてはオリジナルの研究を参照してください。
iam.serviceAccounts.setIamPolicy
iam.serviceAccounts.setIamPolicy
上記の権限を持つ攻撃者は、サービスアカウントにIAMポリシーを追加することができます。これを悪用して、必要な権限を自分に付与し、サービスアカウントを偽装することができます。以下の例では、興味のあるSAに対してroles/iam.serviceAccountTokenCreator
ロールを自分に付与しています:
自動化スクリプトはこちらで見つけることができます。
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs permissionはAWSのiam:PassRole permissionに似ています。これは、Compute Engineインスタンスの起動などのタスクを実行するために不可欠であり、Service Accountとして「actAs」する能力を付与し、安全な権限管理を確保します。これがないと、ユーザーが不適切なアクセスを得る可能性があります。さらに、iam.serviceAccounts.actAsの悪用にはさまざまな方法があり、それぞれに一連の権限が必要であり、他の方法とは対照的に1つの権限だけでは済みません。
Service account impersonation
Service accountを偽装することは、新しいより良い権限を取得するために非常に有用です。以下の3つの方法で他のService accountを偽装することができます:
RSA private keysを使用した認証(上記でカバー)
Cloud IAM policiesを使用した認可(ここでカバー)
GCPサービスにジョブをデプロイ(ユーザーアカウントの侵害により適用)
iam.serviceAccounts.getOpenIdToken
iam.serviceAccounts.getOpenIdToken
上記の権限を持つ攻撃者は、OpenID JWTを生成することができます。これらはアイデンティティを主張するために使用され、必ずしもリソースに対する暗黙の認可を持つわけではありません。
この興味深い投稿によると、オーディエンス(トークンを使用して認証したいサービス)を指定する必要があり、Googleによって署名されたJWTが返され、そのJWTのService accountとオーディエンスが示されます。
OpenIDTokenを生成するには(アクセス権がある場合):
次に、それを使用してサービスにアクセスできます:
いくつかのサービスは、この種のトークンを介した認証をサポートしています:
Google Cloud Endpoints (Google OIDCを使用している場合)
サービスアカウントの代わりにOpenIDトークンを作成する方法の例はこちらで見つけることができます。
参考文献
Last updated