AWS वर कॅपिटल वन हॅकचे तांत्रिक तपशील

19 जुलै 2019 रोजी, कॅपिटल वनला संदेश प्राप्त झाला की प्रत्येक आधुनिक कंपनीला भीती वाटते—डेटा भंग झाला. याचा 106 दशलक्षाहून अधिक लोकांवर परिणाम झाला. 140 यूएस सामाजिक सुरक्षा क्रमांक, एक दशलक्ष कॅनेडियन सामाजिक सुरक्षा क्रमांक. 000 बँक खाती. अप्रिय, आपण सहमत नाही?

दुर्दैवाने, 19 जुलै रोजी हॅक झाला नाही. असे दिसून आले की, Paige Thompson, a.k.a. अनियमित, 22 मार्च ते 23 मार्च 2019 दरम्यान वचनबद्ध केले. ते आहे जवळपास चार महिन्यांपूर्वी. खरं तर, बाहेरील सल्लागारांच्या मदतीनेच कॅपिटल वनला काहीतरी घडले आहे हे कळू शकले.

अॅमेझॉनच्या एका माजी कर्मचाऱ्याला अटक करण्यात आली आणि त्याला $250 दंड आणि पाच वर्षांचा तुरुंगवास भोगावा लागला... पण अजूनही बरीच नकारात्मकता बाकी आहे. का? कारण हॅकचा त्रास झालेल्या अनेक कंपन्या सायबर गुन्ह्यांमध्ये वाढ होत असताना त्यांच्या पायाभूत सुविधा आणि ऍप्लिकेशन्स मजबूत करण्याच्या जबाबदारीपासून दूर जाण्याचा प्रयत्न करत आहेत.

असो, तुम्ही ही कथा सहज गुगल करू शकता. आम्ही नाटकात जाणार नाही, पण चर्चा करणार आहोत तांत्रिक प्रकरणाची बाजू.

सर्व प्रथम, काय झाले?

कॅपिटल वनमध्ये सुमारे 700 S3 बादल्या चालू होत्या, ज्या Paige Thompson ने कॉपी केल्या आणि काढून टाकल्या.

दुसरे म्हणजे, हे चुकीचे कॉन्फिगर केलेल्या S3 बकेट पॉलिसीचे दुसरे प्रकरण आहे का?

नाही, यावेळी नाही. येथे तिने चुकीच्या कॉन्फिगर केलेल्या फायरवॉलसह सर्व्हरवर प्रवेश मिळवला आणि तिथून संपूर्ण ऑपरेशन केले.

थांबा, हे कसे शक्य आहे?

बरं, सर्व्हरमध्ये लॉग इन करून सुरुवात करूया, जरी आमच्याकडे बरेच तपशील नाहीत. आम्हाला फक्त असे सांगण्यात आले की हे "चुकीचे कॉन्फिगर केलेल्या फायरवॉल" द्वारे झाले आहे. तर, वेब ऍप्लिकेशन फायरवॉल (Imperva), किंवा नेटवर्क फायरवॉल (iptables, ufw, shorewall, इ.) च्या चुकीच्या सुरक्षा गट सेटिंग्ज किंवा कॉन्फिगरेशनसारखे काहीतरी सोपे आहे. कॅपिटल वनने फक्त त्याचा अपराध कबूल केला आणि सांगितले की त्याने छिद्र बंद केले आहे.

स्टोन म्हणाले की, कॅपिटल वनला सुरुवातीला फायरवॉल असुरक्षितता लक्षात आली नाही परंतु एकदा ते लक्षात आल्यानंतर त्वरीत कार्य केले. स्टोन म्हणाले की, हॅकरने कथितपणे मुख्य ओळख माहिती सार्वजनिक डोमेनमध्ये सोडली या वस्तुस्थितीमुळे नक्कीच मदत झाली.

आम्ही या भागात खोलवर का जात नाही असा प्रश्न तुम्हाला पडत असेल, तर कृपया समजून घ्या की मर्यादित माहितीमुळे आम्ही फक्त अंदाज लावू शकतो. हॅक कॅपिटल वन द्वारे सोडलेल्या छिद्रावर अवलंबून आहे हे लक्षात घेता याचा अर्थ नाही. आणि जोपर्यंत ते आम्हाला अधिक सांगत नाहीत तोपर्यंत, आम्ही फक्त कॅपिटल वनने त्यांचे सर्व्हर उघडे ठेवलेल्या सर्व संभाव्य मार्गांची यादी करू ज्यात कोणीतरी या भिन्न पर्यायांपैकी एक वापरू शकतो. या त्रुटी आणि तंत्रे अत्यंत मूर्खपणापासून ते आश्चर्यकारकपणे जटिल नमुन्यांपर्यंत असू शकतात. शक्यतांची श्रेणी पाहता, वास्तविक निष्कर्षाशिवाय ही एक दीर्घ गाथा होईल. म्हणून, ज्या भागामध्ये तथ्य आहे त्या भागाचे विश्लेषण करण्यावर लक्ष केंद्रित करूया.

तर पहिला टेकअवे आहे: तुमचे फायरवॉल काय परवानगी देतात ते जाणून घ्या.

फक्त जे उघडायचे आहे तेच उघडले जाईल याची खात्री करण्यासाठी धोरण किंवा योग्य प्रक्रिया स्थापित करा. जर तुम्ही सुरक्षा गट किंवा नेटवर्क ACL सारखी AWS संसाधने वापरत असाल, तर ऑडिटसाठी चेकलिस्ट मोठी असू शकते... पण जसे अनेक संसाधने आपोआप तयार होतात (म्हणजे क्लाउडफॉर्मेशन), त्यांचे ऑडिटिंग स्वयंचलित करणे देखील शक्य आहे. दोषांसाठी नवीन वस्तू स्कॅन करणारी होममेड स्क्रिप्ट असो, किंवा सीआय/सीडी प्रक्रियेतील सिक्युरिटी ऑडिटसारखे काहीतरी... हे टाळण्यासाठी बरेच सोपे पर्याय आहेत.

कथेचा "मजेदार" भाग असा आहे की जर कॅपिटल वनने आधी छिद्र पाडले असते... तर काहीही झाले नसते. आणि म्हणून, स्पष्टपणे, काहीतरी खरोखर कसे आहे हे पाहणे नेहमीच धक्कादायक असते खूपच सोपे कंपनी हॅक होण्याचे एकमेव कारण बनते. विशेषत: कॅपिटल वन एवढा मोठा.

तर, आत हॅकर - पुढे काय झाले?

बरं, 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 वापरा...

   जर 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