SeerLight پاران
ڪنهن به خدمت جي تعمير ۾ لازمي طور تي سيڪيورٽي تي مسلسل ڪم شامل آهي. سيڪيورٽي هڪ مسلسل عمل آهي جنهن ۾ مسلسل تجزيو ۽ پيداوار جي سيڪيورٽي جي بهتري، خطرات جي باري ۾ خبرن جي نگراني ۽ گهڻو ڪجهه شامل آهي. آڊٽ سميت. آڊٽ اندرون ۽ ٻاهرين ماهرن طرفان ڪيا ويندا آهن، جيڪي بنيادي طور تي سيڪيورٽي ۾ مدد ڪري سگھن ٿا ڇو ته اهي پروجيڪٽ ۾ غرق نه آهن ۽ انهن جو ذهن کليل آهي.
هي مضمون خارجي ماهرن جي هن تمام سادي نظر بابت آهي جن Mail.ru Cloud Solutions (MCS) ٽيم کي ڪلائوڊ سروس جي جانچ ڪرڻ ۾ مدد ڪئي، ۽ انهن کي ڇا مليو. "بيروني قوت" جي طور تي، MCS چونڊيو ڊجيٽل سيڪيورٽي ڪمپني، ڄاڻ جي حفاظت جي حلقن ۾ ان جي اعلي ماهر لاء مشهور آهي. ۽ هن آرٽيڪل ۾ اسين خارجي آڊٽ جي حصي جي طور تي مليل ڪجهه دلچسپ ڪمزورين جو تجزيو ڪنداسين - انهي ڪري ته توهان ساڳئي ريڪ کان پاسو ڪندا جڏهن توهان پنهنجي ڪلائوڊ سروس ٺاهيندا آهيو.
مصنوعات جي وضاحت
ڪلائوڊ ۾ ورچوئل انفراسٽرڪچر جي تعمير لاءِ هڪ پليٽ فارم آهي. ان ۾ شامل آهي IaaS، PaaS، ۽ ڊولپرز لاءِ تيار ٿيل ايپليڪيشن تصويرن جو مارڪيٽ. MCS فن تعمير کي مدنظر رکندي، هيٺين علائقن ۾ پيداوار جي حفاظت کي جانچڻ ضروري هو:
- ورچوئلائيزيشن ماحول جي انفراسٽرڪچر کي تحفظ ڏيڻ: هائپر ويزرز، روٽنگ، فائر والز؛
- گراهڪن جي ورچوئل انفراسٽرڪچر جو تحفظ: هڪ ٻئي کان اڪيلائي، بشمول نيٽ ورڪ، SDN ۾ نجي نيٽ ورڪ؛
- OpenStack ۽ ان جا کليل اجزا؛
- اسان جي پنهنجي ڊيزائن جي S3؛
- IAM: هڪ رول ماڊل سان گڏ گھڻا نوڪر پراجيڪٽ؛
- ويزن (ڪمپيوٽر وژن): APIs ۽ ڪمزوريون جڏهن تصويرن سان ڪم ڪندي؛
- ويب انٽرفيس ۽ کلاسک ويب حملا؛
- PaaS اجزاء جا نقصان؛
- سڀني اجزاء جو API.
شايد اهو سڀ ڪجهه آهي جيڪو اڳتي هلي تاريخ لاءِ ضروري آهي.
ڪهڙي قسم جو ڪم ڪيو ويو ۽ ان جي ضرورت ڇو هئي؟
هڪ سيڪيورٽي آڊٽ جو مقصد نقصانڪارن ۽ ترتيبن جي غلطين جي نشاندهي ڪرڻ آهي جيڪي ذاتي ڊيٽا جي ليڪ ٿيڻ، حساس معلومات جي ترميم، يا خدمت جي دستيابي ۾ خلل جو سبب بڻجي سگهن ٿيون.
ڪم جي دوران، جيڪو سراسري طور تي 1-2 مهينن تائين رهي ٿو، آڊيٽر امڪاني حملي ڪندڙن جي عملن کي ورجائيندا آهن ۽ چونڊيل سروس جي ڪلائنٽ ۽ سرور حصن ۾ ڪمزورين کي ڳوليندا آهن. MCS ڪلائوڊ پليٽ فارم جي آڊٽ جي حوالي سان، هيٺين مقصدن جي نشاندهي ڪئي وئي:
- Анализ аутентификации в сервисе. Уязвимости в данном компоненте помогли бы сразу попасть в чужие аккаунты.
- رول ماڊل جو مطالعو ۽ مختلف اڪائونٽن جي وچ ۾ رسائي ڪنٽرول. هڪ حملي آور لاء، ڪنهن ٻئي جي مجازي مشين تائين رسائي حاصل ڪرڻ جي صلاحيت هڪ گهربل مقصد آهي.
- ڪلائنٽ جي پاسي جي ڪمزورين. XSS/CSRF/CRLF/etc. ڇا اهو ممڪن آهي ته ٻين استعمال ڪندڙن کي بدسلوڪي لنڪ ذريعي حملو ڪيو وڃي؟
- سرور جي پاسي جا ڪمزوريون: RCE ۽ سڀني قسمن جا انجڻ (SQL/XXE/SSRF وغيره). سرور جي ڪمزوري عام طور تي ڳولڻ ۾ وڌيڪ ڏکيو آهي، پر اهي هڪ ئي وقت ۾ ڪيترن ئي استعمال ڪندڙن جي سمجھوتي کي ڏسندا آهن.
- نيٽ ورڪ جي سطح تي صارف جي ڀاڱي جي اڪيلائي جو تجزيو. حملي آور لاءِ، اڪيلائي جي کوٽ ٻين استعمال ڪندڙن جي خلاف حملي جي مٿاڇري کي تمام گهڻو وڌائي ٿي.
- ڪاروباري منطق جو تجزيو. ڇا اهو ممڪن آهي ته ڌنڌي کي ٺڳي ۽ مفت ۾ ورچوئل مشينون ٺاهي؟
هن پروجيڪٽ ۾، ڪم "گرين باڪس" ماڊل جي مطابق ڪيو ويو: آڊيٽر سروس سان عام استعمال ڪندڙن جي استحقاق سان رابطو ڪيو، پر جزوي طور تي API جو سورس ڪوڊ حاصل ڪيو ۽ ڊولپرز سان تفصيلات واضح ڪرڻ جو موقعو مليو. اهو عام طور تي سڀ کان وڌيڪ آسان آهي، ۽ ساڳئي وقت ڪم جو ڪافي حقيقي نمونو: اندروني معلومات اڃا تائين حملي ڪندڙ طرفان گڏ ڪري سگهجي ٿو، اهو صرف وقت جو معاملو آهي.
ڪمزوريون مليون
ان کان اڳ جو آڊيٽر مختلف پيل لوڊ (حملو ڪرڻ لاءِ استعمال ٿيل پيل لوڊ) بي ترتيب هنڌن تي موڪلڻ شروع ڪري، اهو سمجهڻ ضروري آهي ته شيون ڪيئن ڪم ڪن ٿيون ۽ ڪهڙي ڪارڪردگي مهيا ڪئي وڃي ٿي. اهو لڳي سگهي ٿو ته اهو هڪ بيڪار مشق آهي، ڇاڪاڻ ته اڪثر اڀياس ڪيل جڳهن ۾ ڪو به نقصان نه ٿيندو. پر صرف ايپليڪيشن جي جوڙجڪ کي سمجهڻ ۽ ان جي عمل جي منطق کي اهو ممڪن بڻائي سگهندو ته سڀ کان وڌيڪ پيچيده حملي ویکٹر ڳولڻ.
اهو ضروري آهي ته جڳهون ڳولڻ لاء جيڪي مشڪوڪ نظر اچن ٿا يا ڪنهن طريقي سان ٻين کان تمام مختلف آهن. ۽ پهرين خطرناڪ ڪمزوري هن طريقي سان ملي هئي.
IDOR
IDOR (غير محفوظ سڌو آبجیکٹ ريفرنس) خطرات ڪاروباري منطق ۾ سڀ کان وڌيڪ عام ڪمزورين مان آهن، جيڪي هڪ يا ٻئي کي انهن شين تائين رسائي حاصل ڪرڻ جي اجازت ڏين ٿيون جن تائين رسائي جي حقيقت ۾ اجازت ناهي. IDOR ڪمزوريون مختلف درجي جي تنقيد جي استعمال ڪندڙ بابت معلومات حاصل ڪرڻ جو امڪان پيدا ڪن ٿيون.
IDOR اختيارن مان ھڪڙو آھي سسٽم شيون (صارفين، بئنڪ اڪائونٽس، شاپنگ ڪارٽ ۾ شيون) سان عملن کي انجام ڏيڻ جي ذريعي انھن شين تائين رسائي جي سڃاڻپ ڪندڙ کي ترتيب ڏيڻ سان. اهو سڀ کان وڌيڪ غير متوقع نتيجن جي ڪري ٿو. مثال طور، پئسن جي موڪليندڙ جي اڪائونٽ کي تبديل ڪرڻ جو امڪان، جنهن جي ذريعي توهان انهن کي ٻين صارفين کان چوري ڪري سگهو ٿا.
MCS جي صورت ۾، آڊيٽرز صرف غير محفوظ سڃاڻپ ڪندڙ سان لاڳاپيل هڪ IDOR خطرات کي دريافت ڪيو. صارف جي ذاتي اڪائونٽ ۾، UUID سڃاڻپ ڪندڙ ڪنهن به شئي تائين رسائي لاءِ استعمال ڪيا ويا، جيڪي لڳي رهيا هئا، جيئن سيڪيورٽي ماهر چون ٿا، متاثر ڪندڙ طور تي غير محفوظ (يعني وحشي قوتن جي حملن کان محفوظ آهي). پر ڪجهه ادارن لاءِ، اهو معلوم ڪيو ويو ته باقاعده پيش گوئي ڪندڙ نمبر استعمال ڪيا ويندا آهن ايپليڪيشن جي استعمال ڪندڙن بابت معلومات حاصل ڪرڻ لاءِ. مان سمجهان ٿو ته توهان اندازو لڳائي سگهو ٿا ته اهو ممڪن هو ته صارف جي ID کي هڪ طرف تبديل ڪرڻ، ٻيهر درخواست موڪليو ۽ اهڙيء طرح معلومات حاصل ڪريو ACL (رسائي ڪنٽرول لسٽ، ڊيٽا جي رسائي جي ضابطن لاء پروسيس ۽ صارفين).
سرور سائڊ درخواست جعلسازي (SSRF)
OpenSource پراڊڪٽس جي باري ۾ سٺي شيء اها آهي ته انهن وٽ وڏي تعداد ۾ فورمز آهن جن ۾ مسئلن جي تفصيلي ٽيڪنيڪل وضاحتن سان گڏ، ۽، جيڪڏهن توهان خوش قسمت آهيو، حل جي وضاحت. پر هن سکن جو هڪ فلپ پاسو آهي: ڄاڻايل خطرات پڻ تفصيل سان بيان ڪيا ويا آهن. مثال طور، OpenStack فورم تي ڪمزورين جا شاندار بيان آهن и ، جنهن کي ڪجهه سببن لاءِ ڪنهن کي به ٺيڪ ڪرڻ ۾ جلدي ناهي.
ايپليڪيشنن جي هڪ عام ڪارڪردگي صارف جي سرور ڏانهن لنڪ موڪلڻ جي صلاحيت آهي، جنهن تي سرور ڪلڪ ڪري ٿو (مثال طور، هڪ مخصوص ذريعن مان هڪ تصوير ڊائون لوڊ ڪرڻ). جيڪڏهن حفاظتي اوزار پاڻ لنڪن کي فلٽر نه ڪندا آهن يا سرور کان صارفين ڏانهن موٽڻ وارا جواب، اهڙي ڪارڪردگي آساني سان حملو ڪندڙ طرفان استعمال ڪري سگھجن ٿيون.
ايس ايس آر ايف جي ڪمزورين حملن جي ترقي کي تمام گهڻو اڳتي وڌائي سگھي ٿو. هڪ حملو ڪندڙ حاصل ڪري سگهي ٿو:
- حملو ٿيل مقامي نيٽ ورڪ تائين محدود رسائي، مثال طور، صرف ڪجهه نيٽ ورڪ حصن ذريعي ۽ هڪ خاص پروٽوڪول استعمال ڪندي؛
- مقامي نيٽ ورڪ تائين مڪمل رسائي، جيڪڏهن ايپليڪيشن جي سطح کان ٽرانسپورٽ جي سطح تائين گهٽتائي ممڪن آهي، ۽ نتيجي طور، ايپليڪيشن سطح تي مڪمل لوڊ انتظام؛
- سرور تي مقامي فائلن کي پڙهڻ جي رسائي (جيڪڏهن فائل /// اسڪيم سپورٽ ڪئي وئي آهي)؛
- ۽ گهڻو ڪجهه.
OpenStack ۾ هڪ SSRF ڪمزوري گهڻي عرصي کان معلوم ٿي چڪي آهي، جيڪا فطرت ۾ ”انڌي“ آهي: جڏهن توهان سرور سان رابطو ڪندا آهيو، توهان کي ان مان ڪو جواب نه ملندو آهي، پر توهان کي مختلف قسم جون غلطيون/تاخيرون ملنديون آهن، درخواست جي نتيجي تي منحصر هوندو آهي. . انهي جي بنياد تي، توهان اندروني نيٽ ورڪ تي ميزبان تي هڪ پورٽ اسڪين انجام ڏئي سگهو ٿا، سڀني ايندڙ نتيجن سان جيڪي گهٽ نه ٿيڻ گهرجن. مثال طور، هڪ پراڊڪٽ وٽ شايد بيڪ-آفيس API هجي جيڪا صرف ڪارپوريٽ نيٽ ورڪ کان رسائي لائق آهي. دستاويزن سان (اندر جي باري ۾ نه وساريو)، هڪ حملو ڪندڙ اندروني طريقن تائين رسائي حاصل ڪرڻ لاءِ SSRF استعمال ڪري سگهي ٿو. مثال طور، جيڪڏهن توهان ڪنهن طريقي سان مفيد URLs جي لڳ ڀڳ لسٽ حاصل ڪرڻ جي قابل هئا، ته پوءِ SSRF استعمال ڪندي توهان انهن ذريعي وڃو ۽ هڪ درخواست تي عمل ڪري سگهو ٿا - نسبتا ڳالهائڻ، اڪائونٽ کان اڪائونٽ ۾ پئسا منتقل ڪرڻ يا حدون تبديل ڪرڻ.
اهو پهريون ڀيرو نه آهي ته OpenStack ۾ هڪ SSRF جي ڪمزوري دريافت ڪئي وئي آهي. ماضي ۾، اهو ممڪن هو ته ڊائون لوڊ ڪرڻ لاء VM ISO تصويرون هڪ سڌي لنڪ کان، جنهن جي نتيجي ۾ پڻ ساڳيو نتيجا. ھن خصوصيت کي ھاڻي OpenStack مان ھٽايو ويو آھي. بظاهر، ڪميونٽي هن مسئلي جو آسان ۽ سڀ کان وڌيڪ قابل اعتماد حل سمجهيو.
۽ اندر هيڪر ون سروس (h1) کان عوامي طور تي دستياب رپورٽ، مثال جي ميٽا ڊيٽا پڙهڻ جي صلاحيت سان وڌيڪ انڌا SSRF جو استحصال پوري Shopify انفرااسٽرڪچر تائين روٽ رسائي جي ڪري ٿي.
MCS ۾، SSRF جي ڪمزورين کي ٻن هنڌن تي ساڳئي ڪارڪردگي سان دريافت ڪيو ويو، پر فائر والز ۽ ٻين تحفظن جي ڪري انهن جو استحصال ڪرڻ لڳ ڀڳ ناممڪن هو. هڪ طريقو يا ٻيو، MCS ٽيم ڪنهن به طرح هن مسئلي کي حل ڪيو، ڪميونٽي جي انتظار کان سواء.
شيل لوڊ ڪرڻ بدران XSS
لکڻ جي سوين مطالعي جي باوجود، سال بعد سال XSS (ڪراس سائيٽ اسڪرپٽ) حملو اڃا تائين سڀ کان وڌيڪ آهي ويب جي ڪمزوري (يا ؟).
فائل اپلوڊ ڪنهن به سيڪيورٽي محقق لاءِ پسنديده جڳهه آهن. اهو اڪثر ڪري ٿو ته توهان هڪ صوابديدي اسڪرپٽ لوڊ ڪري سگهو ٿا (asp/jsp/php) ۽ OS حڪمن تي عمل ڪري سگهو ٿا، پينٽيسٽرز جي اصطلاحن ۾ - "لوڊ شيل". پر اهڙن خطرن جي مقبوليت ٻنهي طرفن ۾ ڪم ڪري ٿي: انهن کي ياد ڪيو وڃي ٿو ۽ انهن جي خلاف علاج ٺاهيا ويا آهن، انهي ڪري ته تازو "شيل لوڊ ڪرڻ" جو امڪان صفر ڏانهن وڌي ٿو.
حملي واري ٽيم (ڊيجيٽل سيڪيورٽي جي نمائندگي) خوش قسمت هئي. ٺيڪ، MCS ۾ سرور جي پاسي تي ڊائون لوڊ ڪيل فائلن جي مواد کي چيڪ ڪيو ويو، صرف تصويرن جي اجازت ڏني وئي. پر SVG پڻ هڪ تصوير آهي. SVG تصويرون ڪيئن خطرناڪ ٿي سگهن ٿيون؟ ڇو ته توھان انھن ۾ جاوا اسڪرپٽ جا ٽڪرا شامل ڪري سگھو ٿا!
اهو ظاهر ٿيو ته ڊائون لوڊ ڪيل فائلون MCS سروس جي سڀني استعمال ڪندڙن لاء دستياب آهن، جنهن جو مطلب آهي ته اهو ممڪن آهي ٻين ڪلائوڊ استعمال ڪندڙن تي حملو ڪرڻ، يعني منتظمين.
فشنگ لاگ ان فارم تي XSS حملي جو هڪ مثال
XSS حملي جي استحصال جا مثال:
- سيشن کي چوري ڪرڻ جي ڪوشش ڇو ڪجي (خاص طور تي هاڻي کان وٺي HTTP-Only ڪوڪيز هر جڳهه آهن، چوري کان محفوظ آهن js اسڪرپٽ استعمال ڪندي)، جيڪڏهن لوڊ ٿيل اسڪرپٽ فوري طور تي وسيلن API تائين رسائي ڪري سگهي ٿي؟ انهي صورت ۾، پيل لوڊ استعمال ڪري سگھي ٿو XHR درخواستن کي سرور جي ترتيب کي تبديل ڪرڻ لاء، مثال طور، حملي ڪندڙ جي عوامي SSH ڪيچ کي شامل ڪريو ۽ سرور تائين SSH رسائي حاصل ڪريو.
- جيڪڏهن CSP پاليسي (مواد جي حفاظت واري پاليسي) جاوا اسڪرپٽ کي انجڻ کان روڪي ٿي، هڪ حملو ڪندڙ ان جي بغير حاصل ڪري سگهي ٿو. خالص HTML استعمال ڪندي، سائيٽ لاءِ جعلي لاگ ان فارم ٺاهيو ۽ ايڊمنسٽريٽر جو پاسورڊ چوري ڪريو هن جديد فشنگ ذريعي: صارف لاءِ فشنگ صفحو ساڳئي URL تي ختم ٿئي ٿو، ۽ صارف لاءِ ان کي ڳولڻ وڌيڪ ڏکيو آهي.
- آخرڪار، حملو ڪندڙ بندوبست ڪري سگھن ٿا - 4 KB کان وڏيون ڪوڪيز سيٽ ڪريو. استعمال ڪندڙ کي صرف هڪ ڀيرو لنڪ کولڻ جي ضرورت آهي، ۽ سڄي سائيٽ ناقابل رسائي ٿي ويندي آهي جيستائين صارف خاص طور تي برائوزر کي صاف ڪرڻ لاء نه سوچيندو آهي: ڪيسن جي وڏي اڪثريت ۾، ويب سرور اهڙي ڪلائنٽ کي قبول ڪرڻ کان انڪار ڪري ڇڏيندو.
اچو ته هڪ ٻيو ڳوليل XSS جو هڪ مثال ڏسو، هن ڀيري وڌيڪ چالاڪ استحصال سان. MCS سروس توهان کي گروپن ۾ فائر وال سيٽنگون گڏ ڪرڻ جي اجازت ڏئي ٿي. گروپ جو نالو هو جتي XSS معلوم ڪيو ويو. ان جي خصوصيت اها هئي ته ویکٹر کي فوري طور تي شروع نه ڪيو ويو، نه جڏهن ضابطن جي فهرست کي ڏسڻ، پر جڏهن هڪ گروپ کي حذف ڪيو ويو:
اھو آھي، منظر ھيٺ ڏنل آھي: ھڪڙو حملو ڪندڙ نالي ۾ "لوڊ" سان فائر وال قاعدو ٺاھي ٿو، منتظم ڪجھ دير کان پوء ان کي نوٽيس ڪري ٿو ۽ ختم ڪرڻ جي عمل کي شروع ڪري ٿو. ۽ اھو اھو آھي جتي بدسلوڪي JS ڪم ڪري ٿو.
MCS ڊولپرز لاءِ، ڊائون لوڊ ڪيل SVG تصويرن ۾ XSS کان بچاءُ لاءِ (جيڪڏهن انهن کي ڇڏي نه سگهجي)، ڊجيٽل سيڪيورٽي ٽيم سفارش ڪئي:
- استعمال ڪندڙن پاران اپلوڊ ڪيل فائلن کي الڳ ڊومين تي رکو جن جو ”ڪوڪيز“ سان ڪو به واسطو ناهي. اسڪرپٽ کي مختلف ڊومين جي حوالي سان عمل ڪيو ويندو ۽ MCS کي خطرو نه ٿيندو.
- سرور جي HTTP جواب ۾، موڪليو "مواد جي ترتيب: منسلڪ" هيڊر. پوءِ فائلون برائوزر طرفان ڊائون لوڊ ڪيون وينديون ۽ عمل نه ڪيون وينديون.
ان کان علاوه، ھاڻي ڪيترائي طريقا موجود آھن ڊولپرز وٽ XSS استحصال جي خطرن کي گھٽائڻ لاءِ:
- "صرف HTTP" پرچم استعمال ڪندي، توھان ڪري سگھو ٿا سيشن "ڪوڪيز" ھيڊرز بدسلوڪي جاوا اسڪرپٽ تائين پھچڻ جي قابل نه آھن؛
- هڪ حملي آور لاءِ XSS جو استحصال ڪرڻ وڌيڪ مشڪل بڻائيندو؛
- جديد ٽيمپليٽ انجڻ جهڙوڪ Angular يا React خودڪار طريقي سان استعمال ڪندڙ جي ڊيٽا کي صاف ڪرڻ کان پهريان ان کي صارف جي برائوزر ڏانهن ٻاھر ڪڍڻ کان اڳ.
ٻه عنصر جي تصديق جي ڪمزورين
اڪائونٽ سيڪيورٽي کي بهتر ڪرڻ لاء، صارفين کي هميشه 2FA (ٻه عنصر جي تصديق) کي فعال ڪرڻ جي صلاح ڏني وئي آهي. درحقيقت، اهو هڪ مؤثر طريقو آهي هڪ حملي ڪندڙ کي ڪنهن خدمت تائين رسائي حاصل ڪرڻ کان روڪڻ جو جيڪڏهن صارف جي سندن سان ٺاهه ڪيو ويو آهي.
پر ڇا هڪ سيڪنڊ جي تصديق واري عنصر کي استعمال ڪندي هميشه اڪائونٽ جي حفاظت جي ضمانت ڏئي ٿو؟ 2FA جي عمل ۾ هيٺيان سيڪيورٽي مسئلا آهن:
- Brute-force OTP ڪوڊ جي ڳولا (هڪ دفعي ڪوڊ). آپريشن جي سادگي جي باوجود، غلطيون جهڙوڪ OTP برٽ فورس جي خلاف تحفظ جي کوٽ پڻ وڏي ڪمپنين پاران سامھون آھن: , .
- ڪمزور نسل الگورتھم، مثال طور ايندڙ ڪوڊ جي اڳڪٿي ڪرڻ جي صلاحيت.
- منطقي غلطيون، جهڙوڪ توهان جي فون تي ڪنهن ٻئي جي OTP جي درخواست ڪرڻ جي صلاحيت، هن وانگر Shopify کان.
MCS جي صورت ۾، 2FA لاڳو ڪيو ويو آهي Google Authenticator جي بنياد تي ۽ . پروٽوڪول پاڻ اڳ ۾ ئي وقت جي جانچ ڪئي وئي آهي، پر ايپليڪيشن جي پاسي تي ڪوڊ جي تصديق جي عمل کي جانچڻ جي قابل آهي.
MCS 2FA ڪيترن ئي هنڌن تي استعمال ڪيو ويندو آهي:
- جڏهن استعمال ڪندڙ جي تصديق. برٽ فورس جي خلاف تحفظ آهي: استعمال ڪندڙ کي صرف هڪ ڀيرو پاسورڊ داخل ڪرڻ لاء ڪجھ ڪوششون آهن، پوء ان پٽ کي ڪجهه دير تائين بند ڪيو ويو آهي. هي OTP جي برٽ فورس جي چونڊ جي امڪان کي روڪي ٿو.
- جڏهن 2FA انجام ڏيڻ لاءِ آف لائن بيڪ اپ ڪوڊ ٺاهي رهيا آهن، انهي سان گڏ ان کي غير فعال ڪرڻ. هتي، ڪنهن به طاقت جي حفاظت تي عمل نه ڪيو ويو، جنهن اهو ممڪن ڪيو، جيڪڏهن توهان وٽ اڪائونٽ ۽ هڪ فعال سيشن لاء پاسورڊ هجي، بيڪ اپ ڪوڊ ٻيهر ٺاهڻ يا مڪمل طور تي 2FA کي غير فعال ڪرڻ لاء.
انهي ڳالهه تي غور ڪندي ته بيڪ اپ ڪوڊ سٽرنگ ويلز جي ساڳي رينج ۾ موجود هئا جيڪي OTP ايپليڪيشن پاران ٺاهيا ويا آهن، ٿوري وقت ۾ ڪوڊ ڳولڻ جو موقعو تمام گهڻو هو.
"Burp: Intruder" ٽول استعمال ڪندي 2FA کي غير فعال ڪرڻ لاءِ OTP چونڊڻ جو عمل
نتيجي ۾
مجموعي طور تي، MCS هڪ پيداوار جي طور تي محفوظ ٿي لڳي. آڊٽ دوران، پينٽيسٽنگ ٽيم ڪلائنٽ VMs ۽ انهن جي ڊيٽا تائين رسائي حاصل ڪرڻ ۾ ناڪام رهي، ۽ مليل نقصانن کي MCS ٽيم پاران جلدي درست ڪيو ويو.
پر هتي اهو نوٽ ڪرڻ ضروري آهي ته سيڪيورٽي هڪ مسلسل ڪم آهي. خدمتون جامد نه آهن، اهي مسلسل ترقي ڪري رهيا آهن. ۽ اهو ناممڪن آهي ته هڪ پيداوار مڪمل طور تي نقصان جي بغير ترقي ڪري. پر توهان انهن کي وقت ۾ ڳولي سگهو ٿا ۽ انهن جي ٻيهر ٿيڻ جو موقعو گهٽائي سگهو ٿا.
ھاڻي MCS ۾ ذڪر ڪيل سڀيئي خرابيون اڳ ۾ ئي طئي ڪيون ويون آھن. ۽ نون ماڻهن جو تعداد گهٽ ۾ گهٽ رکڻ ۽ انهن جي زندگيءَ کي گهٽائڻ لاءِ، پليٽ فارم ٽيم هي ڪم جاري رکي ٿي:
- باقاعدي طور تي ٻاهرين ڪمپنين پاران آڊٽ ڪرڻ؛
- حمايت ۽ ترقي جي شموليت;
- سيڪيورٽي ۾ مشغول. 🙂
جو ذريعو: www.habr.com