Aktualizujte RouterOS na vašem MikroTiku

Aktualizujte RouterOS na vašem MikroTiku
Večer 10. března začala podpůrná služba Mail.ru přijímat stížnosti uživatelů na nemožnost připojení k serverům Mail.ru IMAP/SMTP prostřednictvím e-mailových programů. Zároveň některá připojení neprošla a některá vykazují chybu certifikátu. Chyba je způsobena tím, že "server" vydává certifikát TLS s vlastním podpisem.
 
Aktualizujte RouterOS na vašem MikroTiku
Během dvou dnů přišlo více než 10 stížností od uživatelů v nejrůznějších sítích a s různými zařízeními, takže je nepravděpodobné, že by problém byl v síti kteréhokoli poskytovatele. Podrobnější analýza problému odhalila, že server imap.mail.ru (stejně jako další poštovní servery a služby) je nahrazován na úrovni DNS. Dále jsme za aktivní pomoci našich uživatelů zjistili, že důvodem byl nesprávný záznam v mezipaměti jejich routeru, který je zároveň lokálním DNS resolverem a který se v mnoha (ale ne ve všech) případech ukázal jako MikroTik. zařízení, velmi oblíbené v malých podnikových sítích a od malých poskytovatelů internetu.

Jaký je problém?

V září 2019 výzkumníci nalezeno několik zranitelností v MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), které umožňovaly útok DNS cache poisoning, tzn. schopnost zfalšovat záznamy DNS v mezipaměti DNS routeru a CVE-2019-3978 umožňuje útočníkovi nečekat, až někdo z interní sítě požádá o záznam na jeho serveru DNS, aby otrávil mezipaměť překladače, ale iniciovat takové požadavek sám přes port 8291 (UDP a TCP). Zranitelnost byla opravena společností MikroTik ve verzích RouterOS 6.45.7 (stabilní) a 6.44.6 (dlouhodobá) 28. října 2019, ale podle výzkum Většina uživatelů aktuálně nemá nainstalovány záplaty.

Je zřejmé, že tento problém je nyní aktivně využíván „v přímém přenosu“.

Proč je to nebezpečné

Útočník může podvrhnout záznam DNS libovolného hostitele, ke kterému přistupuje uživatel v interní síti, a zachycovat tak provoz na něj. Pokud jsou citlivé informace přenášeny bez šifrování (například přes http:// bez TLS) nebo uživatel souhlasí s přijetím falešného certifikátu, může útočník získat všechna data, která jsou odesílána prostřednictvím připojení, jako je přihlašovací jméno nebo heslo. Bohužel praxe ukazuje, že pokud má uživatel možnost přijmout falešný certifikát, využije toho.

Proč servery SMTP a IMAP a co zachránilo uživatele

Proč se útočníci pokusili zachytit SMTP/IMAP provoz e-mailových aplikací, a ne webový provoz, ačkoli většina uživatelů přistupuje k poště přes HTTPS prohlížeč?

Ne všechny e-mailové programy pracující přes SMTP a IMAP/POP3 chrání uživatele před chybami a brání mu v odeslání přihlašovacího jména a hesla přes nezabezpečené nebo kompromitované připojení, ačkoliv podle standardu RFC 8314, přijaté již v roce 2018 (a implementované v Mail.ru mnohem dříve), musí chránit uživatele před zachycením hesla prostřednictvím jakéhokoli nezabezpečeného připojení. Kromě toho se protokol OAuth v e-mailových klientech používá velmi zřídka (je podporován poštovními servery Mail.ru) a bez něj se přihlašovací jméno a heslo přenášejí v každé relaci.

Prohlížeče mohou být o něco lépe chráněny proti útokům typu Man-in-the-Middle. Ve všech kritických doménách mail.ru je kromě HTTPS povolena zásada HSTS (přísné zabezpečení přenosu HTTP). S povoleným HSTS moderní prohlížeč nedává uživateli snadnou možnost přijmout falešný certifikát, i když uživatel chce. Kromě HSTS byli uživatelé zachráněni tím, že od roku 2017 servery SMTP, IMAP a POP3 Mail.ru zakazují přenos hesel přes nezabezpečené připojení, všichni naši uživatelé používali TLS pro přístup přes SMTP, POP3 a IMAP a proto může být přihlašovací jméno a heslo zachyceno pouze v případě, že uživatel sám souhlasí s přijetím podvrženého certifikátu.

Pro mobilní uživatele vždy doporučujeme pro přístup k poště používat aplikace Mail.ru, protože... práce s poštou v nich je bezpečnější než v prohlížečích nebo vestavěných SMTP/IMAP klientech.

Co dělat

Firmware MikroTik RouterOS je nutné aktualizovat na zabezpečenou verzi. Pokud to z nějakého důvodu není možné, je nutné filtrovat provoz na portu 8291 (tcp a udp), tím se zkomplikuje využití problému, i když to nevyloučí možnost pasivního vkládání do DNS cache. Poskytovatelé internetových služeb by měli tento port ve svých sítích filtrovat, aby ochránili firemní uživatele. 

Všichni uživatelé, kteří přijali nahrazený certifikát, by si měli urychleně změnit heslo pro e-mail a další služby, pro které byl tento certifikát akceptován. Z naší strany budeme informovat uživatele, kteří přistupují k poště přes zranitelná zařízení.

PS V příspěvku je také popsána související zranitelnost LukaSafonov "Zranitelnost backportu v RouterOS ohrožuje stovky tisíc zařízení".

Zdroj: www.habr.com

Přidat komentář