GCP - Containers & GKE Enum

HackTricks 지원하기

컨테이너

GCP 컨테이너에서는 GCP가 제공하는 대부분의 컨테이너 기반 서비스를 찾을 수 있으며, 여기에서 가장 일반적인 것들을 열거하는 방법을 볼 수 있습니다:

gcloud container images list
gcloud container images list --repository us.gcr.io/<project-name> #Search in other subdomains repositories
gcloud container images describe <name>
gcloud container subnets list-usable
gcloud container clusters list
gcloud container clusters describe <name>
gcloud container clusters get-credentials [NAME]

# Run a container locally
docker run --rm -ti gcr.io/<project-name>/secret:v1 sh

# Login & Download
sudo docker login -u oauth2accesstoken -p $(gcloud auth print-access-token) https://HOSTNAME
## where HOSTNAME is gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io.
sudo docker pull HOSTNAME/<project-name>/<image-name>

Privesc

다음 페이지에서 컨테이너 권한을 악용하여 권한 상승하는 방법을 확인할 수 있습니다:

GCP - Container Privesc

Node Pools

이것은 쿠버네티스 클러스터를 형성하는 머신(노드)의 풀입니다.

# Pool of machines used by the cluster
gcloud container node-pools list --zone <zone> --cluster <cluster>
gcloud container node-pools describe --cluster <cluster> --zone <zone> <node-pool>

Kubernetes

Kubernetes에 대한 정보는 이 페이지를 확인하세요:

Kubernetes Pentesting

먼저, 프로젝트에 Kubernetes 클러스터가 존재하는지 확인할 수 있습니다.

gcloud container clusters list

클러스터가 있는 경우, gcloud~/.kube/config 파일을 자동으로 구성할 수 있습니다. 이 파일은 K8s 클러스터와 상호 작용하기 위한 기본 CLI인 kubectl을 사용할 때 인증하는 데 사용됩니다. 이 명령을 시도해 보세요.

gcloud container clusters get-credentials [CLUSTER NAME] --region [REGION]

그런 다음 ~/.kube/config 파일을 확인하여 생성된 자격 증명을 확인하십시오. 이 파일은 활성 gcloud 세션이 사용하는 동일한 ID를 기반으로 액세스 토큰을 자동으로 새로 고치는 데 사용됩니다. 물론 이를 위해서는 올바른 권한이 필요합니다.

이 설정이 완료되면 클러스터 구성을 가져오기 위해 다음 명령을 시도할 수 있습니다.

kubectl cluster-info

You can read more about gcloud for containers here.

This is a simple script to enumerate kubernetes in GCP: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum

TLS Boostrap Privilege Escalation

Initially this privilege escalation technique allowed to privesc inside the GKE cluster effectively allowing an attacker to fully compromise it.

This is because GKE provides TLS Bootstrap credentials in the metadata, which is accessible by anyone by just compromising a pod.

The technique used is explained in the following posts:

Ans this tool was created to automate the process: https://github.com/4ARMED/kubeletmein

However, the technique abused the fact that with the metadata credentials it was possible to generate a CSR (Certificate Signing Request) for a new node, which was automatically approved. In my test I checked that those requests aren't automatically approved anymore, so I'm not sure if this technique is still valid.

Secrets in Kubelet API

In this post it was discovered it was discovered a Kubelet API address accesible from inside a pod in GKE giving the details of the pods running:

curl -v -k http://10.124.200.1:10255/pods

API가 리소스를 수정하는 것을 허용하지 않더라도, 응답에서 민감한 정보를 찾을 수 있을 가능성이 있습니다. /pods 엔드포인트는 Kiterunner를 사용하여 발견되었습니다.

HackTricks 지원하기

Last updated