Kubernetes Escape: কনটেইনার ক্লাস্টারের সীমাবদ্ধতা ভেঙে কুবারনেটিস হ্যাকিং!

Kubernetes Escape বোঝার আগে আমাদের ক্লাস্টারের আর্কিটেকচার সম্পর্কে স্পষ্ট ধারণা থাকা প্রয়োজন। একটি Kubernetes ক্লাস্টারে রয়েছে Control Plane (যেখানে kube-apiserver, etcd, scheduler, এবং controller-manager থাকে) এবং Worker Nodes (যেখানে kubelet, kube-proxy, এবং Container Runtime যেমন containerd বা CRI-O চলে)। প্রতিটি Worker Node-এ একাধিক Pod চলে, এবং প্রতিটি Pod-এ এক বা একাধিক Container থাকে।

আক্রমণকারীর প্রাথমিক লক্ষ্য হতে পারে একটি Pod-এর মধ্যে Code Execution অর্জন করা। এটি একটি Vulnerable Web Application, একটি Misconfigured Service, অথবা একটি Compromised Container Image-এর মাধ্যমে ঘটতে পারে। এরপর আক্রমণকারী Pod থেকে Node-এ, এবং Node থেকে Control Plane-এ Lateral Movement-এর মাধ্যমে পুরো ক্লাস্টারের নিয়ন্ত্রণ নিতে চেষ্টা করে।

সবচেয়ে সাধারণ Kubernetes Escape ভেক্টর হলো Privileged Container-এর অপব্যবহার। যখন একটি Container privileged: true দিয়ে চালানো হয়, তখন এটি কার্যত হোস্টের সমস্ত Capabilities পেয়ে যায়। এর অর্থ হলো Container-এর ভেতর থেকে আক্রমণকারী হোস্ট ফাইল সিস্টেম মাউন্ট করতে পারে, Kernel Module লোড করতে পারে, এমনকি /dev/sda সরাসরি অ্যাক্সেস করতে পারে।

একটি ক্লাসিক উদাহরণ হলো mount /dev/sda1 /mnt কমান্ড ব্যবহার করে হোস্টের ফাইল সিস্টেম Container-এর ভেতরে মাউন্ট করা এবং তারপর /etc/shadow বা SSH কী চুরি করা। এমনকি যদি Privileged না হয়, কিন্তু Container-এ CAP_SYS_ADMIN, CAP_SYS_PTRACE, বা CAP_DAC_READ_SEARCH Capability থাকে, তবুও আক্রমণকারী বিভিন্ন কৌশলে Escape সম্ভব করতে পারে।

আক্রমণকারীরা প্রায়শই capsh --print কমান্ড দিয়ে Container-এর Capabilities চেক করে। যদি বিপজ্জনক Capability পাওয়া যায়, তবে তারা সেগুলো কাজে লাগিয়ে হোস্ট প্রসেসে প্রবেশ করার চেষ্টা করে।

আরেকটি বহুল ব্যবহৃত Escape কৌশল হলো hostPath Volume-এর অপব্যবহার। যদি একটি Pod-এ হোস্টের একটি ডিরেক্টরি যেমন / বা /var/run/docker.sock মাউন্ট করা থাকে, তবে আক্রমণকারী সরাসরি হোস্টে ফাইল লিখতে বা পড়তে পারে। বিশেষ করে Docker Socket মাউন্ট করা থাকলে আক্রমণকারী হোস্টে নতুন Container তৈরি করতে পারে এবং সেই নতুন Container-কে Privileged বা hostPID:true সেট করে পুরো হোস্টে অ্যাক্সেস পেতে পারে।

docker -H unix:///var/run/docker.sock run --rm \
  --privileged --pid=host -v /:/host alpine \
  chroot /host bash

এই কমান্ডটি দেখায় কীভাবে Docker Socket অ্যাক্সেসের মাধ্যমে হোস্ট Shell অর্জন করা যায়। তাই Container Image তৈরি করার সময় কোনোভাবেই Docker Socket মাউন্ট করা উচিত নয়।

প্রতিটি Pod ডিফল্টভাবে একটি ServiceAccount Token পায়, যা /var/run/secrets/kubernetes.io/serviceaccount/token-এ মাউন্ট করা থাকে। যদি এই ServiceAccount-এর RBAC Permission ভুলভাবে কনফিগার করা থাকে, তাহলে আক্রমণকারী এই Token ব্যবহার করে Kubernetes API-তে সরাসরি কল করতে পারে।

উদাহরণস্বরূপ, যদি ServiceAccount-এর pods/exec বা pods/create Permission থাকে cluster-admin scope-এ, তাহলে আক্রমণকারী যেকোনো namespace-এ নতুন Privileged Pod তৈরি করতে পারে, যা পরে hostNetwork এবং hostPID সহ চলবে। এভাবে তারা সরাসরি Control Plane-এ পৌঁছে যায়।

Penetration Tester-রা প্রায়ই kubectl auth can-i কমান্ড ব্যবহার করে দেখেন তাদের কাছে কী কী Permission রয়েছে:

kubectl auth can-i --list --as=system:serviceaccount:default:default

Container Isolation মূলত Linux Kernel-এর Namespace এবং cgroups-এর উপর নির্ভরশীল। তাই Kernel-এ যেকোনো দুর্বলতা সরাসরি Container Escape-এর জন্য ব্যবহার করা যেতে পারে। উল্লেখযোগ্য CVE-গুলোর মধ্যে রয়েছে CVE-2022-0492 (cgroups v1 release_agent issue), CVE-2022-0185 (FUSE বা OverlayFS-এর কারণে Container Escape), এবং CVE-2024-21626 (runc Vulnerability)।

CVE-2024-21626 বিশেষভাবে উল্লেখযোগ্য কারণ এটি একটি File Descriptor Leak সমস্যা runc-এ, যা একজন আক্রমণকারীকে একটি Container Image তৈরি করতে দেয় যা চালানোর সময় হোস্ট ফাইল সিস্টেমে অ্যাক্সেস পেয়ে যায়। এই ধরনের Supply Chain ভিত্তিক আক্রমণ অত্যন্ত বিপজ্জনক।

অনেক ক্লাস্টারে Kubelet API (পোর্ট 10250) Authentication ছাড়াই খোলা থাকে। যদি একটি Pod থেকে Kubelet API-তে অ্যাক্সেস পাওয়া যায়, তাহলে আক্রমণকারী /exec, /run, বা /attach Endpoint ব্যবহার করে অন্য Pod-এ Command Execute করতে পারে। এটি Lateral Movement-এর একটি শক্তিশালী পদ্ধতি।

এছাড়া etcd ডেটাস্টোরে সরাসরি অ্যাক্সেস পেলে আক্রমণকারী পুরো ক্লাস্টারের সমস্ত Secret, ConfigMap, এবং RBAC তথ্য দেখতে পারে। অনেক সময় etcd ভুল কনফিগারেশনের কারণে TLS Authentication ছাড়াই অ্যাক্সেসযোগ্য থাকে।

২০১৮ সালে Tesla-র Kubernetes Dashboard, যা কোনো Authentication ছাড়াই Internet-এ Exposed ছিল, আক্রমণকারীরা সেটি ব্যবহার করে Tesla-র AWS Credentials চুরি করে এবং সেই Credentials দিয়ে Cryptocurrency Mining চালায়। এটি Cryptojacking-এর একটি ক্লাসিক উদাহরণ।

আরেকটি বিখ্যাত ঘটনা হলো ২০১৯ সালের Capital One Data Breach, যেখানে একটি Misconfigured WAF এবং Container পরিবেশের কারণে প্রায় ১০ কোটি গ্রাহকের তথ্য ফাঁস হয়। যদিও এটি সরাসরি Kubernetes ছিল না, তবে এটি Cloud-native পরিবেশে Misconfiguration কতটা ভয়াবহ হতে পারে তার একটি গুরুত্বপূর্ণ শিক্ষা।

Kubernetes Penetration Testing-এর জন্য বেশ কিছু পেশাদার টুল রয়েছে। kube-hunter NCC Group দ্বারা তৈরি, যা ক্লাস্টারের নিরাপত্তা দুর্বলতা স্বয়ংক্রিয়ভাবে স্ক্যান করে। Peirates একটি Interactive Tool, যা Compromised Pod থেকে চালালে বিভিন্ন Escape কৌশল স্বয়ংক্রিয়ভাবে পরীক্ষা করে। Kubesploit হলো Metasploit-এর মতো একটি Post-exploitation Framework, যা বিশেষভাবে Container পরিবেশের জন্য ডিজাইন করা।

Bishop Fox-এর তৈরি Cloudfox এবং Trail of Bits-এর Kubescape-এর মতো টুলগুলো ক্লাস্টারের Security Posture বিশ্লেষণে অত্যন্ত কার্যকর। Red Team Operator-রা এই টুলগুলো ব্যবহার করে দ্রুত Attack Path খুঁজে বের করেন।

Kubernetes Escape প্রতিরোধে Defense in Depth অপরিহার্য। প্রথমেই Pod Security Standards (পূর্বে PodSecurityPolicy) প্রয়োগ করতে হবে, যা Privileged Container, hostPath Mount, এবং বিপজ্জনক Capability নিষিদ্ধ করে। Kubernetes 1.25 থেকে Pod Security Admission ব্যবহার করে এই নীতি প্রয়োগ করা যায়।

দ্বিতীয়ত, Network Policies-এর মাধ্যমে Pod-to-Pod যোগাযোগ সীমিত করতে হবে। Calico, Cilium, বা Weave Net-এর মতো CNI ব্যবহার করে Zero Trust নেটওয়ার্কিং প্রয়োগ করা সম্ভব। তৃতীয়ত, RBAC-কে অত্যন্ত সতর্কতার সাথে কনফিগার করতে হবে এবং Least Privilege Principle অনুসরণ করতে হবে। ServiceAccount Token Auto-mount ডিজেবল করা উচিত যেখানে প্রয়োজন নেই।

Runtime Security-এর জন্য Falco-র মতো ওপেন সোর্স টুল ব্যবহার করা যেতে পারে, যা Kernel-level Events মনিটর করে অস্বাভাবিক কার্যকলাপ শনাক্ত করে। OPA Gatekeeper বা Kyverno-র মতো Policy Engine দিয়ে Admission Controller-এ Custom Rule প্রয়োগ করা যায়। Container Image Scanning-এর জন্য Trivy, Grype, বা Snyk ব্যবহার করে ইমেজে দুর্বলতা চিহ্নিত করতে হবে।

সবচেয়ে গুরুত্বপূর্ণ হলো, Container-এর ভেতরে কখনোই Root User হিসেবে অ্যাপ্লিকেশন না চালানো এবং নিয়মিতভাবে Cluster Configuration Audit করা। CIS Kubernetes Benchmark অনুসরণ করে নিয়মিত Compliance Check চালানো উচিত।