GCP - Containers, GKE & Composer Enum
コンテナ
GCPのコンテナでは、GCPが提供するほとんどのコンテナベースのサービスを見つけることができます。ここでは、最も一般的なサービスの列挙方法を見ることができます:
Privesc
以下のページでは、コンテナの権限を悪用して権限を昇格する方法について確認できます:
pageGCP - Container PrivescNode Pools
これらは、kubernetesクラスタを形成するマシン(ノード)のプールです。
Composer
これは Airflow のGCP管理バージョンです。
権限昇格
以下のページでは、Composerの権限を悪用して権限を昇格させる方法について確認できます:
pageGCP - Composer PrivescKubernetes
Kubernetesについての情報は、このページを確認してください:
pageKubernetes Pentestingまず、プロジェクトにKubernetesクラスターが存在するかどうかを確認できます。
クラスターをお持ちの場合、gcloud
を使用して ~/.kube/config
ファイルを自動的に設定できます。このファイルは、K8s クラスターと対話するためのネイティブ CLI である kubectl を使用する際に認証するために使用されます。このコマンドを試してみてください。
その後、生成された認証情報を確認するために ~/.kube/config
ファイルを見てください。このファイルは、アクティブな gcloud
セッションが使用している同じアイデンティティに基づいてアクセストークンを自動的に更新するために使用されます。もちろん、これには適切な権限が必要です。
これが設定されたら、クラスターの設定を取得するために次のコマンドを試してみることができます。
gcloud
に関するコンテナの詳細はこちらで読むことができます。
これはGCP内のkubernetesを列挙するシンプルなスクリプトです: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum
TLSブートストラップ権限昇格
当初、この権限昇格技術は、攻撃者がGKEクラスタ内で権限昇格し、それを完全に侵害することを可能にしました。
これは、GKEがメタデータにTLSブートストラップ資格情報を提供し、ポッドを侵害するだけで誰でもアクセス可能だったためです。
使用される技術は以下の投稿で説明されています:
そして、このプロセスを自動化するためにこのツールが作成されました: https://github.com/4ARMED/kubeletmein
しかし、この技術はメタデータの資格情報を使って新しいノードのためのCSR(Certificate Signing Request)を生成し、それが自動的に承認されるという事実を悪用していました。 私のテストでは、これらのリクエストはもはや自動的に承認されないことを確認したので、この技術がまだ有効かどうかはわかりません。
Kubelet APIのシークレット
この投稿では、GKE内のポッドからアクセス可能なKubelet APIアドレスが発見され、実行中のポッドの詳細が明らかになりました。
APIがリソースの変更を許可しない場合でも、レスポンスに機密情報が見つかる可能性があります。エンドポイント /pods は Kiterunner を使用して見つかりました。
最終更新