Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
基本情報:
GCP - Storage Enum
storage.objects.getこの権限は、Cloud Storage内に保存されたファイルをダウンロードすることを許可します。これは、場合によっては機密情報がそこに保存されているため、権限を昇格させる可能性があります。さらに、いくつかのGCPサービスは、バケットに情報を保存します:
GCP Composer: Composer環境を作成すると、すべてのDAGのコードがバケット内に保存されます。これらのタスクは、そのコード内に興味深い情報を含む可能性があります。
GCR (Container Registry): コンテナのイメージはバケット内に保存されており、バケットを読み取ることができれば、イメージをダウンロードして漏洩やソースコードを検索することができます。
storage.objects.setIamPolicyこの権限を使用して、このセクションの前のシナリオのいずれかを悪用することができます。
storage.buckets.setIamPolicyこの権限で権限を変更する方法の例については、このページを確認してください:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.createCloud Storageの「相互運用性」機能は、AWS S3などのクロスクラウドインタラクションのために設計されており、サービスアカウントとユーザーのHMACキーの作成を含みます。攻撃者は、権限のあるサービスアカウントのHMACキーを生成することによってこれを悪用し、Cloud Storage内で権限を昇格させることができます。ユーザーに関連付けられたHMACキーはウェブコンソールを介してのみ取得可能ですが、アクセスキーとシークレットキーは永続的にアクセス可能であり、バックアップアクセスストレージの可能性を提供します。一方、サービスアカウントにリンクされたHMACキーはAPIアクセス可能ですが、作成後はそのアクセスキーとシークレットキーは取得できず、継続的なアクセスのための複雑さを加えます。
この方法の別のエクスプロイトスクリプトはこちらで見つけることができます。
storage.objects.create, storage.objects.delete = ストレージ書き込み権限バケット内に新しいオブジェクトを作成するにはstorage.objects.createが必要で、ドキュメントによると、既存のオブジェクトを変更するにはstorage.objects.deleteも必要です。
クラウドに書き込むことができるバケットの一般的な悪用は、バケットがウェブサーバーファイルを保存している場合であり、ウェブアプリケーションで使用される新しいコードを保存できる可能性があります。
ComposerはGCP内で管理されているApache Airflowです。いくつかの興味深い機能があります：
GKEクラスター内で実行されるため、クラスターが使用するSAはComposer内で実行されるコードからアクセス可能です。
Composer環境のすべてのコンポーネント（DAGのコード、プラグイン、データ）はGCPバケット内に保存されます。攻撃者がそれに対して読み取りおよび書き込み権限を持っている場合、バケットを監視し、DAGが作成または更新されるたびに、バックドア付きのバージョンを提出することができるため、Composer環境はストレージからバックドア付きのバージョンを取得します。
この攻撃のPoCはリポジトリで見つけることができます： https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Cloud Functionsのコードはストレージに保存され、新しいバージョンが作成されると、コードがバケットにプッシュされ、その後新しいコンテナがこのコードからビルドされます。したがって、新しいバージョンがビルドされる前にコードを上書きすることで、クラウド関数が任意のコードを実行することが可能になります。
この攻撃のPoCはリポジトリで見つけることができます： https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
AppEngineのバージョンは、staging.<project-id>.appspot.comという形式のバケット内にデータを生成します。このバケット内には、AppEngineアプリのバージョンごとにフォルダを含むaeというフォルダがあり、これらのフォルダ内にはmanifest.jsonファイルが見つかります。このファイルには、特定のバージョンを作成するために使用されるすべてのファイルを含むjsonが含まれています。さらに、ファイルの実際の名前、GCPバケット内のURL（バケット内のファイルはそのsha1ハッシュのために名前が変更されています）、および各ファイルのsha1ハッシュを見つけることができます。
このバケットを事前に取得することはできません。なぜなら、GCPユーザーはappspot.comというドメイン名を使用してバケットを生成する権限がないからです。
しかし、このバケットに対して読み取りおよび書き込みアクセスがあれば、バケットを監視し、変更が行われるたびに（新しいバージョン）、新しいバージョンをできるだけ早く変更することで、App Engineバージョンに付随するSAの権限を昇格させることが可能です。このようにして、このコードから作成されるコンテナはバックドア付きのコードを実行します。
前述の攻撃はさまざまな方法で実行できますが、すべてはstaging.<project-id>.appspot.comバケットを監視することから始まります：
AppEngineバージョンの完全な新しいコードを別の利用可能なバケットにアップロードし、新しいバケット名とsha1ハッシュを持つmanifest.jsonファイルを準備します。その後、バケット内で新しいバージョンが作成されると、manifest.jsonファイルを変更して悪意のあるものをアップロードするだけです。
悪意のある依存関係のコードを使用するrequirements.txtの修正バージョンをアップロードし、manifest.jsonファイルを新しいファイル名、URL、およびそのハッシュで更新します。
悪意のあるコードを実行するmain.pyまたはapp.yamlファイルを修正してアップロードし、manifest.jsonファイルを新しいファイル名、URL、およびそのハッシュで更新します。
この攻撃のPoCはリポジトリで見つけることができます： https://github.com/carlospolop/Monitor-Backdoor-AppEngine
Google Container Registryはバケット内にイメージを保存します。これらのバケットに書き込むことができれば、これらのバケットが実行されている場所に横移動できる可能性があります。
GCRが使用するバケットは、gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.comのようなURLを持ちます（トップレベルのサブドメインはこちらで指定されています）。
このサービスは廃止されているため、この攻撃はもはや有効ではありません。さらに、このサービスの代わりとなるArtifact Registryは、バケットにイメージを保存しません。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
