GCP - IAM Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
IAMに関する詳細情報は以下を参照してください:
GCP - IAM, Principals & Org Policies Enumiam.roles.update (iam.roles.get)上記の権限を持つ攻撃者は、あなたに割り当てられたロールを更新し、他のリソースに対して追加の権限を付与することができます:
You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)An attacker with the mentioned permissions will be able to request an access token that belongs to a Service Account, so it's possible to request an access token of a Service Account with more privileges than ours.
攻撃者は、前述の権限を持っていると、サービスアカウントに属するアクセストークンを要求することができるため、私たちよりも多くの権限を持つサービスアカウントのアクセストークンを要求することが可能です。
あなたは、脆弱な環境の作成、悪用、クリーンアップを自動化するスクリプトをここで見つけることができます およびこの特権を悪用するためのPythonスクリプトをここで見つけることができます。詳細については、元の研究を確認してください。
iam.serviceAccountKeys.create言及された権限を持つ攻撃者は、サービスアカウントのユーザー管理キーを作成することができ、これによりそのサービスアカウントとしてGCPにアクセスできるようになります。
ここで、脆弱な環境の作成、悪用、クリーンアップを自動化するスクリプトと、この特権を悪用するためのPythonスクリプトをこちらで見つけることができます。詳細については、元の研究を確認してください。
iam.serviceAccountKeys.updateはSAのキーを変更するためには機能しないことに注意してください。なぜなら、それを行うにはiam.serviceAccountKeys.createの権限も必要だからです。
iam.serviceAccounts.implicitDelegationもし、iam.serviceAccounts.implicitDelegationの権限を持つサービスアカウントが、第三のサービスアカウントに対してiam.serviceAccounts.getAccessTokenの権限を持っている場合、implicitDelegationを使用してその第三のサービスアカウントのトークンを作成することができます。説明を助けるための図は以下の通りです。
ドキュメントによると、gcloudの委任はgenerateAccessToken()メソッドを使用してトークンを生成するためにのみ機能することに注意してください。したがって、APIを直接使用してトークンを取得する方法は以下の通りです：
You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら. For more information check the 元の研究.
iam.serviceAccounts.signBlobAn attacker with the mentioned permissions will be able to GCP内の任意のペイロードに署名する. So it'll be possible to SAの署名されていないJWTを作成し、それをブロブとして送信してターゲットにしているSAによってJWTに署名させる. For more information これを読む.
You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら and こちら. For more information check the 元の研究.
iam.serviceAccounts.signJwtAn attacker with the mentioned permissions will be able to 適切に形成されたJSONウェブトークン（JWT）に署名する. The difference with the previous method is that JWTを含むブロブに署名するためにGoogleに署名させるのではなく、すでにJWTを期待しているsignJWTメソッドを使用します. This makes it easier to use but you can only sign JWT instead of any bytes.
You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはこちら and a python script to abuse this privilege こちら. For more information check the 元の研究.
iam.serviceAccounts.setIamPolicyAn attacker with the mentioned permissions will be able to サービスアカウントにIAMポリシーを追加する. You can abuse it to 自分に必要な権限を付与してサービスアカウントを偽装する. In the following example we are granting ourselves the roles/iam.serviceAccountTokenCreator role over the interesting SA:
You can find a script to automate the 作成、悪用、脆弱な環境のクリーンアップはここにあります.
iam.serviceAccounts.actAsiam.serviceAccounts.actAs権限は、AWSのiam:PassRole権限のようなものです。これは、Compute Engineインスタンスを起動するなどのタスクを実行するために不可欠であり、サービスアカウントとして「行動する」能力を付与し、安全な権限管理を確保します。これがなければ、ユーザーは不当なアクセスを得る可能性があります。さらに、iam.serviceAccounts.actAsを悪用するには、さまざまな方法があり、それぞれに一連の権限が必要であり、他の方法は1つの権限だけで済むのとは対照的です。
サービスアカウントになりすますことは、新しいより良い権限を取得するために非常に便利です。他のサービスアカウントをなりすます方法は3つあります:
RSA秘密鍵を使用した認証（上記で説明）
Cloud IAMポリシーを使用した認可（ここで説明）
GCPサービスでのジョブのデプロイ（ユーザーアカウントの侵害により適用される）
iam.serviceAccounts.getOpenIdToken前述の権限を持つ攻撃者は、OpenID JWTを生成することができます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の認可を必ずしも持っているわけではありません。
この興味深い投稿によると、トークンを認証に使用するサービス（オーディエンス）を示す必要があり、サービスアカウントとJWTのオーディエンスを示すgoogleによって署名されたJWTを受け取ります。
アクセスがあれば、OpenIDTokenを生成できます:
その後、次のようにしてサービスにアクセスできます：
いくつかのサービスは、この種のトークンを介して認証をサポートしています：
Google Cloud Endpoints (Google OIDCを使用している場合)
サービスアカウントの代わりにOpenIDトークンを作成する方法の例はこちらで見つけることができます。
AWSハッキングを学び、練習する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する：HackTricks Training GCP Red Team Expert (GRTE)
