GCP - Storage Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Storage

基本情報:

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 Escalation

storage.hmacKeys.create

Cloud Storageの「相互運用性」機能は、AWS S3などのクロスクラウドインタラクションのために設計されており、サービスアカウントとユーザーのHMACキーの作成を含みます。攻撃者は、権限のあるサービスアカウントのHMACキーを生成することによって、Cloud Storage内で権限を昇格させることができます。ユーザーに関連付けられたHMACキーはウェブコンソールを介してのみ取得可能ですが、アクセスキーとシークレットキーは永続的にアクセス可能であり、バックアップアクセスストレージの可能性を提供します。一方、サービスアカウントにリンクされたHMACキーはAPI経由でアクセス可能ですが、作成後はそのアクセスキーとシークレットキーは取得できず、継続的なアクセスのための複雑さを加えます。

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"exam-storage-sa-read-flag-3@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

この方法の別のエクスプロイトスクリプトはこちらで見つけることができます。

storage.objects.create, storage.objects.delete = ストレージ書き込み権限

バケット内に新しいオブジェクトを作成するにはstorage.objects.createが必要で、ドキュメントによると、既存のオブジェクトを変更するにはstorage.objects.deleteも必要です。

クラウドに書き込むことができるバケットの非常に一般的な悪用は、バケットがウェブサーバーファイルを保存している場合であり、ウェブアプリケーションで使用される新しいコードを保存できる可能性があります。

Composer

ComposerはGCP内で管理されているApache Airflowです。いくつかの興味深い機能があります：

• GKEクラスター内で実行されるため、クラスターが使用するSAはComposer内で実行されるコードからアクセス可能です。

• Composer環境のすべてのコンポーネント（DAGのコード、プラグイン、データ）はGCPバケット内に保存されます。攻撃者がそれに対して読み取りおよび書き込み権限を持っている場合、バケットを監視し、DAGが作成または更新されるたびに、バックドア付きのバージョンを提出することができるため、Composer環境はストレージからバックドア付きのバージョンを取得します。

この攻撃のPoCはリポジトリで見つけることができます： https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

• Cloud Functionsのコードはストレージに保存され、新しいバージョンが作成されると、コードがバケットにプッシュされ、その後新しいコンテナがこのコードからビルドされます。したがって、新しいバージョンがビルドされる前にコードを上書きすることで、クラウド関数が任意のコードを実行することが可能になります。

この攻撃のPoCはリポジトリで見つけることができます： https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngineのバージョンは、staging.<project-id>.appspot.comという形式のバケット内にデータを生成します。このバケット内には、AppEngineアプリのバージョンごとにフォルダを含むaeというフォルダが見つかります。これらのフォルダ内には、特定のバージョンを作成するために使用されるすべてのファイルを含むjsonが含まれるmanifest.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

GCR

• Google Container Registryはバケット内にイメージを保存します。これらのバケットに書き込むことができれば、後でそれらのバケットが実行されている場所に横移動できる可能性があります。

• GCRが使用するバケットは、gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.comのようなURLを持ちます（トップレベルのサブドメインはこちらで指定されています）。

このサービスは廃止されているため、この攻撃はもはや有効ではありません。さらに、このサービスの代わりとなるArtifact Registryは、バケットにイメージを保存しません。

参考文献

• https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！

• **💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。