Martxoaren 10eko arratsaldean, Mail.ru laguntza zerbitzua erabiltzaileen kexak jasotzen hasi zen posta elektronikoko programen bidez Mail.ru IMAP/SMTP zerbitzarietara konektatzeko ezintasunagatik. Aldi berean, konexio batzuk ez ziren pasatu, eta beste batzuek ziurtagiri-errore bat erakusten dute. Errorea "zerbitzariak" berez sinatutako TLS ziurtagiria jaulkitzeak eragiten du.
Bi egunetan, 10 kexa baino gehiago iritsi ziren hainbat saretako eta hainbat gailutako erabiltzaileen aldetik, eta zaila zen arazoa hornitzaile baten sarean egotea. Arazoaren azterketa zehatzago batek agerian utzi zuen imap.mail.ru zerbitzaria (baita beste posta zerbitzari eta zerbitzu batzuk ere) DNS mailan ordezkatzen ari direla. Gainera, gure erabiltzaileen laguntza aktiboarekin, arrazoia beren bideratzailearen cachean sarrera oker bat zela ikusi genuen, hau ere tokiko DNS konpontzailea dena, eta kasu askotan (baina ez guztietan) MikroTik izan zela. gailua, oso ezaguna den sare korporatibo txikietan eta Interneteko hornitzaile txikietan.
Zein da arazoa
2019ko irailean, ikertzaileak MikroTik RouterOS-en hainbat ahultasun (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), DNS cachearen pozoitze-erasoa ahalbidetu dutenak, hau da. bideratzailearen DNS cachean DNS erregistroak faltifikatzeko gaitasuna, eta CVE-2019-3978-k aukera ematen dio erasotzaileari ez itxaron behar barne-sareko norbaitek bere DNS zerbitzarian sarrera bat eskatzeko ebazteko cachea pozoitzeko, baizik eta abiarazteko. eskaera bat berak 8291 atakaren bidez (UDP eta TCP). Ahultasuna MikroTik-ek konpondu zuen RouterOS 6.45.7 (egonkorra) eta 6.44.6 (epe luzerako) bertsioetan 28ko urriaren 2019an, baina arabera Erabiltzaile gehienek ez dute adabakirik instalatu.
Bistakoa da arazo hau "zuzenean" aktiboki ustiatzen ari dela.
Zergatik da arriskutsua
Erasotzaileak barne sarean erabiltzaile batek atzitzen duen edozein ostalariren DNS erregistroa faltifika dezake, eta, horrela, bertarako trafikoa atzematen du. Informazio sentikorra enkriptatu gabe transmititzen bada (adibidez, http://-ren bidez TLS gabe) edo erabiltzaileak ziurtagiri faltsu bat onartzea onartzen badu, erasotzaileak konexioaren bidez bidaltzen dituen datu guztiak lor ditzake, hala nola saio-hasiera edo pasahitza. Zoritxarrez, praktikak erakusten du erabiltzaile batek ziurtagiri faltsu bat onartzeko aukera badu, aprobetxatuko duela.
Zergatik SMTP eta IMAP zerbitzariak, eta zerk salbatu zituen erabiltzaileak
Zergatik saiatu ziren erasotzaileak posta elektronikoko aplikazioen SMTP/IMAP trafikoa atzematen, eta ez web trafikoa, nahiz eta erabiltzaile gehienek beren posta HTTPS arakatzailearen bidez sartzen diren?
SMTP eta IMAP/POP3 bidez lan egiten duten posta elektronikoko programa guztiek ez dute erabiltzailea akatsetatik babesten, eta horrek saio-hasiera eta pasahitza bidaltzea eragozten dio segurtasunik gabeko edo arriskuan dagoen konexio baten bidez, nahiz eta estandarraren arabera. , 2018an onartua (eta Mail.ru-n askoz lehenago inplementatua), erabiltzailea babestu behar dute pasahitza atzematetik seguru gabeko edozein konexioren bidez. Gainera, OAuth protokoloa oso gutxitan erabiltzen da posta elektronikoko bezeroetan (Mail.ru posta-zerbitzariek onartzen dute), eta hori gabe, saio bakoitzean saio-hasiera eta pasahitza transmititzen dira.
Baliteke nabigatzaileak apur bat hobeto babestuta egotea Man-in-the-Middle-en erasoetatik. Mail.ru domeinu kritiko guztietan, HTTPS gain, HSTS (HTTP strict transport security) politika gaituta dago. HSTS gaituta, arakatzaile moderno batek ez dio erabiltzaileari ziurtagiri faltsu bat onartzeko aukera errazik ematen, erabiltzaileak nahi badu ere. HSTSaz gain, erabiltzaileak salbatu ziren 2017az geroztik, Mail.ru-ren SMTP, IMAP eta POP3 zerbitzariek segurtasun gabeko konexio baten bidez pasahitzak transferitzea debekatzen dutelako, gure erabiltzaile guztiek TLS erabiltzen zuten SMTP, POP3 eta IMAP bidez sartzeko, eta beraz, saio-hasiera eta pasahitzak atzeman ditzakete erabiltzaileak berak faltsututako ziurtagiria onartzen badu soilik.
Mugikorrentzako erabiltzaileentzat, beti gomendatzen dugu Mail.ru aplikazioak erabiltzea posta atzitzeko, izan ere... posta elektronikoarekin lan egitea seguruagoa da nabigatzaileetan edo SMTP/IMAP bezero integratuak baino.
Zer egin
Beharrezkoa da MikroTik RouterOS firmwarea bertsio seguru batera eguneratzea. Arrazoiren batengatik hori ezinezkoa bada, 8291 atakan (tcp eta udp) trafikoa iragaztea beharrezkoa da, horrek arazoaren ustiapena zaildu egingo du, nahiz eta DNS cachean injekzio pasiboa egiteko aukera ezabatuko. ISPek ataka hau iragazi beharko lukete sareetan, erabiltzaile korporatiboak babesteko.
Ordeztutako ziurtagiria onartu duten erabiltzaile guztiek premiaz aldatu beharko dute posta elektronikoaren eta ziurtagiri hau onartu zen beste zerbitzu batzuen pasahitza. Gure aldetik, gailu ahulen bidez posta elektronikora sartzen diren erabiltzaileei jakinaraziko diegu.
PS Mezuan deskribatutako ahultasun bat ere badago "".
Iturria: www.habr.com