🥇AWS पर कैपिटल वन बैंक हैक की तकनीकी जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ट्रस्ट नीति - कौन सी सेवाएं या लोग इस भूमिका का उपयोग कर सकते हैं?
अनुमति नीति - यह भूमिका क्या अनुमति देती है?

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

एक बार जब आप IAM भूमिका के साथ EC2 इंस्टेंस पर होते हैं, तो आप कुछ तरीकों से क्रेडेंशियल प्राप्त कर सकते हैं:

आप इंस्टेंस मेटाडेटा का अनुरोध यहां कर सकते हैं http://169.254.169.254/latest/meta-data
अन्य बातों के अलावा, आप इस पते पर किसी भी एक्सेस कुंजी के साथ IAM भूमिका पा सकते हैं। बेशक, केवल तभी जब आप इंस्टेंस में हों।
AWS CLI का उपयोग करें…
यदि AWS CLI स्थापित है, तो यह IAM भूमिकाओं से क्रेडेंशियल के साथ बूट होता है यदि मौजूद है। बस इतना ही बचा है कि इंस्टेंस के माध्यम से काम करना है। बेशक, अगर उनकी ट्रस्ट पॉलिसी सार्वजनिक थी, तो पैगी सीधे ऐसा कर सकती थी।

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

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

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

उस क्षण से, उसे बस आदेश चलाना था। List Buckets, और फिर आदेश Sync AWS CLI से…

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

कहानी की सीख: अपनी सुरक्षा का परीक्षण करें; नियमित रूप से ऑडिट करें; सुरक्षा नीतियों के लिए न्यूनतम विशेषाधिकार के सिद्धांत का सम्मान करें।

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

स्रोत: www.habr.com