AWS मा क्यापिटल वन बैंक ह्याकको प्राविधिक विवरण

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

दुर्भाग्यवश, ह्याक जुलाई १९ मा भएन। यो बाहिर जान्छ, Paige Thompson, a.k.a. अनियमित, मार्च 22 र मार्च 23, 2019 बीच यो प्रतिबद्ध छ। त्यो हो लगभग चार महिना अघि। वास्तवमा, यो बाहिरी सल्लाहकारहरूको सहयोगमा मात्र थियो कि क्यापिटल वनले पत्ता लगाउन सक्षम भयो कि केहि भयो।

अमेजनका एक पूर्व कर्मचारीलाई गिरफ्तार गरियो र $250 जरिवाना र पाँच वर्षको जेल सजाय भोग्नुपर्नेछ... तर त्यहाँ अझै धेरै नकारात्मकता बाँकी छ। किन? किनभने ह्याकबाट पीडित धेरै कम्पनीहरूले साइबर अपराधको बृद्धिको बीचमा आफ्नो पूर्वाधार र अनुप्रयोगहरूलाई सुदृढ गर्ने जिम्मेवारीबाट पन्छिन खोजिरहेका छन्।

जे भए पनि, तपाईं सजिलैसँग यो कथा गुगल गर्न सक्नुहुन्छ। हामी नाटकमा जाँदैनौं, तर कुरा गर्छौं प्राविधिक कुरा को पक्ष।

सबैभन्दा पहिले, के भयो?

क्यापिटल वनमा लगभग 700 S3 बाल्टिनहरू चलिरहेका थिए, जसलाई Paige Thompson ले नक्कल गरेर सिफन गरे।

दोस्रो, के यो गलत कन्फिगर गरिएको S3 बाल्टिन नीतिको अर्को केस हो?

होइन, यस पटक होइन। यहाँ उनले गलत तरिकाले कन्फिगर गरिएको फायरवालको साथ सर्भरमा पहुँच प्राप्त गरिन् र त्यहाँबाट सम्पूर्ण कार्य सञ्चालन गरिन्।

पर्खनुहोस्, यो कसरी सम्भव छ?

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

स्टोनले भने कि क्यापिटल वनले सुरुमा फायरवाल जोखिमलाई याद गरेन तर यो थाहा पाएपछि छिट्टै काम गर्यो। यो निश्चित रूपमा यस तथ्यले मद्दत गरेको थियो कि ह्याकरले कथित रूपमा सार्वजनिक डोमेनमा मुख्य पहिचान जानकारी छोडेको थियो, स्टोनले भने।

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

त्यसोभए पहिलो टेकअवे हो: जान्नुहोस् तपाईको फायरवालहरूले के अनुमति दिन्छ।

खोल्नु पर्ने कुरा मात्रै खोलिएको छ भनी सुनिश्चित गर्न नीति वा उचित प्रक्रिया स्थापना गर्नुहोस्। यदि तपाइँ AWS स्रोतहरू जस्तै सुरक्षा समूह वा नेटवर्क ACLs प्रयोग गर्दै हुनुहुन्छ भने, स्पष्ट रूपमा अडिट गर्नको लागि चेकलिस्ट लामो हुन सक्छ ... तर जस्तै धेरै स्रोतहरू स्वचालित रूपमा सिर्जना हुन्छन् (जस्तै CloudFormation), तिनीहरूको अडिटिङ स्वचालित गर्न पनि सम्भव छ। चाहे यो घरेलु स्क्रिप्ट हो जसले त्रुटिहरूको लागि नयाँ वस्तुहरू स्क्यान गर्दछ, वा CI/CD प्रक्रियामा सुरक्षा अडिट जस्ता केहि... यसबाट बच्न धेरै सजिलो विकल्पहरू छन्।

कथाको "रमाइलो" भाग यो हो कि यदि क्यापिटल वनले पहिलो स्थानमा प्वाल प्लग गरेको भए ... केहि हुने थिएन। र त्यसोभए, स्पष्ट रूपमा, यो सँधै स्तब्ध हुन्छ कि कसरी केहि साँच्चै धेरै सरल कम्पनी ह्याक हुनुको एक मात्र कारण बन्छ। विशेष गरी क्यापिटल वन जत्तिकै ठूलो।

त्यसोभए, ह्याकर भित्र - त्यसपछि के भयो?

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

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

1. विश्वास नीति - कुन सेवाहरू वा मानिसहरूले यो भूमिका प्रयोग गर्न सक्छन्?
2. अनुमति नीति - यो भूमिकाले के अनुमति दिन्छ?

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

एक पटक तपाईं IAM भूमिकाको साथ EC2 उदाहरणमा हुनुहुन्छ, तपाईंले धेरै तरिकामा प्रमाणहरू प्राप्त गर्न सक्नुहुन्छ:

1. तपाईं मा उदाहरण मेटाडेटा अनुरोध गर्न सक्नुहुन्छ http://169.254.169.254/latest/meta-data

   अन्य चीजहरू मध्ये, तपाईंले यो ठेगानामा पहुँच कुञ्जीहरू मध्ये कुनै पनि IAM भूमिका फेला पार्न सक्नुहुन्छ। अवश्य पनि, यदि तपाईं एक उदाहरणमा हुनुहुन्छ भने।

2. AWS CLI प्रयोग गर्नुहोस्...

   यदि AWS CLI स्थापना गरिएको छ भने, यदि अवस्थित छ भने, यो IAM भूमिकाहरूबाट प्रमाणहरू भरिन्छ। सबै बाँकी छ उदाहरण मार्फत काम गर्न। निस्सन्देह, यदि तिनीहरूको विश्वास नीति खुला थियो भने, Paige प्रत्यक्ष रूपमा सबै गर्न सक्थे।

त्यसैले IAM भूमिकाहरूको सार यो हो कि तिनीहरूले केही स्रोतहरूलाई अन्य स्रोतहरूमा तपाईंको तर्फबाट कार्य गर्न अनुमति दिन्छ।

अब तपाईंले IAM को भूमिकाहरू बुझ्नुभएको छ, हामी Paige Thompson ले के गर्नुभयो भन्ने बारे कुरा गर्न सक्छौं:

1. उनले फायरवालको प्वालबाट सर्भर (EC2 उदाहरण) मा पहुँच प्राप्त गरिन्

   चाहे यो सुरक्षा समूहहरू/ACL हरू वा तिनीहरूको आफ्नै वेब अनुप्रयोग फायरवालहरू थिए, आधिकारिक रेकर्डहरूमा भनिए अनुसार, प्वाल प्लग गर्न धेरै सजिलो थियो।

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

त्यस क्षणदेखि, उनले गर्नुपर्ने भनेको कमाण्ड चलाउनु थियो List Bucketsर त्यसपछि आदेश Sync AWS CLI बाट...

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

कथाको नैतिकता: आफ्नो सुरक्षा जाँच गर्नुहोस्; नियमित अडिटहरू सञ्चालन गर्नुहोस्; सुरक्षा नीतिहरूको लागि न्यूनतम विशेषाधिकारको सिद्धान्तको सम्मान गर्नुहोस्।

(यो छ तपाईं पूर्ण कानूनी रिपोर्ट हेर्न सक्नुहुन्छ)।

स्रोत: www.habr.com