بذریعہ سیر لائٹ
کسی بھی سروس کی تعمیر میں لازمی طور پر سیکورٹی پر مسلسل کام شامل ہوتا ہے۔ سیکورٹی ایک مسلسل عمل ہے جس میں مسلسل تجزیہ اور مصنوعات کی سیکورٹی میں بہتری، خطرات کے بارے میں خبروں کی نگرانی اور بہت کچھ شامل ہے۔ آڈٹ سمیت۔ آڈٹ اندرون اور بیرونی ماہرین دونوں کے ذریعہ کئے جاتے ہیں، جو بنیادی طور پر سیکورٹی میں مدد کرسکتے ہیں کیونکہ وہ پروجیکٹ میں ڈوبے ہوئے نہیں ہیں اور ان کا ذہن کھلا ہے۔
یہ مضمون بیرونی ماہرین کے اس انتہائی سادہ نظریے کے بارے میں ہے جنہوں نے 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 شناخت کنندگان کو کسی بھی چیز تک رسائی حاصل کرنے کے لیے استعمال کیا جاتا تھا، جو لگتا تھا، جیسا کہ سیکیورٹی ماہرین کہتے ہیں، متاثر کن طور پر غیر محفوظ (یعنی طاقت کے حملوں سے محفوظ)۔ لیکن بعض اداروں کے لیے، یہ دریافت ہوا کہ ایپلی کیشن کے استعمال کنندگان کے بارے میں معلومات حاصل کرنے کے لیے باقاعدہ پیشن گوئی کرنے والے نمبر استعمال کیے جاتے ہیں۔ میرے خیال میں آپ اندازہ لگا سکتے ہیں کہ یوزر آئی ڈی کو ایک ایک کرکے تبدیل کرنا، دوبارہ درخواست بھیجنا اور اس طرح ACL (ایکسیس کنٹرول لسٹ، ڈیٹا تک رسائی کے ضابطے عمل اور صارفین کے لیے) کو نظرانداز کرتے ہوئے معلومات حاصل کرنا ممکن تھا۔
سرور سائیڈ درخواست جعلسازی (SSRF)
اوپن سورس پراڈکٹس کے بارے میں اچھی بات یہ ہے کہ ان کے پاس بہت سارے فورمز ہیں جن میں پیدا ہونے والے مسائل کی تفصیلی تکنیکی وضاحت ہے اور اگر آپ خوش قسمت ہیں تو حل کی تفصیل۔ لیکن اس سکے کا پلٹا پہلو ہے: معلوم خطرات کو بھی تفصیل سے بیان کیا گیا ہے۔ مثال کے طور پر، OpenStack فورم پر خطرات کی شاندار وضاحتیں موجود ہیں۔ и ، جسے کسی وجہ سے کسی کو ٹھیک کرنے کی جلدی نہیں ہے۔
ایپلی کیشنز کی ایک عام فعالیت صارف کے لیے سرور کو ایک لنک بھیجنے کی صلاحیت ہے، جس پر سرور کلک کرتا ہے (مثال کے طور پر، کسی مخصوص ذریعہ سے تصویر ڈاؤن لوڈ کرنا)۔ اگر سیکیورٹی ٹولز لنکس کو خود فلٹر نہیں کرتے ہیں یا سرور سے صارفین کو واپس کیے گئے جوابات کو فلٹر نہیں کرتے ہیں، تو ایسی فعالیت کو حملہ آور آسانی سے استعمال کر سکتے ہیں۔
SSRF کی کمزوریاں حملے کی نشوونما کو بہت آگے بڑھا سکتی ہیں۔ حملہ آور حاصل کر سکتا ہے:
- حملہ شدہ مقامی نیٹ ورک تک محدود رسائی، مثال کے طور پر، صرف نیٹ ورک کے کچھ حصوں کے ذریعے اور ایک مخصوص پروٹوکول کے ذریعے؛
- مقامی نیٹ ورک تک مکمل رسائی، اگر ایپلی کیشن کی سطح سے ٹرانسپورٹ کی سطح تک نیچے کی سطح تک پہنچنا ممکن ہے اور اس کے نتیجے میں، ایپلی کیشن کی سطح پر مکمل لوڈ مینجمنٹ؛
- سرور پر مقامی فائلوں کو پڑھنے تک رسائی (اگر فائل: // اسکیم معاون ہے)؛
- اور بہت کچھ.
OpenStack میں ایک SSRF کمزوری طویل عرصے سے معلوم ہے، جو کہ فطرت میں "بلائنڈ" ہے: جب آپ سرور سے رابطہ کرتے ہیں، تو آپ کو اس سے کوئی جواب نہیں ملتا، لیکن آپ کو درخواست کے نتیجے کے لحاظ سے مختلف قسم کی غلطیاں/تاخیاں موصول ہوتی ہیں۔ . اس کی بنیاد پر، آپ اندرونی نیٹ ورک پر میزبانوں پر پورٹ اسکین انجام دے سکتے ہیں، ان تمام نتائج کے ساتھ جن کو کم نہیں سمجھا جانا چاہیے۔ مثال کے طور پر، کسی پروڈکٹ میں بیک آفس API ہو سکتا ہے جو صرف کارپوریٹ نیٹ ورک سے قابل رسائی ہے۔ دستاویزات کے ساتھ (اندرونی کے بارے میں مت بھولنا)، حملہ آور اندرونی طریقوں تک رسائی کے لیے SSRF کا استعمال کر سکتا ہے۔ مثال کے طور پر، اگر آپ کسی طرح مفید URLs کی تخمینی فہرست حاصل کرنے کے قابل تھے، تو SSRF کا استعمال کرتے ہوئے آپ ان کے ذریعے جا سکتے ہیں اور ایک درخواست پر عمل کر سکتے ہیں - نسبتاً، اکاؤنٹ سے اکاؤنٹ میں رقم کی منتقلی یا حدود کو تبدیل کر سکتے ہیں۔
یہ پہلا موقع نہیں ہے جب OpenStack میں SSRF کی کمزوری دریافت ہوئی ہو۔ ماضی میں، براہ راست لنک سے VM ISO تصاویر ڈاؤن لوڈ کرنا ممکن تھا، جس کے نتیجے میں بھی اسی طرح کے نتائج برآمد ہوئے۔ یہ فیچر اب OpenStack سے ہٹا دیا گیا ہے۔ بظاہر، کمیونٹی نے اسے مسئلے کا سب سے آسان اور قابل اعتماد حل سمجھا۔
اور اندر HackerOne سروس (h1) سے عوامی طور پر دستیاب رپورٹ، مثال کے میٹا ڈیٹا کو پڑھنے کی صلاحیت کے ساتھ اب نابینا SSRF کا استحصال پورے Shopify انفراسٹرکچر تک روٹ رسائی کا باعث بنتا ہے۔
MCS میں، SSRF کی کمزوریاں دو جگہوں پر ایک جیسی فعالیت کے ساتھ دریافت ہوئیں، لیکن فائر والز اور دیگر تحفظات کی وجہ سے ان کا فائدہ اٹھانا تقریباً ناممکن تھا۔ کسی نہ کسی طرح، MCS ٹیم نے کمیونٹی کا انتظار کیے بغیر، بہرحال اس مسئلے کو حل کر دیا۔
شیل لوڈ کرنے کے بجائے XSS
لکھے گئے سینکڑوں مطالعات کے باوجود، سال بہ سال XSS (کراس سائٹ اسکرپٹنگ) حملہ اب بھی سب سے زیادہ ہے۔ ویب کی کمزوری (یا ؟).
فائل اپ لوڈز کسی بھی سیکیورٹی محقق کے لیے پسندیدہ جگہ ہیں۔ یہ اکثر پتہ چلتا ہے کہ آپ ایک صوابدیدی اسکرپٹ (asp/jsp/php) لوڈ کر سکتے ہیں اور OS کمانڈز پر عملدرآمد کر سکتے ہیں، پینٹیسٹرز کی اصطلاح میں - "لوڈ شیل"۔ لیکن اس طرح کے خطرات کی مقبولیت دونوں سمتوں میں کام کرتی ہے: انہیں یاد رکھا جاتا ہے اور ان کے خلاف علاج تیار کیا جاتا ہے، تاکہ حال ہی میں "شیل لوڈ کرنے" کا امکان صفر ہو جائے۔
حملہ آور ٹیم (جس کی نمائندگی ڈیجیٹل سیکورٹی نے کی ہے) خوش قسمت تھی۔ ٹھیک ہے، ایم سی ایس میں سرور سائڈ پر ڈاؤن لوڈ کی گئی فائلوں کے مواد کو چیک کیا گیا، صرف تصاویر کی اجازت تھی۔ لیکن SVG بھی ایک تصویر ہے۔ SVG تصاویر کیسے خطرناک ہو سکتی ہیں؟ کیونکہ آپ ان میں جاوا اسکرپٹ کے ٹکڑوں کو ایمبیڈ کر سکتے ہیں!
معلوم ہوا کہ ڈاؤن لوڈ کی گئی فائلیں MCS سروس کے تمام صارفین کے لیے دستیاب ہیں، جس کا مطلب ہے کہ دوسرے کلاؤڈ صارفین یعنی منتظمین پر حملہ کرنا ممکن ہے۔
فشنگ لاگ ان فارم پر XSS حملے کی ایک مثال
XSS حملے کے استحصال کی مثالیں:
- سیشن چوری کرنے کی کوشش کیوں کریں (خاص طور پر چونکہ اب صرف HTTP- کوکیز ہر جگہ موجود ہیں، js اسکرپٹ کا استعمال کرتے ہوئے چوری سے محفوظ ہیں)، اگر بھری ہوئی اسکرپٹ فوری طور پر ریسورس API تک رسائی حاصل کر سکتی ہے؟ اس صورت میں، پے لوڈ سرور کی ترتیب کو تبدیل کرنے کے لیے XHR درخواستوں کا استعمال کر سکتا ہے، مثال کے طور پر، حملہ آور کی عوامی SSH کلید شامل کریں اور سرور تک SSH رسائی حاصل کریں۔
- اگر CSP پالیسی (مواد کے تحفظ کی پالیسی) JavaScript کو انجیکشن لگانے سے منع کرتی ہے، تو حملہ آور اس کے بغیر بھی جا سکتا ہے۔ خالص ایچ ٹی ایم ایل کا استعمال کرتے ہوئے، سائٹ کے لیے ایک جعلی لاگ ان فارم بنائیں اور اس ایڈوانس فشنگ کے ذریعے ایڈمنسٹریٹر کا پاس ورڈ چوری کریں: صارف کے لیے فشنگ صفحہ اسی یو آر ایل پر ختم ہوتا ہے، اور صارف کے لیے اس کا پتہ لگانا زیادہ مشکل ہوتا ہے۔
- آخر میں، حملہ آور بندوبست کر سکتا ہے - 4 KB سے بڑی کوکیز سیٹ کریں۔ صارف کو صرف ایک بار لنک کھولنے کی ضرورت ہوتی ہے، اور پوری سائٹ اس وقت تک ناقابل رسائی ہو جاتی ہے جب تک کہ صارف خاص طور پر براؤزر کو صاف کرنے کے بارے میں نہیں سوچتا: زیادہ تر معاملات میں، ویب سرور ایسے کلائنٹ کو قبول کرنے سے انکار کر دے گا۔
آئیے ایک اور دریافت شدہ XSS کی مثال دیکھیں، اس بار زیادہ ہوشیار استحصال کے ساتھ۔ MCS سروس آپ کو فائر وال سیٹنگز کو گروپس میں یکجا کرنے کی اجازت دیتی ہے۔ گروپ کا نام وہ جگہ تھا جہاں XSS کا پتہ چلا تھا۔ اس کی خاصیت یہ تھی کہ ویکٹر کو فوری طور پر متحرک نہیں کیا گیا، قواعد کی فہرست دیکھتے وقت نہیں، بلکہ گروپ کو حذف کرتے وقت:
یعنی، منظر نامہ مندرجہ ذیل نکلا: حملہ آور نام میں "لوڈ" کے ساتھ ایک فائر وال رول بناتا ہے، منتظم تھوڑی دیر کے بعد اسے نوٹس کرتا ہے اور حذف کرنے کا عمل شروع کرتا ہے۔ اور یہ وہ جگہ ہے جہاں بدنیتی پر مبنی جے ایس کام کرتا ہے۔
MCS ڈویلپرز کے لیے، ڈاؤن لوڈ کردہ SVG امیجز میں XSS سے حفاظت کے لیے (اگر انہیں ترک نہیں کیا جا سکتا ہے)، ڈیجیٹل سیکیورٹی ٹیم نے سفارش کی:
- صارفین کی اپ لوڈ کردہ فائلوں کو ایک علیحدہ ڈومین پر رکھیں جن کا "کوکیز" سے کوئی تعلق نہیں ہے۔ اسکرپٹ کو مختلف ڈومین کے تناظر میں لاگو کیا جائے گا اور اس سے MCS کو کوئی خطرہ نہیں ہوگا۔
- سرور کے HTTP جواب میں، "مواد کی ترتیب: منسلکہ" ہیڈر بھیجیں۔ پھر فائلوں کو براؤزر کے ذریعہ ڈاؤن لوڈ کیا جائے گا اور عمل میں نہیں لایا جائے گا۔
اس کے علاوہ، اب ڈویلپرز کے لیے XSS کے استحصال کے خطرات کو کم کرنے کے لیے بہت سے طریقے دستیاب ہیں:
- "صرف HTTP" پرچم کا استعمال کرتے ہوئے، آپ سیشن "کوکیز" ہیڈر کو نقصان دہ JavaScript کے لیے ناقابل رسائی بنا سکتے ہیں۔
- حملہ آور کے لیے XSS کا استحصال کرنا زیادہ مشکل بنا دے گا۔
- جدید ٹیمپلیٹ انجن جیسے اینگولر یا ری ایکٹ صارف کے ڈیٹا کو صارف کے براؤزر میں آؤٹ پٹ کرنے سے پہلے خود بخود صاف کرتے ہیں۔
دو عنصر کی توثیق کی کمزوریاں
اکاؤنٹ کی حفاظت کو بہتر بنانے کے لیے، صارفین کو ہمیشہ 2FA (دو عنصر کی تصدیق) کو فعال کرنے کا مشورہ دیا جاتا ہے۔ درحقیقت، اگر صارف کی اسناد سے سمجھوتہ کیا گیا ہو تو حملہ آور کو سروس تک رسائی حاصل کرنے سے روکنے کا یہ ایک مؤثر طریقہ ہے۔
لیکن کیا دوسرے تصدیقی عنصر کا استعمال ہمیشہ اکاؤنٹ کی حفاظت کی ضمانت دیتا ہے؟ 2FA کے نفاذ میں درج ذیل حفاظتی مسائل ہیں:
- 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