AWS पर कैपिटल वन हैक का तकनीकी विवरण

19 जुलाई, 2019 को कैपिटल वन को यह संदेश मिला कि हर आधुनिक कंपनी को डर है- डेटा उल्लंघन हुआ है। इससे 106 मिलियन से अधिक लोग प्रभावित हुए। 140 अमेरिकी सामाजिक सुरक्षा नंबर, दस लाख कनाडाई सामाजिक सुरक्षा नंबर। 000 बैंक खाते. अप्रिय, क्या आप सहमत नहीं हैं?

दुर्भाग्यवश, 19 जुलाई को हैक नहीं हुआ। जैसा कि पता चला, पेगे थॉम्पसन, उर्फ. अनियमित, इसे 22 मार्च से 23 मार्च 2019 के बीच प्रतिबद्ध किया। वह है लगभग चार महीने पहले. वास्तव में, बाहरी सलाहकारों की मदद से ही कैपिटल वन यह पता लगाने में सक्षम था कि कुछ हुआ था।

अमेज़ॅन के एक पूर्व कर्मचारी को गिरफ्तार कर लिया गया और उसे $250 का जुर्माना और पांच साल की जेल का सामना करना पड़ा... लेकिन अभी भी बहुत सारी नकारात्मकता बाकी है। क्यों? क्योंकि हैक से पीड़ित कई कंपनियां साइबर अपराध में वृद्धि के बीच अपने बुनियादी ढांचे और अनुप्रयोगों को मजबूत करने की जिम्मेदारी से बचने की कोशिश कर रही हैं।

बहरहाल, आप इस कहानी को आसानी से गूगल पर देख सकते हैं। हम नाटक में नहीं जाएंगे, बल्कि बात करेंगे तकनीकी मामले का पक्ष.

सबसे पहले, क्या हुआ?

कैपिटल वन में लगभग 700 S3 बाल्टियाँ चल रही थीं, जिन्हें पेगे थॉम्पसन ने कॉपी किया और निकाल लिया।

दूसरे, क्या यह गलत तरीके से कॉन्फ़िगर की गई S3 बकेट नीति का एक और मामला है?

नहीं, इस बार नहीं। यहां उसने गलत तरीके से कॉन्फ़िगर किए गए फ़ायरवॉल वाले सर्वर तक पहुंच प्राप्त की और वहां से पूरे ऑपरेशन को अंजाम दिया।

रुको, यह कैसे संभव है?

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

स्टोन ने कहा कि कैपिटल वन ने शुरू में फ़ायरवॉल भेद्यता पर ध्यान नहीं दिया, लेकिन जैसे ही उसे इसकी जानकारी हुई, उसने तुरंत कार्रवाई की। स्टोन ने कहा, निश्चित रूप से इस तथ्य से मदद मिली कि हैकर ने कथित तौर पर सार्वजनिक डोमेन में महत्वपूर्ण पहचान संबंधी जानकारी छोड़ दी।

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

तो पहला उपाय यह है: जानें कि आपके फ़ायरवॉल क्या अनुमति देते हैं।

यह सुनिश्चित करने के लिए एक नीति या उचित प्रक्रिया स्थापित करें कि केवल वही खोला जाए जिसे खोलने की आवश्यकता है। यदि आप सुरक्षा समूह या नेटवर्क एसीएल जैसे एडब्ल्यूएस संसाधनों का उपयोग कर रहे हैं, तो जाहिर तौर पर ऑडिट के लिए चेकलिस्ट लंबी हो सकती है... लेकिन जैसे कई संसाधन स्वचालित रूप से बनाए जाते हैं (यानी क्लाउडफॉर्मेशन), उनकी ऑडिटिंग को स्वचालित करना भी संभव है। चाहे वह एक होममेड स्क्रिप्ट हो जो खामियों के लिए नई वस्तुओं को स्कैन करती है, या सीआई/सीडी प्रक्रिया में सुरक्षा ऑडिट जैसा कुछ... इससे बचने के लिए कई आसान विकल्प हैं।

कहानी का "मजाकिया" हिस्सा यह है कि अगर कैपिटल वन ने पहले ही छेद को बंद कर दिया होता... तो कुछ नहीं होता। और इसलिए, स्पष्ट रूप से, यह देखना हमेशा चौंकाने वाला होता है कि वास्तव में कुछ कैसे होता है बहुत साधारण किसी कंपनी के हैक होने का एकमात्र कारण बन जाता है। विशेषकर कैपिटल वन जितना बड़ा।

तो, अंदर हैकर - आगे क्या हुआ?

खैर, EC2 उदाहरण में सेंध लगाने के बाद... बहुत कुछ गलत हो सकता है। यदि आप किसी को इतनी दूर जाने देते हैं तो आप व्यावहारिक रूप से चाकू की धार पर चल रहे हैं। लेकिन यह S3 बाल्टियों में कैसे आया? इसे समझने के लिए आइए IAM भूमिकाओं पर चर्चा करें।

तो, AWS सेवाओं तक पहुँचने का एक तरीका उपयोगकर्ता बनना है। ठीक है, यह बिल्कुल स्पष्ट है। लेकिन क्या होगा यदि आप अन्य AWS सेवाएँ, जैसे कि आपके एप्लिकेशन सर्वर, को अपने S3 बकेट तक पहुँच देना चाहते हैं? IAM भूमिकाएँ इसी के लिए हैं। इनमें दो घटक शामिल हैं:

1. विश्वास नीति - कौन सी सेवाएँ या लोग इस भूमिका का उपयोग कर सकते हैं?
2. अनुमति नीति - यह भूमिका किस चीज़ की अनुमति देती है?

उदाहरण के लिए, आप एक IAM भूमिका बनाना चाहते हैं जो EC2 इंस्टेंसेस को S3 बकेट तक पहुंचने की अनुमति देगी: सबसे पहले, भूमिका में एक ट्रस्ट नीति निर्धारित की जाती है कि EC2 (संपूर्ण सेवा) या विशिष्ट इंस्टेंसेस भूमिका को "कब्जा" कर सकते हैं। किसी भूमिका को स्वीकार करने का अर्थ है कि वे कार्य करने के लिए भूमिका की अनुमतियों का उपयोग कर सकते हैं। दूसरे, अनुमति नीति उस सेवा/व्यक्ति/संसाधन को अनुमति देती है जिसने S3 पर कुछ भी करने के लिए "भूमिका निभाई है", चाहे वह एक विशिष्ट बकेट तक पहुंच हो... या 700 से अधिक, जैसा कि कैपिटल वन के मामले में है।

एक बार जब आप IAM भूमिका के साथ EC2 उदाहरण में होते हैं, तो आप कई तरीकों से क्रेडेंशियल प्राप्त कर सकते हैं:

1. आप यहां इंस्टेंस मेटाडेटा का अनुरोध कर सकते हैं http://169.254.169.254/latest/meta-data

   अन्य बातों के अलावा, आप इस पते पर किसी भी एक्सेस कुंजी के साथ IAM भूमिका पा सकते हैं। बेशक, केवल तभी जब आप किसी उदाहरण में हों।

2. एडब्ल्यूएस सीएलआई का प्रयोग करें...

   यदि AWS CLI स्थापित है, तो इसे IAM भूमिकाओं से क्रेडेंशियल्स के साथ लोड किया जाता है, यदि मौजूद हो। जो कुछ बचा है वह उदाहरण के माध्यम से काम करना है। निःसंदेह, यदि उनकी विश्वास नीति खुली होती, तो पेज सीधे सब कुछ कर सकता था।

तो IAM भूमिकाओं का सार यह है कि वे कुछ संसाधनों को आपकी ओर से अन्य संसाधनों पर कार्य करने की अनुमति देते हैं।

अब जब आप IAM की भूमिकाएँ समझ गए हैं, तो हम इस बारे में बात कर सकते हैं कि पेज थॉम्पसन ने क्या किया:

1. उसने फ़ायरवॉल में एक छेद के माध्यम से सर्वर (EC2 उदाहरण) तक पहुंच प्राप्त की

   चाहे वह सुरक्षा समूह/एसीएल हों या उनके स्वयं के वेब एप्लिकेशन फ़ायरवॉल, छेद को प्लग करना संभवतः काफी आसान था, जैसा कि आधिकारिक रिकॉर्ड में कहा गया है।

2. एक बार सर्वर पर आने के बाद, वह ऐसा व्यवहार करने में सक्षम हो गई जैसे कि वह स्वयं सर्वर हो
3. चूंकि IAM सर्वर भूमिका ने S3 को इन 700+ बकेट तक पहुंच की अनुमति दी, इसलिए यह उन तक पहुंचने में सक्षम था

उस क्षण से, उसे बस कमांड चलाना था List Bucketsऔर फिर आदेश Sync एडब्ल्यूएस सीएलआई से...

कैपिटल वन बैंक का अनुमान है कि हैक से $100 से $150 मिलियन के बीच नुकसान होगा. इस तरह की क्षति को रोकने के लिए कंपनियां क्लाउड इंफ्रास्ट्रक्चर सुरक्षा, DevOps और सुरक्षा विशेषज्ञों में इतना निवेश करती हैं। और क्लाउड पर जाना कितना मूल्यवान और लागत प्रभावी है? इतना कि अधिक से अधिक साइबर सुरक्षा चुनौतियों का सामना करने पर भी 42 की पहली तिमाही में समग्र सार्वजनिक क्लाउड बाज़ार में 2019% की वृद्धि हुई!

कहानी का नैतिक: अपनी सुरक्षा की जाँच करें; नियमित लेखापरीक्षा करें; सुरक्षा नीतियों के लिए न्यूनतम विशेषाधिकार के सिद्धांत का सम्मान करें।

(यहां आप पूरी कानूनी रिपोर्ट देख सकते हैं)।

स्रोत: www.habr.com