मुख्य विषयवस्तु में जाएं
ब्लॉग पर वापस जाएं

खतरा अनुसंधान

कैसे एक हमलावर AWS में आपके ऐप को भंग करने के लिए इंस्टेंस मेटाडेटा का उपयोग कर सकता है

मार्च 22, 2022

त्यागा वासुदेवन द्वारा - उत्पाद प्रबंधन के उपाध्यक्ष, Skyhigh Security

अपने एंटरप्राइज़ अनुप्रयोगों के लिए क्लाउड-नेटिव आर्किटेक्चर में जाना जबरदस्त व्यावसायिक मूल्य प्रदान कर सकता है, पैचिंग और सर्वर इन्फ्रास्ट्रक्चर को अपग्रेड करने जैसे कठिन कार्यों को ऑफ-लोड करते समय स्केल और चपलता जोड़ सकता है।

हालाँकि, प्रत्येक क्लाउड वातावरण में, चाहे Amazon Web Services (AWS), Azure या Google Cloud, जोखिम की एक नई श्रेणी है। क्लाउड-नेटिव खतरे क्लाउड वातावरण में आपके पास मौजूद नए संदर्भ और कॉन्फ़िगरेशन आवश्यकताओं से उपजे हैं। ऐतिहासिक रूप से, भंडारण वस्तुओं तक सार्वजनिक पहुंच जैसी डिफ़ॉल्ट सेटिंग्स ने संवेदनशील डेटा को खुले में छोड़ दिया है, इन कमजोरियों के लिए रेंगने वाले किसी भी व्यक्ति द्वारा चोरी करना आसान है।

नए वातावरण में गलतियाँ करना आसान है, नई सेटिंग्स लगातार पेश की जाती हैं क्योंकि क्लाउड प्रदाताओं द्वारा नई क्षमताओं को जोड़ा जाता है। आपके क्लाउड वातावरण का विन्यास हमेशा आपकी जिम्मेदारी है। AWS और अन्य का इस बात पर कोई नियंत्रण नहीं है कि आप उनकी सेवाओं का उपयोग कैसे करते हैं। वे आपके लिए निर्माण करने के लिए एक टेम्पलेट हैं।

आपके कॉन्फ़िगरेशन के परिणाम को नहीं समझना और आप क्लाउड-नेटिव एप्लिकेशन कैसे बनाते हैं, इसके भयावह परिणाम हो सकते हैं। और यहां तक कि सबसे समझदार क्लाउड ग्राहक भी इन परिणामों से पीड़ित हो सकते हैं।

मामले में मामला उल्लंघन है कि कैपिटल वन को लगभग तीन साल पहले सामना करना पड़ा था जहां एक हमलावर के पास 100 मिलियन अमेरिकी व्यक्तियों से सामाजिक सुरक्षा संख्या और 6 मिलियन कनाडाई व्यक्तियों से सामाजिक बीमा संख्या तक पहुंच थी। हमलावर ने डेटा तक पहुंच प्राप्त करने के लिए कई तकनीकों का इस्तेमाल किया, लेकिन हमले से एक महत्वपूर्ण सीख यह थी कि वर्चुअल मशीनों तक पहुंच की रक्षा के लिए डिज़ाइन किया गया एक सुरक्षा सुविधा - इलास्टिक कंप्यूट क्लाउड या ईसी इंस्टेंस - हमलावर ने जोड़ा। इस सुविधा को इंस्टेंस मेटाडेटा सेवा या IMDS कहा जाता है।

उदाहरण मेटाडेटा हमले

IMDS (IMDSv1) का संस्करण 1 2012 में जारी किया गया था ताकि EC2 उदाहरणों को अन्य AWS सेवाओं के साथ इंटरैक्ट करने के लिए अधिक सुरक्षित तरीका मिल सके। उदाहरण पर AWS कुंजियाँ छोड़ने के बजाय, ग्राहक अब EC2 इंस्टेंस को क्रेडेंशियल प्राप्त करने और अन्य AWS सेवाओं को AWS API कॉल करने के लिए मेटाडेटा सेवा से क्वेरी कर सकते हैं। उदाहरण के लिए, यदि EC2 इंस्टेंस को कुछ ग्राहक डेटा मिला है, तो वह उस डेटा को Amazon सिंपल स्टोरेज सर्विस (S3) बकेट में स्टोर करने के लिए IMDSv1 का उपयोग कर सकता है। यह सटीक क्षमता थी कि हमलावर ने कैपिटल वन ग्राहकों के बारे में जानकारी संग्रहीत करने के लिए उपयोग की जाने वाली S3 बाल्टी से संवेदनशील जानकारी को नीचे खींचने के लिए उपयोग किया था।

अपने स्वयं के परीक्षण में हम डुप्लिकेट करने में सक्षम थे कि डेटा का यह निष्कर्षण किसी भी एप्लिकेशन में कैसे काम कर सकता है। हमारे उदाहरण में, महामारी विज्ञानियों की एक टीम ने एडब्ल्यूएस में एक क्लाउड-नेटिव एप्लिकेशन का निर्माण किया, जिसमें एक सार्वजनिक डैशबोर्ड के साथ डेटा का नेत्रहीन प्रतिनिधित्व किया जा सके, जो वायरस जीनोम का विश्लेषण करते हुए उनकी प्रगति दिखा रहा है।

 

इस एप्लिकेशन के विकास के चरण के दौरान, टीम एक चुनौती में भाग गई। उनके वर्चुअल प्राइवेट क्लाउड (VPC) के अधिकांश संसाधनों को इंटरनेट से छिपाया जाना चाहिए था। सार्वजनिक दृश्य के लिए उनके वीपीसी में एकमात्र संसाधन डैशबोर्ड था।

S3 बाल्टी अपने डेटा की मेजबानी करने के लिए निजी रहने की आवश्यकता है। S3 से डेटा को सार्वजनिक डैशबोर्ड पर खींचने के लिए, उन्होंने एक रिवर्स प्रॉक्सी जोड़ा, जो एक बिचौलिए के रूप में कार्य करता है। यह सब एक त्वरित Google खोज थी, और इसे अपने आवेदन में जोड़ने के लिए कोड की कुछ पंक्तियाँ थीं।

 

महामारी विज्ञानियों की टीम के लिए, रिवर्स प्रॉक्सी एक बुनियादी, सुरुचिपूर्ण समाधान था जो उनके उपयोग के मामले के लिए पूरी तरह से कार्य करता था। उन्हें जो एहसास नहीं हुआ वह यह है कि इसने उन्हें बड़े पैमाने पर उल्लंघन के लिए स्थापित किया।

रिवर्स प्रॉक्सी चलाने वाले गणना उदाहरण को उनके निजी एस 3 बाल्टी तक पहुंचने की अनुमति के साथ एक आईएएम भूमिका सौंपी गई थी। S3 तक पहुँचने के लिए रिवर्स प्रॉक्सी के लिए क्रेडेंशियल इंस्टेंस मेटाडेटा से प्राप्त किए गए थे।

साइट पर आने वाले और उनके डेटा में रुचि रखने वाले एक हमलावर ने देखा कि टीम ने डैशबोर्ड में रिवर्स प्रॉक्सी के आईपी पते का संदर्भ दिया था। हमलावर ने तब यह देखने के लिए जाँच की कि क्या वे इससे जुड़ सकते हैं। उनकी कनेक्टिविटी की पुष्टि करने के बाद, हमलावर ने यह देखने के लिए जाँच की कि क्या वे रिवर्स प्रॉक्सी के माध्यम से इंस्टेंस मेटाडेटा तक पहुँच सकते हैं। सफलता।

रिवर्स प्रॉक्सी के माध्यम से और इंस्टेंस मेटाडेटा से, हमलावर ने टीम के निजी S3 स्टोरेज बकेट में क्रेडेंशियल्स का खुलासा किया।

 

अब, S3 बाल्टी तक पहुंच के साथ, हमलावर अत्यधिक संवेदनशील डेटा चुरा सकता है जिसे टीम ने अपने आवेदन के लिए संग्रहीत किया था। हमलावर ने बस लक्ष्य S3 बाल्टी को दूसरे AWS खाते में अपने स्वयं के S3 बाल्टी में सिंक किया, और डेटा उनका था।

 

इस प्रकार का हमला MITRE द्वारा क्लाउड वातावरण के लिए उनके ATT&CK ढांचे में वर्णित 43 तकनीकों में से एक है: https://attack.mitre.org/matrices/enterprise/cloud/

AWS इंस्टेंस मेटाडेटा हमलों को कैसे कम करता है

इस सेवा की सुरक्षा में सुधार करने के लिए, AWS ने IMDSv2 जारी किया, जो सुरक्षा की कई नई परतें जोड़ता है।

IMDSv2 में, बाह्य उपयोगकर्ताओं को क्रेडेंशियल्स प्राप्त करने से ब्लॉक किया जाता है, जिससे केवल अनुप्रयोग संसाधन उन्हें प्राप्त कर सकते हैं. सुरक्षा की इस परत और IMDSv2 के बारे में यहाँ और पढ़ें: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

हालाँकि, चुनौती बनी हुई है कि IMDSv1 अभी भी जीवित है। एडब्ल्यूएस में कुछ भी नहीं है जो ग्राहकों को आईएमडीएसवी 1 का उपयोग करने से रोकता है, और आप अभी भी इसे अपने सभी ईसी 2 उदाहरणों के लिए डिफ़ॉल्ट रूप से उपयोग कर सकते हैं। जैसा कि हमने पहले उल्लेख किया है, यह सुनिश्चित करने के लिए AWS की ज़िम्मेदारी नहीं है कि आप क्लाउड का सुरक्षित रूप से उपयोग कर रहे हैं। यह जिम्मेदारी पूरी तरह से ग्राहक पर आती है।

हमले में हमने अभी वर्णित किया है, बाहरी अनुरोधों को आंतरिक संसाधनों तक पहुंचने की अनुमति देने के लिए रिवर्स प्रॉक्सी को गलत तरीके से कॉन्फ़िगर किया गया था। यदि टीम ने IMDSv2 का उपयोग करने के लिए अपने गणना उदाहरण को कॉन्फ़िगर किया था, तो बाहरी खतरे के अभिनेता द्वारा अनधिकृत पहुंच अवरुद्ध हो गई होगी।

Skyhigh Cloud नेटिव्ह ऍप्लिकेशन प्रोटेक्शन कसे मदत करू शकते

पर Skyhigh Security, हमारे पास कई दृष्टिकोण हैं जो इस तरह के हमलों का पता लगाने और रोकने में आपकी सहायता कर सकते हैं। स्काईहाई क्लाउड नेटिव एप्लिकेशन प्रोटेक्शन प्लेटफॉर्म (CNAPP) हमारा क्लाउड-नेटिव सिक्योरिटी प्लेटफॉर्म है जो आपको AWS, Azure, GCP में कॉन्फ़िगरेशन की निगरानी और अपडेट करने के साथ-साथ अतिरिक्त सुरक्षा उपायों की एक विस्तृत श्रृंखला के साथ अनुमति देता है जिसके बारे में आप यहां पढ़ सकते हैं।

एडब्ल्यूएस के साथ प्रत्यक्ष एपीआई-एकीकरण का उपयोग करते हुए, स्काईहाई सीएनएपी लगातार अमेज़ॅन क्लाउडवॉच - एक एप्लिकेशन और इन्फ्रास्ट्रक्चर मॉनिटरिंग सेवा की निगरानी करता है - यह इंगित करने के लिए कि आप प्रत्येक ईसी 2 उदाहरण में आईएमडीएस के किस संस्करण का उपयोग कर रहे हैं।

जब CloudWatch IMDSv1 का उपयोग करके सक्रिय रूप से एक उदाहरण लॉग करता है, तो Skyhigh CNAPP एक सुरक्षा घटना उत्पन्न करता है, जो आपको IMDSv2 में अपने कॉन्फ़िगरेशन को अपडेट करने के लिए सूचित करता है, जो बाहरी उपयोगकर्ताओं द्वारा आपके क्रेडेंशियल्स तक अनधिकृत पहुंच को रोक देगा।

IMDS संस्करण कॉन्फ़िगरेशन के लिए Skyhigh CNAPP नीति घटनाएं

सभी स्थानीय कोड और उपयोगकर्ताओं के लिए अपने EC2 उदाहरणों पर IMDSv2 लागू करना सबसे अच्छा अभ्यास है। एक बार जब आप निर्दिष्ट करते हैं कि IMDSv2 का उपयोग किया जाना चाहिए, तो IMDSv1 अब कार्य नहीं करेगा। AWS के पास IMDSv2 का उपयोग करने के लिए अपने उदाहरणों को कॉन्फ़िगर करने के तरीके के बारे में चरण-दर-चरण निर्देश हैं।

इस हमले के उदाहरण से परे, स्काईहाई CNAPP आपको अपने क्लाउड-देशी अनुप्रयोगों की सुरक्षा के लिए सर्वोत्तम प्रथाओं की एक श्रृंखला को लागू करने की अनुमति देता है:

  • अपने कॉन्फ़िगरेशन का लगातार ऑडिट करें। Skyhigh CNAPP के साथ आप उत्पादन में प्रवेश करने से पहले AWS CloudFormation टेम्प्लेट को स्कैन कर सकते हैं, और फिर समय के साथ अपने कॉन्फ़िगरेशन में किसी भी "बहाव" का पता लगा सकते हैं। यह आपको गलत कॉन्फ़िगरेशन का पता लगाने और संसाधन अनुमति के लिए कम-विशेषाधिकार मॉडल लागू करने की अनुमति देता है।
  • शून्य-विश्वास लागू करें। एक पद्धति के रूप में शून्य-विश्वास का उपयोग करें, जहां केवल विशिष्ट संसाधनों को एक दूसरे के साथ चलाने और संवाद करने की अनुमति है। बाकी सब कुछ अवरुद्ध है।
  • कोड कमजोरियों के लिए स्कैन करें। विशेष रूप से डॉकर जैसे खुले सॉफ़्टवेयर वितरण मॉडल के साथ, निरंतर आधार पर कमजोरियों के लिए अपने एप्लिकेशन संसाधनों की निगरानी करना महत्वपूर्ण है।
  • विसंगतियों और खतरों का पता लगाएं। उपयोगकर्ता और इकाई व्यवहार विश्लेषण (UEBA) के साथ, आप विषम गतिविधि और क्रेडेंशियल चोरी जैसे वास्तविक खतरों को उजागर करने के लिए लाखों क्लाउड घटनाओं का आकलन कर सकते हैं।
  • संग्रहण ऑब्जेक्ट पर DLP चलाएँ। किसी भी अन्य क्लाउड सेवा की तरह जिसे आप अपने नेटवर्क, या एंडपॉइंट को मंजूरी देते हैं, एडब्ल्यूएस के भीतर आप अपने डेटा को एस 3 के भीतर वर्गीकृत कर सकते हैं और चला सकते हैं data loss prevention निष्कासन प्रयासों को रोकने के लिए।

अपने संगठन में इन उपायों को लागू करने के बारे में बात करने के लिए हमसे संपर्क करें

ब्लॉग पर वापस जाएं