AWS - EKS Post Exploitation
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
अधिक जानकारी के लिए देखें
AWS - EKS Enumयदि आपके पास अनुमति eks:AccessKubernetesApi है, तो आप AWS EKS कंसोल के माध्यम से Kubernetes ऑब्जेक्ट्स को देख सकते हैं (अधिक जानें)।
आसान तरीका:
इतना आसान तरीका नहीं है:
यदि आप aws eks get-token --name <cluster_name> के साथ एक टोकन प्राप्त कर सकते हैं लेकिन आपके पास क्लस्टर जानकारी (describeCluster) प्राप्त करने की अनुमति नहीं है, तो आप अपना खुद का ~/.kube/config तैयार कर सकते हैं। हालांकि, टोकन होने पर, आपको जुड़ने के लिए url endpoint की आवश्यकता है (यदि आप एक पॉड से JWT टोकन प्राप्त करने में सफल रहे हैं तो यहाँ पढ़ें) और क्लस्टर का नाम।
मेरे मामले में, मैंने CloudWatch लॉग में जानकारी नहीं पाई, लेकिन मैंने LaunchTemplates userData में और EC2 मशीनों में userData में भी इसे पाया। आप इस जानकारी को userData में आसानी से देख सकते हैं, उदाहरण के लिए अगले उदाहरण में (क्लस्टर का नाम cluster-name था):
EKS क्लस्टर का निर्माता हमेशा समूह के kubernetes क्लस्टर भाग system:masters (k8s admin) में प्रवेश प्राप्त कर सकेगा। इस लेख के समय पर क्लस्टर को बनाने वाले को खोजने का कोई सीधा तरीका नहीं है (आप CloudTrail की जांच कर सकते हैं)। और उस अधिकार को हटाने का कोई तरीका नहीं है।
K8s पर अधिक AWS IAM उपयोगकर्ताओं या भूमिकाओं को पहुँच प्रदान करने का तरीका configmap aws-auth का उपयोग करना है।
इसलिए, config map aws-auth पर लिखने के अधिकार वाले कोई भी व्यक्ति पूरे क्लस्टर को समझौता कर सकेगा।
IAM भूमिकाओं और उपयोगकर्ताओं को अतिरिक्त अधिकार प्रदान करने के बारे में अधिक जानकारी के लिए एक ही या विभिन्न खाते में और इसे दुरुपयोग करने के लिए privesc इस पृष्ठ की जांच करें।
यहाँ पर इस अद्भुत पोस्ट की जांच करें कि IAM -> Kubernetes प्रमाणीकरण कैसे काम करता है।
यह संभव है कि kubernetes सेवा खाते के लिए OpenID प्रमाणीकरण की अनुमति दी जाए ताकि वे AWS में भूमिकाएँ ग्रहण कर सकें। जानें कि यह इस पृष्ठ पर कैसे काम करता है।
नहीं मिला कोई दस्तावेज़ जो 'दो अक्षरों' और 'संख्या' के लिए मानदंडों को समझाए। लेकिन अपनी ओर से कुछ परीक्षण करते समय मैंने इनमें से कुछ को बार-बार देखा:
gr7
yl4
वैसे भी, ये सिर्फ 3 अक्षर हैं, हम इन्हें ब्रूटफोर्स कर सकते हैं। सूची उत्पन्न करने के लिए नीचे दिए गए स्क्रिप्ट का उपयोग करें।
फिर wfuzz के साथ
याद रखें कि & को बदलें।
यदि एक हमलावर EKS पर अनुमति के साथ AWS के क्रेडेंशियल्स प्राप्त करता है। यदि हमलावर अपने kubeconfig को कॉन्फ़िगर करता है (बिना update-kubeconfig को कॉल किए) जैसा कि पहले समझाया गया है, तो get-token Cloudtrail में लॉग उत्पन्न नहीं करता है क्योंकि यह AWS API के साथ इंटरैक्ट नहीं करता है (यह केवल स्थानीय रूप से टोकन बनाता है)।
तो जब हमलावर EKS क्लस्टर के साथ बात करता है, cloudtrail उपयोगकर्ता के चोरी होने और इसे एक्सेस करने से संबंधित कुछ भी लॉग नहीं करेगा।
ध्यान दें कि EKS क्लस्टर में लॉग सक्षम हो सकते हैं जो इस एक्सेस को लॉग करेंगे (हालांकि, डिफ़ॉल्ट रूप से, वे अक्षम होते हैं)।
डिफ़ॉल्ट रूप से, उपयोगकर्ता या भूमिका जिसने एक क्लस्टर बनाया है, हमेशा क्लस्टर पर प्रशासनिक विशेषाधिकार रखने वाला होगा। और यही एकमात्र "सुरक्षित" एक्सेस है जो AWS Kubernetes क्लस्टर पर होगा।
तो, यदि एक हमलावर फर्गेट का उपयोग करके एक क्लस्टर से समझौता करता है और सभी अन्य प्रशासकों को हटा देता है और क्लस्टर बनाने वाले AWS उपयोगकर्ता/भूमिका को हटा देता है, हमलावर ने क्लस्टर को फिरौती** ली हो सकती है**।
ध्यान दें कि यदि क्लस्टर EC2 VMs का उपयोग कर रहा था, तो नोड से प्रशासनिक विशेषाधिकार प्राप्त करना और क्लस्टर को पुनर्प्राप्त करना संभव हो सकता है।
वास्तव में, यदि क्लस्टर फर्गेट का उपयोग कर रहा है, तो आप EC2 नोड्स प्राप्त कर सकते हैं या सब कुछ EC2 में क्लस्टर में स्थानांतरित कर सकते हैं और नोड में टोकन को एक्सेस करके इसे पुनर्प्राप्त कर सकते हैं।
JWT टोकन को डिकोड करने पर हमें क्लस्टर आईडी और क्षेत्र भी मिलता है। यह जानकर कि EKS URL का मानक प्रारूप है
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
