तुमच्या MikroTik वर RouterOS अपडेट करा

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 रेकॉर्डची फसवणूक करू शकतो, ज्यामुळे त्यावरील रहदारी रोखू शकते. जर संवेदनशील माहिती एन्क्रिप्शनशिवाय प्रसारित केली गेली असेल (उदाहरणार्थ, TLS शिवाय http:// वर) किंवा वापरकर्ता बनावट प्रमाणपत्र स्वीकारण्यास सहमत असेल, तर आक्रमणकर्ता लॉगिन किंवा पासवर्ड सारखा कनेक्शनद्वारे पाठविला जाणारा सर्व डेटा मिळवू शकतो. दुर्दैवाने, सराव दर्शविते की जर वापरकर्त्यास बनावट प्रमाणपत्र स्वीकारण्याची संधी असेल तर तो त्याचा फायदा घेईल.

SMTP आणि IMAP सर्व्हर का आणि वापरकर्ते कशाने सेव्ह केले

बहुतेक वापरकर्ते HTTPS ब्राउझरद्वारे त्यांचे मेल ऍक्सेस करत असले तरी हल्लेखोरांनी ईमेल ऍप्लिकेशन्सच्या SMTP/IMAP ट्रॅफिकमध्ये अडथळा आणण्याचा प्रयत्न का केला, वेब ट्रॅफिक नाही?

SMTP आणि IMAP/POP3 द्वारे कार्य करणारे सर्व ईमेल प्रोग्राम वापरकर्त्यास त्रुटींपासून संरक्षण देत नाहीत, त्याला असुरक्षित किंवा तडजोड कनेक्शनद्वारे लॉगिन आणि पासवर्ड पाठविण्यापासून प्रतिबंधित करतात, जरी मानकांनुसार आरएफसी 8314, 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 कॅशेमध्ये निष्क्रिय इंजेक्शनची शक्यता दूर करणार नाही. कॉर्पोरेट वापरकर्त्यांचे संरक्षण करण्यासाठी ISP ने हे पोर्ट त्यांच्या नेटवर्कवर फिल्टर केले पाहिजे. 

बदली प्रमाणपत्र स्वीकारलेल्या सर्व वापरकर्त्यांनी ईमेल आणि इतर सेवांचा पासवर्ड तातडीने बदलला पाहिजे ज्यासाठी हे प्रमाणपत्र स्वीकारले आहे. आमच्या भागासाठी, आम्ही असुरक्षित उपकरणांद्वारे मेलमध्ये प्रवेश करणार्‍या वापरकर्त्यांना सूचित करू.

P.S. पोस्टमध्ये वर्णन केलेली संबंधित भेद्यता देखील आहे लुकासाफोनोव "RouterOS मधील बॅकपोर्ट असुरक्षा शेकडो हजारो उपकरणांना धोका निर्माण करते".

स्त्रोत: www.habr.com