10 مارچ کی شام کو، Mail.ru سپورٹ سروس کو صارفین کی جانب سے ای میل پروگرامز کے ذریعے Mail.ru IMAP/SMTP سرورز سے جڑنے میں ناکامی کے بارے میں شکایات موصول ہونا شروع ہوئیں۔ ایک ہی وقت میں، کچھ کنکشن نہیں گزرے، اور کچھ سرٹیفکیٹ کی خرابی دکھاتے ہیں۔ غلطی "سرور" کی طرف سے خود دستخط شدہ TLS سرٹیفکیٹ جاری کرنے کی وجہ سے ہوئی ہے۔
دو دنوں میں، 10 سے زیادہ شکایات صارفین کی جانب سے مختلف نیٹ ورکس اور مختلف آلات کے ساتھ آئیں، جس سے اس بات کا امکان نہیں ہے کہ مسئلہ کسی ایک فراہم کنندہ کے نیٹ ورک میں ہو۔ مسئلے کے مزید تفصیلی تجزیے سے یہ بات سامنے آئی ہے کہ imap.mail.ru سرور (نیز دیگر میل سرورز اور خدمات) کو DNS سطح پر تبدیل کیا جا رہا ہے۔ مزید، اپنے صارفین کی فعال مدد سے، ہم نے پایا کہ اس کی وجہ ان کے راؤٹر کے کیشے میں ایک غلط اندراج تھی، جو کہ مقامی DNS حل کرنے والا بھی ہے، اور جو بہت سے (لیکن تمام نہیں) معاملات میں MikroTik نکلا۔ ڈیوائس، چھوٹے کارپوریٹ نیٹ ورکس اور چھوٹے انٹرنیٹ فراہم کنندگان میں بہت مقبول ہے۔
مسئلہ کیا ہے
ستمبر 2019 میں، محققین MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979) میں کئی خطرات، جس نے DNS کیش پوائزننگ اٹیک کی اجازت دی، یعنی راؤٹر کے ڈی این ایس کیشے میں ڈی این ایس ریکارڈز کو جعل سازی کرنے کی صلاحیت، اور CVE-2019-3978 حملہ آور کو اجازت دیتی ہے کہ وہ اندرونی نیٹ ورک کے کسی فرد کا اپنے DNS سرور پر اندراج کی درخواست کرنے کا انتظار نہ کرے تاکہ ریزولور کیشے کو زہر آلود کیا جا سکے۔ پورٹ 8291 (UDP اور TCP) کے ذریعے خود ایک درخواست۔ MikroTik نے RouterOS 6.45.7 (مستحکم) اور 6.44.6 (طویل مدتی) کے ورژن میں 28 اکتوبر 2019 کو کمزوری کو ٹھیک کیا تھا، لیکن اس کے مطابق زیادہ تر صارفین نے فی الحال پیچ انسٹال نہیں کیے ہیں۔
یہ ظاہر ہے کہ اس مسئلے کو اب "لائیو" کے طور پر استعمال کیا جا رہا ہے۔
یہ خطرناک کیوں ہے؟
حملہ آور داخلی نیٹ ورک پر کسی صارف کے ذریعے رسائی حاصل کرنے والے کسی بھی میزبان کے DNS ریکارڈ کو دھوکہ دے سکتا ہے، اس طرح اس پر ٹریفک کو روکتا ہے۔ اگر حساس معلومات کو خفیہ کاری کے بغیر منتقل کیا جاتا ہے (مثال کے طور پر، TLS کے بغیر http:// پر) یا صارف جعلی سرٹیفکیٹ قبول کرنے پر راضی ہوتا ہے، تو حملہ آور وہ تمام ڈیٹا حاصل کر سکتا ہے جو کنکشن کے ذریعے بھیجا جاتا ہے، جیسے لاگ ان یا پاس ورڈ۔ بدقسمتی سے، پریکٹس سے پتہ چلتا ہے کہ اگر کسی صارف کو جعلی سرٹیفکیٹ قبول کرنے کا موقع ملتا ہے، تو وہ اس سے فائدہ اٹھائے گا۔
SMTP اور IMAP سرورز کیوں، اور کس چیز نے صارفین کو بچایا
حملہ آوروں نے ای میل ایپلی کیشنز کے SMTP/IMAP ٹریفک کو روکنے کی کوشش کیوں کی، نہ کہ ویب ٹریفک، حالانکہ زیادہ تر صارفین HTTPS براؤزر کے ذریعے اپنے میل تک رسائی حاصل کرتے ہیں؟
SMTP اور IMAP/POP3 کے ذریعے کام کرنے والے تمام ای میل پروگرام صارف کو غلطیوں سے نہیں بچاتے، اسے غیر محفوظ یا سمجھوتہ شدہ کنکشن کے ذریعے لاگ ان اور پاس ورڈ بھیجنے سے روکتے ہیں، حالانکہ معیار کے مطابق 2018 میں اپنایا گیا تھا (اور بہت پہلے Mail.ru میں لاگو کیا گیا تھا)، انہیں کسی بھی غیر محفوظ کنکشن کے ذریعے صارف کو پاس ورڈ کی مداخلت سے بچانا چاہیے۔ اس کے علاوہ، OAuth پروٹوکول ای میل کلائنٹس میں بہت کم استعمال ہوتا ہے (یہ Mail.ru میل سرورز کے ذریعے تعاون یافتہ ہے)، اور اس کے بغیر، لاگ ان اور پاس ورڈ ہر سیشن میں منتقل ہوتے ہیں۔
مین-ان-دی مڈل حملوں کے خلاف براؤزر قدرے بہتر طور پر محفوظ ہو سکتے ہیں۔ تمام mail.ru اہم ڈومینز پر، HTTPS کے علاوہ، HSTS (HTTP سخت ٹرانسپورٹ سیکیورٹی) پالیسی فعال ہے۔ HSTS فعال ہونے کے ساتھ، ایک جدید براؤزر صارف کو جعلی سرٹیفکیٹ قبول کرنے کا آسان آپشن نہیں دیتا، چاہے صارف چاہے۔ HSTS کے علاوہ، صارفین کو اس حقیقت سے بچایا گیا کہ 2017 سے، Mail.ru کے SMTP، IMAP اور POP3 سرورز غیر محفوظ کنکشن پر پاس ورڈز کی منتقلی پر پابندی لگاتے ہیں، ہمارے تمام صارفین نے SMTP، POP3 اور IMAP کے ذریعے رسائی کے لیے TLS کا استعمال کیا، اور لہذا لاگ ان اور پاس ورڈ صرف اس صورت میں روک سکتے ہیں جب صارف خود جعلی سرٹیفکیٹ کو قبول کرنے پر راضی ہو۔
موبائل صارفین کے لیے، ہم ہمیشہ میل تک رسائی کے لیے Mail.ru ایپلیکیشنز استعمال کرنے کی تجویز کرتے ہیں، کیونکہ... ان میں میل کے ساتھ کام کرنا براؤزرز یا بلٹ ان SMTP/IMAP کلائنٹس سے زیادہ محفوظ ہے۔
کیا کرنا چاہیے
MikroTik RouterOS فرم ویئر کو محفوظ ورژن میں اپ ڈیٹ کرنا ضروری ہے۔ اگر کسی وجہ سے یہ ممکن نہیں ہے، تو پورٹ 8291 (tcp اور udp) پر ٹریفک کو فلٹر کرنا ضروری ہے، یہ مسئلہ کے استحصال کو پیچیدہ بنا دے گا، حالانکہ یہ DNS کیشے میں غیر فعال انجیکشن کے امکان کو ختم نہیں کرے گا۔ ISPs کو کارپوریٹ صارفین کی حفاظت کے لیے اپنے نیٹ ورکس پر اس پورٹ کو فلٹر کرنا چاہیے۔
تمام صارفین جنہوں نے متبادل سرٹیفکیٹ قبول کیا ہے انہیں فوری طور پر ای میل اور دیگر خدمات کا پاس ورڈ تبدیل کرنا چاہیے جن کے لیے یہ سرٹیفکیٹ قبول کیا گیا تھا۔ ہماری طرف سے، ہم ان صارفین کو مطلع کریں گے جو کمزور آلات کے ذریعے میل تک رسائی حاصل کرتے ہیں۔
PS پوسٹ میں بیان کردہ ایک متعلقہ کمزوری بھی ہے۔ "".
ماخذ: www.habr.com