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

存储

Basic Information:

GCP - Storage Enum

storage.objects.get

此权限允许你 下载存储在 Cloud Storage 中的文件。这可能允许你提升权限，因为在某些情况下 敏感信息会保存在那里。此外，某些 GCP 服务会将它们的信息存储在 buckets 中：

  • GCP Composer: 当你创建 Composer Environment 时，所有 DAGs 的代码 会被保存在一个 bucket 中。这些任务的代码中可能包含有用的信息。
  • GCR (Container Registry): 容器的 image 存储在 buckets 中，这意味着如果你可以读取这些 buckets，就能下载镜像并 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

有关如何使用此权限修改权限的示例，请查看此页面：

# 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 这样的 跨云交互，涉及 为 Service Accounts 和 users 创建 HMAC keys。攻击者可以通过 为具有提权权限的 Service Account 生成 HMAC key 来利用这一点，从而 在 Cloud Storage 中提升权限。虽然与用户关联的 HMAC keys 只能通过 web console 检索，但其 access 和 secret keys 始终 可被访问，允许潜在的备份访问存储。相反，与 Service Account 关联的 HMAC keys 可通过 API 访问，但其 access 和 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

要在 bucket 内创建新对象，需要 storage.objects.create，并且根据 the docs，要修改已存在对象还需要 storage.objects.delete。

在可写的 bucket 中，一个非常常见的利用场景是当该 bucket 存放 web server 文件 时，你可能能够存储新的代码，该代码将被 web 应用使用。

Composer

Composer 是在 GCP 内托管的 Apache Airflow。它有几个值得注意的特性：

  • 它运行在 GKE cluster 内，因此在 Composer 内运行的代码可以访问集群所使用的 SA。
  • Composer 环境的所有组件（DAGs 的代码、插件和数据）都存储在 GCP 的 bucket 中。如果攻击者对其拥有读写权限，他可以监控该 bucket，并且每当有 DAG 被创建或更新时，提交一个带后门的版本，这样 Composer 环境就会从 Storage 获取到被植入后门的版本。

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

Cloud Functions

  • Cloud Functions 的代码存储在 Storage 中，每当创建新版本时，代码会被推送到 bucket，然后基于这些代码构建新的容器。因此，在新版本构建之前覆盖代码可以使 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 的 bucket 内生成一些数据。在这个 bucket 里，可以找到一个名为 ae 的文件夹，该文件夹会为 AppEngine 应用的每个版本包含一个子文件夹，在这些子文件夹内可以找到 manifest.json 文件。该文件包含一个 json，列出创建该特定版本所需的所有文件。此外，可以找到文件的真实名称、它们在 GCP bucket 内的 URL（bucket 内的文件名被改为它们的 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.

不过，如果对该 bucket 拥有读写权限，可以通过监控该 bucket 提权到附加在 App Engine 版本上的 SA：每当检测到变更（新版本）时，尽快修改新版本。这样，基于这些代码创建的容器就会执行带后门的代码。

上述攻击可以通过多种方式实现，所有方式都从监控 staging.<project-id>.appspot.com bucket 开始：

  • 将 AppEngine 新版本的完整代码上传到另一个可用的 bucket，并准备一个包含新 bucket 名称和文件 sha1 哈希的 manifest.json 文件。然后，当该 bucket 中创建新版本时，只需修改 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 将镜像存储在 buckets 中，如果你能写入这些 buckets，可能有机会横向移动到那些运行这些 buckets 的地方。
  • GCR 使用的 bucket 的 URL 类似于 gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com（顶级子域可参考 here）。

Tip

该服务已被弃用，因此此攻击不再有用。此外，Artifact Registry（替代该服务）并不将镜像存储在 buckets 中。

参考资料

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