في مساء يوم 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، أي. القدرة على انتحال سجلات DNS في ذاكرة التخزين المؤقت لنظام DNS الخاص بجهاز التوجيه، ويسمح CVE-2019-3978 للمهاجم بعدم انتظار شخص ما من الشبكة الداخلية لطلب إدخال على خادم DNS الخاص به من أجل تسميم ذاكرة التخزين المؤقت للمحلل، ولكن لبدء مثل هذا طلب نفسه من خلال المنفذ 8291 (UDP وTCP). تم إصلاح الثغرة الأمنية بواسطة MikroTik في إصدارات RouterOS 6.45.7 (المستقر) و6.44.6 (طويل الأجل) في 28 أكتوبر 2019، ولكن وفقًا لـ لم يقم معظم المستخدمين حاليًا بتثبيت التصحيحات.
ومن الواضح أن هذه المشكلة يتم استغلالها الآن بشكل نشط "مباشر".
لماذا هو خطير
يمكن للمهاجم انتحال سجل DNS لأي مضيف يصل إليه المستخدم على الشبكة الداخلية، وبالتالي اعتراض حركة المرور إليه. إذا تم إرسال معلومات حساسة بدون تشفير (على سبيل المثال، عبر http:// بدون TLS) أو وافق المستخدم على قبول شهادة مزيفة، فيمكن للمهاجم الحصول على جميع البيانات المرسلة عبر الاتصال، مثل تسجيل الدخول أو كلمة المرور. لسوء الحظ، تظهر الممارسة أنه إذا أتيحت للمستخدم الفرصة لقبول شهادة مزورة، فسوف يستغلها.
لماذا خوادم SMTP وIMAP، وما الذي أنقذ المستخدمين
لماذا حاول المهاجمون اعتراض حركة مرور SMTP/IMAP لتطبيقات البريد الإلكتروني، وليس حركة مرور الويب، على الرغم من أن معظم المستخدمين يصلون إلى بريدهم عبر متصفح HTTPS؟
ليست كل برامج البريد الإلكتروني التي تعمل عبر SMTP وIMAP/POP3 تحمي المستخدم من الأخطاء، وتمنعه من إرسال معلومات تسجيل الدخول وكلمة المرور عبر اتصال غير آمن أو مخترق، على الرغم من أنها تتوافق مع المعايير ، التي تم اعتمادها في عام 2018 (وتم تنفيذها في Mail.ru قبل ذلك بكثير)، يجب عليها حماية المستخدم من اعتراض كلمة المرور من خلال أي اتصال غير آمن. بالإضافة إلى ذلك، نادرا ما يستخدم بروتوكول OAuth في عملاء البريد الإلكتروني (وهو مدعوم من قبل خوادم البريد Mail.ru)، وبدون ذلك، يتم نقل تسجيل الدخول وكلمة المرور في كل جلسة.
قد تكون المتصفحات محمية بشكل أفضل قليلاً ضد هجمات Man-in-the-Middle. في جميع المجالات الهامة لـ mail.ru، بالإضافة إلى HTTPS، يتم تمكين سياسة HSTS (أمان النقل الصارم لـ HTTP). مع تمكين HSTS، لا يوفر المتصفح الحديث للمستخدم خيارًا سهلاً لقبول شهادة مزورة، حتى لو أراد المستخدم ذلك. بالإضافة إلى HSTS، تم إنقاذ المستخدمين من خلال حقيقة أنه منذ عام 2017، تحظر خوادم SMTP وIMAP وPOP3 الخاصة بـ Mail.ru نقل كلمات المرور عبر اتصال غير آمن، ويستخدم جميع مستخدمينا TLS للوصول عبر SMTP وPOP3 وIMAP، و وبالتالي، لا يمكن اعتراض تسجيل الدخول وكلمة المرور إلا إذا وافق المستخدم نفسه على قبول الشهادة المزيفة.
بالنسبة لمستخدمي الأجهزة المحمولة، نوصي دائمًا باستخدام تطبيقات Mail.ru للوصول إلى البريد، لأن... يعد العمل مع البريد فيها أكثر أمانًا من المتصفحات أو عملاء SMTP/IMAP المضمنين.
ماذا أفعل
من الضروري تحديث البرنامج الثابت MikroTik RouterOS إلى إصدار آمن. إذا لم يكن ذلك ممكنا لسبب ما، فمن الضروري تصفية حركة المرور على المنفذ 8291 (tcp و udp)، فسيؤدي ذلك إلى تعقيد استغلال المشكلة، على الرغم من أنه لن يلغي إمكانية الحقن السلبي في ذاكرة التخزين المؤقت لنظام أسماء النطاقات. يجب على مزودي خدمة الإنترنت تصفية هذا المنفذ على شبكاتهم لحماية مستخدمي الشركات.
يجب على جميع المستخدمين الذين قبلوا شهادة بديلة تغيير كلمة المرور للبريد الإلكتروني والخدمات الأخرى التي تم قبول هذه الشهادة لها بشكل عاجل. ومن جانبنا، سنقوم بإخطار المستخدمين الذين يصلون إلى البريد من خلال الأجهزة المعرضة للخطر.
ملاحظة: هناك أيضًا ثغرة أمنية ذات صلة موصوفة في المنشور "".
المصدر: www.habr.com