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 почта серверлери колдойт) жана ансыз логин жана сырсөз ар бир сессияда өткөрүлүп берилет.
Браузерлер Ортодогу Адамдын чабуулдарынан бир аз жакшыраак корголушу мүмкүн. Бардык 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 кэшине пассивдүү киргизүү мүмкүнчүлүгүн жокко чыгарбаса да, көйгөйдү эксплуатациялоону кыйындатат. Провайдерлер корпоративдик колдонуучуларды коргоо үчүн бул портту өз тармактарында чыпкалашы керек.
Алмаштырылган сертификатты кабыл алган бардык колдонуучулар электрондук почтанын жана бул сертификат кабыл алынган башка кызматтардын сырсөзүн тез арада өзгөртүүсү керек. Биз өз тарапыбыздан аялуу түзмөктөр аркылуу почтага кирген колдонуучуларга кабарлайбыз.
P.S. Постто сүрөттөлгөн тиешелүү алсыздык да бар "".
Source: www.habr.com