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 жылдан бастап Mail.ru сайтының SMTP, IMAP және POP3 серверлері құпия сөздерді қорғалмаған қосылым арқылы беруге тыйым салатындығымен сақталды; біздің барлық пайдаланушылар SMTP, POP3 және IMAP арқылы кіру үшін TLS пайдаланды, және сондықтан пайдаланушының өзі жалған сертификатты қабылдауға келіскен жағдайда ғана логин мен құпия сөзді ұстай алады.
Ұялы телефон пайдаланушылары үшін поштаға қол жеткізу үшін әрқашан Mail.ru қолданбаларын пайдалануды ұсынамыз, себебі... олардағы поштамен жұмыс браузерлерге немесе кірістірілген SMTP/IMAP клиенттеріне қарағанда қауіпсіз.
Не істеу керек
MikroTik RouterOS микробағдарламасын қауіпсіз нұсқаға жаңарту қажет. Егер қандай да бір себептермен бұл мүмкін болмаса, 8291 портында (tcp және udp) трафикті сүзгілеу қажет болса, бұл DNS кэшіне пассивті енгізу мүмкіндігін жоймаса да, мәселені пайдалануды қиындатады. ISP корпоративтік пайдаланушыларды қорғау үшін өз желілерінде осы портты сүзуі керек.
Ауыстырылған сертификатты қабылдаған барлық пайдаланушылар осы сертификат қабылданған электрондық пошта және басқа қызметтер үшін құпия сөзді шұғыл өзгертуі керек. Біз өз тарапымыздан осал құрылғылар арқылы поштаға кіретін пайдаланушыларды хабардар етеміз.
PS Сондай-ақ постта сипатталған қатысты осалдық бар "".
Ақпарат көзі: www.habr.com