आफ्नो 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 सर्भरहरू, र के बचत गरियो प्रयोगकर्ताहरू

किन आक्रमणकारीहरूले ईमेल अनुप्रयोगहरूको SMTP/IMAP ट्राफिक रोक्न प्रयास गरे, वेब ट्राफिक होइन, यद्यपि अधिकांश प्रयोगकर्ताहरूले HTTPS ब्राउजर मार्फत उनीहरूको मेल पहुँच गर्छन्?

SMTP र IMAP/POP3 मार्फत काम गर्ने सबै इमेल कार्यक्रमहरूले प्रयोगकर्तालाई त्रुटिहरूबाट जोगाउँदैन, उसलाई असुरक्षित वा सम्झौता गरिएको जडान मार्फत लगइन र पासवर्ड पठाउनबाट रोक्छ, यद्यपि मानक अनुसार। RFC 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 क्यासमा निष्क्रिय इंजेक्शनको सम्भावनालाई हटाउने छैन। ISPs ले कर्पोरेट प्रयोगकर्ताहरूको सुरक्षा गर्न आफ्नो नेटवर्कमा यो पोर्ट फिल्टर गर्नुपर्छ। 

प्रतिस्थापित प्रमाणपत्र स्वीकार गर्ने सबै प्रयोगकर्ताहरूले तुरुन्तै इमेल र अन्य सेवाहरूको लागि पासवर्ड परिवर्तन गर्नुपर्छ जसको लागि यो प्रमाणपत्र स्वीकार गरिएको थियो। हाम्रो पक्षको लागि, हामी कमजोर उपकरणहरू मार्फत मेल पहुँच गर्ने प्रयोगकर्ताहरूलाई सूचित गर्नेछौं।

PS पोष्टमा वर्णन गरिएको एक सम्बन्धित जोखिम पनि छ लुकासाफोनोभ "RouterOS मा ब्याकपोर्ट कमजोरीले सयौं हजारौं उपकरणहरूलाई जोखिममा राख्छ".

स्रोत: www.habr.com