AWS - EKS Post Exploitation
EKS
अधिक जानकारी के लिए देखें
pageAWS - EKS EnumAWS Console से क्लस्टर का एन्युमरेट करें
यदि आपके पास अनुमति eks:AccessKubernetesApi
है, तो आप AWS EKS कंसोल के माध्यम से Kubernetes ऑब्जेक्ट्स को देख सकते हैं (और जानें).
AWS Kubernetes क्लस्टर से कनेक्ट करें
आसान तरीका:
इतना आसान नहीं है:
यदि आप aws eks get-token --name <cluster_name>
के साथ टोकन प्राप्त कर सकते हैं परन्तु आपके पास क्लस्टर की जानकारी प्राप्त करने की अनुमति नहीं है (describeCluster), तो आप अपना ~/.kube/config
तैयार कर सकते हैं। हालांकि, टोकन होने के बावजूद, आपको अभी भी url endpoint की आवश्यकता होती है जिससे जुड़ना है और क्लस्टर का नाम।
मेरे मामले में, मुझे CloudWatch लॉग्स में यह जानकारी नहीं मिली, लेकिन मैंने इसे LaunchTemaplates के userData में और EC2 मशीनों के userData में भी पाया। आप इस जानकारी को userData में आसानी से देख सकते हैं, उदाहरण के लिए निम्नलिखित उदाहरण में (क्लस्टर का नाम cluster-name था):
AWS से Kubernetes तक
EKS cluster का निर्माता हमेशा समूह system:masters
(k8s admin) के kubernetes cluster भाग में प्रवेश करने में सक्षम होगा। इस लेखन के समय, cluster बनाने वाले को पता लगाने का कोई सीधा तरीका नहीं है (CloudTrail की जांच कर सकते हैं)। और उस विशेषाधिकार को हटाने का कोई तरीका नहीं है।
अधिक AWS IAM उपयोगकर्ताओं या भूमिकाओं को K8s तक पहुंच प्रदान करने का तरीका configmap aws-auth
का उपयोग करना है।
इसलिए, जिस किसी के पास भी config map aws-auth
पर लिखने की पहुंच होगी, वह पूरे cluster को समझौता करने में सक्षम होगा।
IAM भूमिकाओं और उपयोगकर्ताओं को अतिरिक्त विशेषाधिकार प्रदान करने के बारे में अधिक जानकारी के लिए और एक ही या अलग खाते में और इसका दुरुपयोग कैसे करें, इस पृष्ठ की जांच करें।
इस शानदार पोस्ट को भी देखें जिससे आप सीख सकते हैं कि IAM -> Kubernetes प्रमाणीकरण कैसे काम करता है।
Kubernetes से AWS तक
AWS में भूमिकाओं को मान लेने के लिए OpenID प्रमाणीकरण के साथ kubernetes सेवा खाते की अनुमति देना संभव है। जानें कि यह कैसे काम करता है इस पृष्ठ पर।
CloudTrail को बायपास करना
यदि कोई हमलावर EKS पर अनुमति वाले AWS की साख प्राप्त करता है। यदि हमलावर अपना खुद का kubeconfig
कॉन्फ़िगर करता है (बिना update-kubeconfig
को कॉल किए), जैसा कि पहले समझाया गया है, तो get-token
Cloudtrail में लॉग नहीं बनाता क्योंकि यह AWS API के साथ इंटरैक्ट नहीं करता (यह केवल स्थानीय रूप से टोकन बनाता है)।
इसलिए जब हमलावर EKS cluster से बात करता है, cloudtrail उस उपयोगकर्ता से संबंधित कुछ भी लॉग नहीं करेगा जिसे चुराया गया है और उसे एक्सेस कर रहा है।
ध्यान दें कि EKS cluster में लॉग सक्षम हो सकते हैं जो इस पहुंच को लॉग करेंगे (हालांकि, डिफ़ॉल्ट रूप से, वे अक्षम होते हैं)।
EKS Ransom?
डिफ़ॉल्ट रूप से उपयोगकर्ता या भूमिका जिसने cluster बनाया है हमेशा cluster पर admin विशेषाधिकार रखेगा। और वही "सुरक्षित" पहुंच होगी जो AWS के पास Kubernetes cluster पर होगी।
इसलिए, यदि कोई हमलावर fargate का उपयोग करके cluster को समझौता करता है और सभी अन्य admins को हटा देता है और AWS उपयोगकर्ता/भूमिका को हटा देता है जिसने Cluster बनाया, हमलावर cluster को ransom कर सकता है।
ध्यान दें कि यदि cluster EC2 VMs का उपयोग कर रहा था, तो Node से Admin विशेषाधिकार प्राप्त करना संभव हो सकता है और cluster को पुनः प्राप्त कर सकता है।
वास्तव में, यदि cluster Fargate का उपयोग कर रहा है तो आप EC2 nodes को जोड़ सकते हैं या सब कुछ EC2 में cluster में स्थानांतरित कर सकते हैं और Node में टोकन तक पहुंच प्राप्त करके इसे पुनः प्राप्त कर सकते हैं।
Last updated