Մարտի 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-ին, սակայն համաձայն. Օգտատերերի մեծ մասը ներկայումս չի տեղադրել patches:
Ակնհայտ է, որ այս խնդիրն այժմ ակտիվորեն շահարկվում է «ուղիղ եթերում»։
Ինչու է դա վտանգավոր
Հարձակվողը կարող է խաբել ցանկացած հոսթի 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 սերվերներն արգելում են գաղտնաբառերի փոխանցումը անապահով կապի միջոցով, մեր բոլոր օգտվողներն օգտագործում էին TLS՝ SMTP, POP3 և IMAP-ի միջոցով մուտք գործելու համար, և հետևաբար, մուտքն ու գաղտնաբառը կարող են գաղտնալսել միայն այն դեպքում, եթե օգտվողն ինքը համաձայնի ընդունել կեղծված վկայականը:
Բջջային հեռախոսներից օգտվողներին խորհուրդ ենք տալիս միշտ օգտագործել Mail.ru հավելվածները փոստ մուտք գործելու համար, քանի որ... Դրանցում փոստի հետ աշխատելն ավելի անվտանգ է, քան բրաուզերներում կամ ներկառուցված SMTP/IMAP հաճախորդներում:
Ինչ անել
Անհրաժեշտ է թարմացնել MikroTik RouterOS որոնվածը անվտանգ տարբերակի: Եթե ինչ-ինչ պատճառներով դա հնարավոր չէ, անհրաժեշտ է զտել երթևեկությունը 8291 նավահանգստում (tcp և udp), դա կբարդացնի խնդրի շահագործումը, չնայած դա չի վերացնի DNS քեշի մեջ պասիվ ներարկման հնարավորությունը: ISP-ները պետք է զտեն այս պորտն իրենց ցանցերում՝ կորպորատիվ օգտատերերին պաշտպանելու համար:
Բոլոր օգտվողները, ովքեր ընդունել են փոխարինված վկայականը, պետք է շտապ փոխեն էլփոստի և այլ ծառայությունների գաղտնաբառը, որոնց համար ընդունվել է այս վկայագիրը: Մեր կողմից մենք կտեղեկացնենք օգտատերերին, ովքեր մուտք են գործում փոստ խոցելի սարքերի միջոցով:
Հ.Գ. Գրառման մեջ նկարագրված է նաև հարակից խոցելիություն "".
Source: www.habr.com