How to prevent the spread of backscatter emails by email servers of MU
Jak vzniká tento typ škodlivých e-mailů? Proč je potřeba jejich šíření zabránit a jak na to?
V čem je problém – první scénář
Backscatter e-maily vznikají tak, že útočník na e-mailový server pošle závadný e-mail, přičemž zfalšuje hlavičku těchto e-mailů tak, aby políčka From a Reply-To obsahovala e-mailovou adresu oběti. Po doručení této zprávy na e-mailový server a její detekci jeho spamovým či antimalverovým filtrem – nebo jiné příčině, kvůli které e-mail není možno doručit (například neplatná adresa příjemce) – tento e-mailový server zprávu “odrazí” (bounce) na adresu, která je v e-mailu uvedená jako odesílatel, což je v tomto případě oběť; případně e-mailový server pošle oběti notifikaci o nedoručení e-mailu. Obzvlášť v prvním případě útočník dosáhne svého cíle, ale stačit může i druhý případ. V některých případech může nastat, že tímto způsobem i jinak legitimní e-mailový server může skončit na spamových blacklistech.
Servery Masarykovy univerzity jsou na tuto zranitelnost bohužel citlivé, a právě tuto zranitelnost aktuálně využívá masová kampaň sextortion.
Jak to funguje?
Útočník jednoduše nastaví e-mailovou adresu oběti nejen jako odesílatele, ale také jako příjemce e-mailu, čímž u uživatele vyvolává dojem, že byl e-mail opravdu odeslaný z jeho účtu sobě samému. Pomocí této manipulace se snaží útočník oběť přesvědčit, že má plnou kontrolu nad jeho zařízením a v rámci toho jej v diskrétní chvíli natočil při sledování pornografického obsahu.
Uživatel se může nechat takto zmanipulovat i v případě, kdy dostane notifikaci o nedoručení e-mailu. E-mail byl přeci zablokován e-mailovým serverem, který není infikován a udělal to, co měl. Narativ útočníka, že má pod kontrolou počítač, potažmo e-mailovou schránku oběti, tím tolik neztrácí na uvěřitelnosti. Jindy je zfalšovaná adresa odesílatele neplatná, ale i v tomto případě pokus o “odražení” e-mailu představuje zbytečnou komunikační a výpočetní zátěž.
Jak prvnímu scénáři zabránit?
Velmi jednoduše – e-mailové servery je třeba překonfigurovat tak, aby e-maily, které jakýkoli filtr označí jako závadný, nezasílaly na adresu odesílatele až po jeho přijetí (bounce), ale odmítly (reject) je přímo při přijímaní. Toto odmítnutí e-mailový server provede během SMTP přenosu, dokud je spojení se skutečným odesílatelem závadného e-mailu stále otevřené – tedy ještě předtím, než vstoupí na e-mailový server. Toto odmítnutí může mít návratový kód 4xx pro dočasné odmítnutí (například „mailbox busy”) nebo 5xx pro trvalé odmítnutí (například „no such user”). [1] navrhuje návratový kód 554, [2] a [3] navrhují 550. Takto odmítnutí dostane pouze skutečně odesílající server, který by o tom měl upozornit svého lokálního odesílatele, obzvlášť jestli jde o legitimní e-mail. Spam často rozesílají boti, kteří ani neposlouchají.
Takhle elegantní řešení už po uzavření spojení se skutečně odesílajícím serverem není možné, a “odražení” (bounce) e-mailu je možné udělat pouze podle informací ve zfalšovaných hlavičkách e-mailu, co už problém pouze zhoršuje. Taktéž již poté není možné spolehlivě a bezpečně upozornit odesílatele na nedoručení e-mailu. I dle novějších RFC se nemají „odrážet” e-maily, u kterých není rozumná jistota, že “odražené” zprávy budou „užitečně doručeny” – samozřejmě, skutečnému odesílateli. Pro celý tento problém se stejně tak nedoporučuje používat automatické odpovědi na e-maily, nebo v případě nevyhnutelnosti jen za silným spamovým filtrem doplněným o kontrolu pověřenou osobou. To samé platí pro Challenge / Response – problém pouze přesouvají od příjemce na ty, kteří jsou falešně uvedeni jako odesílatelé závadných e-mailů, a navíc je lehké je zneužít a obejít. I používání těchto mechanizmů lehko může vést k tomu, že náš e-mailový server skončí na blacklistech.
Další detaily a rady, které považujeme za obzvlášť relevantní, naleznete v poslední sekci tohoto článku.
Druhý scénář
Existuje ale ještě záludnější scénář, který může vést k posílání backscatter závadných e-mailů – když má nějaký uživatel e-mailového serveru nastavené přeposílání pošty jinam. Pokud útočníkův e-mail detekuje až filtr na e-mailovém serveru třetí strany, ten jej odmítne, a náš e-mailový server informuje „původního odesílatele“ – tedy v tomto případě opět oběť – že doručení (závadného) e-mailu selhalo. Jelikož mezi přijetím e-mailu a jeho přeposláním je často zpoždění, není možné při přijímání e-mailu a rozhodování o jeho odmítnutí čekat na odpověď od e-mailového serveru třetí strany.
Jak zabránit druhému scénáři?
Jediný způsob, jak zabránit tomuto druhému scénáři, je být důsledný ve filtrování závadných e-mailů na našem serveru, abychom minimalizovali riziko, že závadný e-mail, který my přepošleme jinam, bude vrácený.
Další podrobnosti k řešení
Mnohé závadné e-maily je možné odfiltrovat jednodušeji než pokročilým spamovým filtrem typu SpamAssasin. Jde zejména o prověření, zda adresa odesílatele není na blacklistu, a zda byl e-mail odeslaný běžným e-mailovým klientem, ale i spousty dalších věcí. Příklady takovéto konfigurace Postfixu jsou v [1] a [3]. [1] doporučuje začínat filtry méně náročnými na výpočty, a hlavně komunikaci s jinými servery, a postupně jít k náročnějším, pokročilé filtry typu SpamAssasin či Bayesovo filtrování pak ponechat úplně na konec. Zpráva je nakonec přijata pouze pokud projde všemi filtry. Takto je možno dosáhnout maximální efektivity filtrování. [3] radí, jak je alespoň v některých případech možné detekovat zfalšovanou adresu odesílatele, a v poslední řadě načrtává, jak filtrovat notifikace od antivirových skenerů. [4] popisuje specifický případ celého tohoto problému.
Zdroje
[1] https://willem.com/blog/2019-09-10_fighting-backscatter-spam-at-server-level/ – velmi jednoduše vysvětlené s částkovým příkladem konfigurace Postfixu
[2] http://www.dontbouncespam.org/ – stránka z let 2007–2011, ale stále užitečná; podrobněji vysvětlené i s kontextem, obsahuje i rady na filtrování spamu, otestování správného chování konfigurovaného e-mailového serveru, i zjištění, či už je na blacklistech
[3] http://www.postfix.org/BACKSCATTER_README.html – starý článek v dokumentaci Postfixu; je zaměřený na praktické řešení tohoto problému v Postfixu
[4] https://serverfault.com/questions/792442/postfix-reject-not-bounce-unknown-virtual-aliases – popisuje řešení specifického případu tohoto problému v Postfixu – odmítání místo „odrážení” e-mailů směřujících na neznámé virtuální aliasy