MCS क्लाउड प्लेटफर्मको सुरक्षा अडिट

स्काईशिप साँझ सीरलाइट द्वारा

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

यो लेख Mail.ru Cloud Solutions (MCS) टोलीलाई क्लाउड सेवाको परीक्षण गर्न मद्दत गर्ने बाह्य विशेषज्ञहरूको सबैभन्दा सीधा दृष्टिकोण र तिनीहरूले के फेला पारे भन्ने बारे हो। "बाह्य शक्ति" को रूपमा, MCS ले डिजिटल सुरक्षा कम्पनी छनोट गर्यो, सूचना सुरक्षा सर्कलहरूमा यसको उच्च विशेषज्ञताको लागि परिचित। र यस लेखमा हामी बाह्य लेखापरीक्षणको भागको रूपमा फेला परेका केही रोचक कमजोरीहरूको विश्लेषण गर्नेछौं - ताकि तपाईंले आफ्नै क्लाउड सेवा सिर्जना गर्दा उही रेकबाट बच्न सक्नुहुन्छ।

Описание продукта

Mail.ru क्लाउड समाधान (MCS) क्लाउडमा भर्चुअल पूर्वाधार निर्माण गर्ने प्लेटफर्म हो। यसमा IaaS, PaaS, र विकासकर्ताहरूका लागि तयार-निर्मित अनुप्रयोग छविहरूको बजार समावेश छ। MCS वास्तुकलालाई ध्यानमा राख्दै, निम्न क्षेत्रहरूमा उत्पादनको सुरक्षा जाँच गर्न आवश्यक थियो:

• भर्चुअलाइजेशन वातावरणको पूर्वाधारको सुरक्षा गर्दै: हाइपरभाइजर, रूटिङ, फायरवालहरू;
• ग्राहकहरूको भर्चुअल पूर्वाधारको सुरक्षा: एकअर्काबाट अलगाव, नेटवर्क सहित, SDN मा निजी नेटवर्कहरू;
• OpenStack र यसको खुला कम्पोनेन्टहरू;
• हाम्रो आफ्नै डिजाइनको S3;
• IAM: रोल मोडेलका साथ बहु-भाडामा लिने परियोजनाहरू;
• दृष्टि (कम्प्युटर दृष्टि): छविहरूसँग काम गर्दा API र कमजोरीहरू;
• वेब इन्टरफेस र क्लासिक वेब आक्रमणहरू;
• PaaS घटकहरूको कमजोरीहरू;
• सबै कम्पोनेन्टहरूको API।

सायद यो सबै अर्को इतिहासको लागि आवश्यक छ।

कस्तो प्रकारको काम गरिएको थियो र यो किन आवश्यक थियो?

सुरक्षा अडिटको उद्देश्य कमजोरीहरू र कन्फिगरेसन त्रुटिहरू पहिचान गर्ने उद्देश्यले हो जसले व्यक्तिगत डेटाको चुहावट, संवेदनशील जानकारीको परिमार्जन, वा सेवा उपलब्धतामा अवरोध ल्याउन सक्छ।

कामको क्रममा, जुन औसत 1-2 महिनासम्म रहन्छ, लेखा परीक्षकहरूले सम्भावित आक्रमणकारीहरूको कार्यहरू दोहोर्याउँछन् र ग्राहक र चयन गरिएको सेवाको सर्भर भागहरूमा कमजोरीहरू खोज्छन्। MCS क्लाउड प्लेटफर्मको अडिटको सन्दर्भमा, निम्न लक्ष्यहरू पहिचान गरिएको थियो:

1. सेवामा प्रमाणीकरणको विश्लेषण। यस कम्पोनेन्टमा भएका कमजोरीहरूले तुरुन्तै अन्य व्यक्तिहरूको खाताहरूमा जान मद्दत गर्नेछ।
2. रोल मोडेल अध्ययन गर्दै र विभिन्न खाताहरू बीच पहुँच नियन्त्रण। आक्रमणकारीको लागि, अरू कसैको भर्चुअल मेसिनमा पहुँच प्राप्त गर्ने क्षमता एक वांछनीय लक्ष्य हो।
3. ग्राहक पक्ष कमजोरीहरू। XSS/CSRF/CRLF/etc के यो दुर्भावनापूर्ण लिङ्कहरू मार्फत अन्य प्रयोगकर्ताहरूलाई आक्रमण गर्न सम्भव छ?
4. सर्भर साइड कमजोरीहरू: RCE र सबै प्रकारका इंजेक्शनहरू (SQL/XXE/SSRF र यस्तै)। सर्भर कमजोरीहरू सामान्यतया फेला पार्न गाह्रो हुन्छ, तर तिनीहरूले एकैचोटि धेरै प्रयोगकर्ताहरूको सम्झौताको नेतृत्व गर्छन्।
5. नेटवर्क स्तरमा प्रयोगकर्ता खण्ड अलगाव को विश्लेषण। आक्रमणकारीको लागि, अलगावको कमीले अन्य प्रयोगकर्ताहरू विरुद्ध आक्रमणको सतहलाई धेरै बढाउँछ।
6. व्यापार तर्क विश्लेषण। के यो व्यवसायहरूलाई धोका दिन र नि: शुल्क भर्चुअल मेसिनहरू सिर्जना गर्न सम्भव छ?

यस परियोजनामा, "ग्रे-बक्स" मोडेल अनुसार काम गरिएको थियो: लेखा परीक्षकहरूले साधारण प्रयोगकर्ताहरूको विशेषाधिकारको साथ सेवासँग अन्तरक्रिया गरे, तर आंशिक रूपमा API को स्रोत कोड राखे र विकासकर्ताहरूसँग विवरणहरू स्पष्ट गर्ने अवसर थियो। यो सामान्यतया सबै भन्दा सुविधाजनक छ, र एकै समयमा काम को एकदम यथार्थवादी मोडेल: आन्तरिक जानकारी अझै पनि एक आक्रमणकारी द्वारा सङ्कलन गर्न सकिन्छ, यो केवल समय को कुरा हो।

कमजोरीहरू फेला पर्यो

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

शंकास्पद देखिने वा कुनै न कुनै तरिकाले अरूभन्दा धेरै फरक ठाउँहरू फेला पार्नु महत्त्वपूर्ण छ। र पहिलो खतरनाक जोखिम यस तरिकामा फेला पर्यो।

IDOR

IDOR (असुरक्षित प्रत्यक्ष वस्तु सन्दर्भ) जोखिमहरू व्यापार तर्कमा सबैभन्दा सामान्य कमजोरीहरू मध्ये एक हो, जसले एक वा अर्कोलाई वस्तुहरूमा पहुँच प्राप्त गर्न अनुमति दिन्छ जसमा पहुँच वास्तवमा अनुमति छैन। IDOR कमजोरीहरूले आलोचनात्मकताको फरक डिग्रीको प्रयोगकर्ताको बारेमा जानकारी प्राप्त गर्ने सम्भावना सिर्जना गर्दछ।

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

MCS को मामलामा, लेखा परीक्षकहरूले भर्खरै गैर-सुरक्षित पहिचानकर्ताहरूसँग सम्बन्धित IDOR जोखिम पत्ता लगाए। प्रयोगकर्ताको व्यक्तिगत खातामा, UUID पहिचानकर्ताहरू कुनै पनि वस्तुहरू पहुँच गर्न प्रयोग गरिन्थ्यो, जुन सुरक्षा विशेषज्ञहरूले भनेझैं प्रभावकारी रूपमा असुरक्षित (अर्थात, क्रूर बल आक्रमणबाट सुरक्षित) जस्तो देखिन्थ्यो। तर केहि संस्थाहरु को लागी, यो पत्ता लाग्यो कि नियमित अनुमानित संख्याहरु को लागी अनुप्रयोग को प्रयोगकर्ताहरु को बारे मा जानकारी प्राप्त गर्न को लागी प्रयोग गरिन्छ। मलाई लाग्छ कि तपाइँ अनुमान गर्न सक्नुहुन्छ कि यो एक द्वारा प्रयोगकर्ता आईडी परिवर्तन गर्न सम्भव थियो, पुन: अनुरोध पठाउनुहोस् र यसरी ACL (पहुँच नियन्त्रण सूची, प्रक्रियाहरू र प्रयोगकर्ताहरूको लागि डेटा पहुँच नियमहरू) लाई बाइपास गरेर जानकारी प्राप्त गर्नुहोस्।

सर्भर साइड रिक्वेस्ट फोर्जरी (SSRF)

OpenSource उत्पादनहरूको बारेमा राम्रो कुरा यो हो कि तिनीहरूसँग उत्पन्न हुने समस्याहरूको विस्तृत प्राविधिक विवरणहरूको साथ ठूलो संख्यामा फोरमहरू छन् र, यदि तपाईं भाग्यशाली हुनुहुन्छ भने, समाधानको विवरण। तर यो सिक्का एक फ्लिप पक्ष छ: ज्ञात कमजोरीहरू पनि विस्तारमा वर्णन गरिएको छ। उदाहरणका लागि, OpenStack फोरममा कमजोरीहरूको अद्भुत विवरणहरू छन् [XSS] и [SSRF], जुन कुनै कारणले कोही पनि ठीक गर्न हतारमा छैन।

अनुप्रयोगहरूको सामान्य कार्यक्षमता भनेको प्रयोगकर्ताको लागि सर्भरमा लिङ्क पठाउने क्षमता हो, जुन सर्भरले क्लिक गर्दछ (उदाहरणका लागि, निर्दिष्ट स्रोतबाट छवि डाउनलोड गर्न)। यदि सुरक्षा उपकरणहरूले लिङ्कहरू आफैं फिल्टर गर्दैनन् वा सर्भरबाट प्रयोगकर्ताहरूलाई फर्काइएका प्रतिक्रियाहरू, यस्तो प्रकार्यता सजिलै आक्रमणकारीहरूद्वारा प्रयोग गर्न सकिन्छ।

SSRF कमजोरीहरूले आक्रमणको विकासलाई धेरै अगाडि बढाउन सक्छ। एक आक्रमणकारीले प्राप्त गर्न सक्छ:

• आक्रमण गरिएको स्थानीय नेटवर्कमा सीमित पहुँच, उदाहरणका लागि, केवल निश्चित नेटवर्क खण्डहरू र निश्चित प्रोटोकल प्रयोग गरेर;
• स्थानीय नेटवर्कमा पूर्ण पहुँच, यदि अनुप्रयोग स्तरबाट यातायात स्तरमा डाउनग्रेड गर्न सम्भव छ र, परिणाम स्वरूप, अनुप्रयोग स्तरमा पूर्ण लोड व्यवस्थापन;
• सर्भरमा स्थानीय फाइलहरू पढ्न पहुँच (यदि फाइल:/// योजना समर्थित छ);
• र धेरै बढी।

ओपनस्ट्याकमा एक SSRF कमजोरी लामो समयदेखि ज्ञात छ, जुन प्रकृतिमा "अन्धो" हो: जब तपाइँ सर्भरलाई सम्पर्क गर्नुहुन्छ, तपाइँ त्यसबाट प्रतिक्रिया प्राप्त गर्नुहुन्न, तर तपाइँले अनुरोधको परिणाममा निर्भर गर्दै, विभिन्न प्रकारका त्रुटिहरू/ढिलाइहरू प्राप्त गर्नुहुन्छ। । यसको आधारमा, तपाइँ आन्तरिक सञ्जालमा होस्टहरूमा पोर्ट स्क्यान गर्न सक्नुहुन्छ, सबै आगामी परिणामहरू जसलाई कम आँकलन गर्नु हुँदैन। उदाहरणका लागि, एउटा उत्पादनसँग ब्याक-अफिस API हुन सक्छ जुन कर्पोरेट नेटवर्कबाट मात्र पहुँचयोग्य हुन्छ। कागजातको साथ (अन्तरको बारेमा नबिर्सनुहोस्), एक आक्रमणकारीले आन्तरिक विधिहरू पहुँच गर्न SSRF प्रयोग गर्न सक्छ। उदाहरणका लागि, यदि तपाइँ कुनै पनि तरिकाले उपयोगी URL को अनुमानित सूची प्राप्त गर्न सक्षम हुनुभयो भने, त्यसपछि SSRF प्रयोग गरेर तपाइँ ती मार्फत जान सक्नुहुन्छ र अनुरोध कार्यान्वयन गर्न सक्नुहुन्छ - तुलनात्मक रूपमा भन्नुपर्दा, खाताबाट खातामा पैसा स्थानान्तरण गर्न वा सीमाहरू परिवर्तन गर्न सक्नुहुन्छ।

OpenStack मा SSRF को कमजोरी पत्ता लागेको यो पहिलो पटक होइन। विगतमा, प्रत्यक्ष लिङ्कबाट VM ISO छविहरू डाउनलोड गर्न सम्भव थियो, जसले समान परिणामहरू निम्त्यायो। यो सुविधा अब OpenStack बाट हटाइएको छ। स्पष्ट रूपमा, समुदायले यसलाई समस्याको सबैभन्दा सरल र भरपर्दो समाधान मानेको छ।

र भित्र यो HackerOne सेवा (h1) बाट सार्वजनिक रूपमा उपलब्ध रिपोर्ट, उदाहरण मेटाडेटा पढ्न सक्ने क्षमताको साथ अब अन्धा नभएको SSRF को शोषणले सम्पूर्ण Shopify पूर्वाधारमा रूट पहुँचमा पुर्‍याउँछ।

MCS मा, SSRF कमजोरीहरू समान प्रकार्यका साथ दुई ठाउँमा फेला परेका थिए, तर फायरवाल र अन्य सुरक्षाका कारण तिनीहरूको शोषण गर्न लगभग असम्भव थियो। कुनै न कुनै तरिकाले, MCS टोलीले समुदायको प्रतीक्षा नगरी यस समस्यालाई जसरी पनि समाधान गर्यो।

शेलहरू लोड गर्नुको सट्टा XSS

लेखिएका सयौं अध्ययनहरूको बावजुद, वर्ष पछि XSS (क्रस-साइट स्क्रिप्टिङ) आक्रमण अझै पनि सबैभन्दा बढी छ बारम्बार सामना वेब भेद्यता (वा आक्रमण?)।

फाइल अपलोड कुनै पनि सुरक्षा अनुसन्धानकर्ताको लागि मनपर्ने ठाउँ हो। यो अक्सर बाहिर जान्छ कि तपाइँ एक मनमानी स्क्रिप्ट लोड गर्न सक्नुहुन्छ (asp/jsp/php) र ओएस आदेशहरू कार्यान्वयन गर्न सक्नुहुन्छ, पेन्टेस्टर्सको शब्दावलीमा - "लोड शेल"। तर त्यस्ता कमजोरीहरूको लोकप्रियता दुवै दिशामा काम गर्दछ: मानिसहरूले तिनीहरूको बारेमा सम्झन्छन् र तिनीहरूको विरुद्ध उपचारहरू विकास गर्छन्, ताकि हालै "शेल लोड" को सम्भावना शून्य हुन्छ।

आक्रमणकारी टोली (डिजिटल सुरक्षा द्वारा प्रतिनिधित्व) भाग्यशाली थियो। ठीक छ, MCS मा सर्भर साइडमा डाउनलोड गरिएका फाइलहरूको सामग्रीहरू जाँच गरियो, केवल छविहरूलाई अनुमति दिइयो। तर SVG पनि तस्विर हो। SVG छविहरू कसरी खतरनाक हुन सक्छ? किनकी तपाइँ तिनीहरूलाई जाभास्क्रिप्ट स्निपेटहरू इम्बेड गर्न सक्नुहुन्छ!

यो पत्ता लाग्यो कि डाउनलोड गरिएका फाइलहरू MCS सेवाका सबै प्रयोगकर्ताहरूका लागि उपलब्ध छन्, जसको अर्थ अन्य क्लाउड प्रयोगकर्ताहरू, अर्थात् प्रशासकहरूलाई आक्रमण गर्न सम्भव छ।

फिसिङ लगइन फारममा XSS आक्रमणको उदाहरण

XSS आक्रमण शोषणका उदाहरणहरू:

• किन सत्र चोर्ने प्रयास गर्ने (विशेष गरी अहिले HTTP-मात्र कुकीहरू जताततै छन्, js स्क्रिप्टहरू प्रयोग गरेर चोरीबाट सुरक्षित छन्), यदि लोड गरिएको स्क्रिप्टले तुरुन्तै स्रोत API पहुँच गर्न सक्छ? यस अवस्थामा, पेलोडले सर्भर कन्फिगरेसन परिवर्तन गर्न XHR अनुरोधहरू प्रयोग गर्न सक्छ, उदाहरणका लागि, आक्रमणकर्ताको सार्वजनिक SSH कुञ्जी थप्नुहोस् र सर्भरमा SSH पहुँच प्राप्त गर्नुहोस्।
• यदि CSP नीति (सामग्री सुरक्षा नीति) ले JavaScript लाई इन्जेक्सन हुनबाट रोक्छ भने, आक्रमणकारीले यसलाई बिना नै जान सक्छ। शुद्ध HTML प्रयोग गरेर, साइटको लागि नक्कली लगइन फारम सिर्जना गर्नुहोस् र यस उन्नत फिसिङ मार्फत प्रशासकको पासवर्ड चोर्नुहोस्: प्रयोगकर्ताको लागि फिसिङ पृष्ठ उही URL मा समाप्त हुन्छ, र प्रयोगकर्तालाई यो पत्ता लगाउन अझ गाह्रो हुन्छ।
• अन्तमा, आक्रमणकारीले व्यवस्था गर्न सक्छ ग्राहक DoS - 4 KB भन्दा ठूलो कुकीहरू सेट गर्नुहोस्। प्रयोगकर्ताले केवल एक पटक लिङ्क खोल्न आवश्यक छ, र प्रयोगकर्ताले ब्राउजरलाई विशेष रूपमा सफा गर्ने सोच नगरेसम्म सम्पूर्ण साइट पहुँचयोग्य हुन्छ: धेरै जसो केसहरूमा, वेब सर्भरले त्यस्तो ग्राहकलाई स्वीकार गर्न अस्वीकार गर्नेछ।

अर्को पत्ता लगाइएको XSS को उदाहरण हेरौं, यस पटक थप चलाख शोषणको साथ। MCS सेवाले तपाईंलाई समूहहरूमा फायरवाल सेटिङहरू संयोजन गर्न अनुमति दिन्छ। समूह नाम जहाँ XSS पत्ता लगाइएको थियो। यसको विशेषता यो थियो कि भेक्टर तुरुन्तै ट्रिगर गरिएको थिएन, नियमहरूको सूची हेर्दा होइन, तर समूह मेटाउँदा:

त्यो हो, परिदृश्य निम्न बन्यो: एक आक्रमणकर्ताले नाममा "लोड" को साथ फायरवाल नियम सिर्जना गर्दछ, प्रशासकले केहि समय पछि यसलाई नोटिस गर्छ र मेटाउने प्रक्रिया प्रारम्भ गर्दछ। र यो जहाँ दुर्भावनापूर्ण JS काम गर्दछ।

MCS विकासकर्ताहरूका लागि, डाउनलोड गरिएका SVG छविहरूमा XSS विरुद्ध सुरक्षा गर्न (यदि तिनीहरू छोड्न सकिँदैन), डिजिटल सुरक्षा टोलीले सिफारिस गर्यो:

• प्रयोगकर्ताहरूद्वारा अपलोड गरिएका फाइलहरूलाई छुट्टै डोमेनमा राख्नुहोस् जसको "कुकीहरू" सँग कुनै सम्बन्ध छैन। स्क्रिप्ट फरक डोमेनको सन्दर्भमा कार्यान्वयन गरिनेछ र MCS लाई खतरा हुनेछैन।
• सर्भरको HTTP प्रतिक्रियामा, "सामग्री-स्वभाव: संलग्नक" हेडर पठाउनुहोस्। त्यसपछि फाइलहरू ब्राउजर द्वारा डाउनलोड गरिनेछ र कार्यान्वयन हुनेछैन।

थप रूपमा, अब विकासकर्ताहरूलाई XSS शोषणको जोखिम कम गर्न धेरै तरिकाहरू उपलब्ध छन्:

• "HTTP मात्र" झण्डा प्रयोग गरेर, तपाइँ सत्र "कुकीहरू" हेडरहरू दुर्भावनापूर्ण जाभास्क्रिप्टमा पहुँचयोग्य बनाउन सक्नुहुन्छ;
• CSP नीति सही रूपमा लागू गरियो XSS को शोषण गर्न एक आक्रमणकारी को लागी यो धेरै गाह्रो बनाउनेछ;
• Angular वा React जस्ता आधुनिक टेम्प्लेट इन्जिनहरूले प्रयोगकर्ताको ब्राउजरमा आउटपुट गर्नु अघि प्रयोगकर्ताको डाटालाई स्वचालित रूपमा सेनिटाइज गर्छ।

दुई-कारक प्रमाणीकरण कमजोरीहरू

खाता सुरक्षा सुधार गर्न, प्रयोगकर्ताहरूलाई सधैं 2FA (दुई-कारक प्रमाणीकरण) सक्षम गर्न सल्लाह दिइन्छ। वास्तवमा, यदि प्रयोगकर्ताको प्रमाणहरू सम्झौता गरिएको छ भने एक आक्रमणकारीलाई सेवामा पहुँच प्राप्त गर्नबाट रोक्न यो एक प्रभावकारी तरिका हो।

तर के दोस्रो प्रमाणीकरण कारक प्रयोग गर्दा सधैं खाता सुरक्षाको ग्यारेन्टी हुन्छ? 2FA को कार्यान्वयनमा निम्न सुरक्षा समस्याहरू छन्:

• OTP कोडको ब्रुट-फोर्स खोज (एक पटकको कोडहरू)। सञ्चालनको सरलताको बावजुद, त्रुटिहरू जस्तै OTP ब्रूट फोर्स विरुद्ध सुरक्षाको कमी पनि ठूला कम्पनीहरूले सामना गरेका छन्: ढिलो केस, फेसबुक मामला.
• कमजोर पुस्ता एल्गोरिथ्म, उदाहरणका लागि अर्को कोड भविष्यवाणी गर्ने क्षमता।
• तार्किक त्रुटिहरू, जस्तै तपाईंको फोनमा अरू कसैको OTP अनुरोध गर्ने क्षमता, जस्तै यो थियो Shopify बाट।

MCS को मामला मा, 2FA गुगल प्रमाणक र मा आधारित लागू गरिएको छ जोडी। प्रोटोकल आफैंमा पहिले नै समय-परीक्षण गरिएको छ, तर अनुप्रयोग पक्षमा कोड प्रमाणिकरणको कार्यान्वयन जाँच गर्न लायक छ।

MCS 2FA धेरै ठाउँहरूमा प्रयोग गरिन्छ:

• प्रयोगकर्ता प्रमाणीकरण गर्दा। त्यहाँ ब्रुट फोर्स विरुद्ध सुरक्षा छ: प्रयोगकर्ताले एक पटकको पासवर्ड प्रविष्ट गर्न केही प्रयास मात्र गर्छ, त्यसपछि इनपुट केही समयको लागि अवरुद्ध हुन्छ। यसले OTP को ब्रुट-फोर्स चयनको सम्भावनालाई रोक्छ।
• 2FA प्रदर्शन गर्न अफलाइन ब्याकअप कोडहरू उत्पन्न गर्दा, साथै यसलाई असक्षम पार्दै। यहाँ, कुनै ब्रुट फोर्स प्रोटेक्शन लागू गरिएको थिएन, जसले यो सम्भव बनायो, यदि तपाईंसँग खाता र सक्रिय सत्रको लागि पासवर्ड छ भने, ब्याकअप कोडहरू पुन: उत्पन्न गर्न वा 2FA पूर्ण रूपमा अक्षम गर्न।

ब्याकअप कोडहरू OTP अनुप्रयोगद्वारा उत्पन्न गरिएका स्ट्रिङ मानहरूको एउटै दायरामा अवस्थित थिए भन्ने कुरालाई ध्यानमा राख्दै, छोटो समयमा कोड फेला पार्ने सम्भावना धेरै बढी थियो।

"Burp: Intruder" उपकरण प्रयोग गरेर 2FA असक्षम गर्न OTP चयन गर्ने प्रक्रिया

परिणाम

समग्रमा, MCS उत्पादनको रूपमा सुरक्षित देखिन्छ। लेखापरीक्षणको क्रममा, पेन्टेस्टिङ टोलीले ग्राहक VM र तिनीहरूको डेटामा पहुँच प्राप्त गर्न सकेन, र भेट्टाइएका कमजोरीहरूलाई MCS टोलीले तुरुन्तै सच्यायो।

तर यहाँ यो ध्यान दिन महत्त्वपूर्ण छ कि सुरक्षा एक निरन्तर काम हो। सेवाहरू स्थिर छैनन्, तिनीहरू निरन्तर विकसित भइरहेका छन्। र कमजोरी बिना उत्पादन पूर्ण रूपमा विकास गर्न असम्भव छ। तर तपाईंले तिनीहरूलाई समयमै फेला पार्न सक्नुहुन्छ र तिनीहरूको पुनरावृत्तिको सम्भावनालाई कम गर्न सक्नुहुन्छ।

अब MCS मा उल्लेख गरिएका सबै कमजोरीहरू पहिले नै तय भइसकेका छन्। र नयाँहरूको संख्यालाई न्यूनतम राख्न र तिनीहरूको जीवनकाल घटाउनको लागि, प्लेटफर्म टोलीले यो गर्न जारी राख्छ:

• नियमित रूपमा बाह्य कम्पनीहरु द्वारा लेखा परीक्षण सञ्चालन;
• समर्थन र सहभागिता विकास Mail.ru समूह बग बाउन्टी कार्यक्रममा;
• सुरक्षा मा संलग्न। 🙂

स्रोत: www.habr.com