GCP - Containers & GKE Enum
컨테이너
GCP 컨테이너에서는 GCP가 제공하는 대부분의 컨테이너 기반 서비스를 찾을 수 있으며, 여기에서 가장 일반적인 것들을 열거하는 방법을 볼 수 있습니다:
권한 상승
다음 페이지에서는 권한 상승을 위해 컨테이너 권한을 남용하는 방법을 확인할 수 있습니다:
GCP - Container Privesc노드 풀
이것들은 쿠버네티스 클러스터를 형성하는 머신(노드)의 풀입니다.
Kubernetes
쿠버네티스에 대한 정보는 다음 페이지를 확인하십시오:
Kubernetes Pentesting먼저 프로젝트에 쿠버네티스 클러스터가 있는지 확인할 수 있습니다.
만약 클러스터가 있다면 gcloud
를 사용하여 자동으로 ~/.kube/config
파일을 구성할 수 있습니다. 이 파일은 K8s 클러스터와 상호 작용하기 위한 네이티브 CLI 인 kubectl를 사용할 때 인증하는 데 사용됩니다. 다음 명령을 시도해보세요.
그럼 생성된 자격 증명을 확인하기 위해 ~/.kube/config
파일을 살펴보세요. 이 파일은 활성 gcloud
세션에서 사용 중인 동일한 ID를 기반으로 액세스 토큰을 자동으로 새로 고칠 때 사용됩니다. 물론 이를 위해서는 올바른 권한이 필요합니다.
이 설정이 완료되면 다음 명령을 시도하여 클러스터 구성을 가져올 수 있습니다.
당신은 gcloud
를 위한 컨테이너에 대해 더 많은 정보를 여기에서 읽을 수 있습니다.
이것은 GCP에서 쿠버네티스를 열거하는 간단한 스크립트입니다: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum
TLS 부트스트랩 권한 상승
초기에 이 권한 상승 기술은 GKE 클러스터 내부에서 권한 상승을 허용하여 공격자가 완전히 침투할 수 있었습니다.
이는 GKE가 TLS 부트스트랩 자격 증명을 메타데이터에서 제공하기 때문에 어떤 사람이라도 pod를 침투함으로써 액세스할 수 있기 때문입니다.
사용된 기술은 다음 게시물에서 설명되어 있습니다:
그리고 이 도구는 이 프로세스를 자동화하기 위해 만들어졌습니다: https://github.com/4ARMED/kubeletmein
그러나, 이 기술은 메타데이터 자격 증명을 통해 새 노드를 위한 CSR (서명 요청서)를 생성할 수 있었고, 이는 자동으로 승인되었습니다. 내 테스트에서 이러한 요청이 더 이상 자동으로 승인되지 않는 것을 확인했으므로, 이 기술이 여전히 유효한지 확신할 수 없습니다.
Kubelet API의 Secrets
이 게시물에서 GKE 내부의 pod에서 액세스할 수 있는 Kubelet API 주소가 발견되었으며, 실행 중인 pod의 세부 정보를 제공했습니다.
심각한 정보를 응답에서 찾을 수 있을 수 있습니다. Kiterunner를 사용하여 /pods 엔드포인트를 발견했습니다.
Last updated