Dostali jste někdy e-mail od šéfa s urgentní žádostí o proplacení faktury? Nebo zprávu od vaší banky, která vypadala o vlásek jinak než obvykle? Pravděpodobně jste se setkali s e-mail spoofingem – jednou z nejčastějších a nejnebezpečnějších technik kybernetických útoků. Nejde o žádnou magii, ale o zneužití desítky let starého designu e-mailu.
E‑mail je základní komunikační nástroj internetu. Zároveň také technologie, která se používá už přes 40 let. Vznikl v době, kdy internet byl akademickou sítí několika univerzit a výzkumných institucí. Celý systém stál na vzájemné důvěře, zatímco bezpečnost zůstávala v pozadí.
Základním protokolem pro přenos pošty je SMTP (Simple Mail Transfer Protocol), popsaný v roce 1982 ve specifikaci RFC 821 (později několikrát upraven do podoby, ve které jej využíváme dnes, viz specifikace RFC 5321 z roku 2008). Tento protokol byl navržen tak, aby byl co nejjednodušší: server přebírá zprávy od klienta a doručuje je dál. Adresa odesílatele se v SMTP zadává čistě textově v příkazu MAIL FROM, aniž by probíhala jakákoli kontrola, zda má klient na uvedenou adresu skutečně právo. Je to jako poslat dopis a na obálku napsat libovolnou zpáteční adresu – pošťák ho doručí.
Vysvětlení na příkladu pošty:
E‑mail má dvě adresy. Jednu na "obálce" (envelope sender, MAIL FROM), kterou používají servery pro doručení a není na první pohled vidět, Druhou v "hlavičce dopisu" (adresa From:), kterou vidí příjemce e‑mailu ve své doručené poště. Útočník může do pole "From:" napsat adresu ředitele vaší firmy, i když "obálková" adresa vede na jeho často anonymní server.
V 80. letech to byla výhoda – jednoduchost umožnila, že protokol mohl běžet na široké škále strojů a sítí. Zároveň ale platí, že původní SMTP bylo zcela textové, a tudíž náchylné i k útokům typu man‑in‑the‑middle, kdy mohl útočník komunikaci po cestě změnit a podvrhnout.
Aby se toto riziko omezilo, vzniklo rozšíření STARTTLS, které přidává šifrování na úrovni přenosu. V praxi ale dlouho fungovalo jen jako tzv. opportunistic encryption – pokud se obě strany dohodly na šifrované komunikaci, použila se, pokud ne, spojení pokračovalo nešifrovaně. To znamenalo, že útočník mohl šifrování prostě „shodit“ (STRIPTLS attack) a komunikace probíhala dál v otevřeném textu. Moderní přístup proto vyžaduje implicitní TLS (Transport Layer Security), tedy povinné šifrování, které zabrání doručení zprávy, pokud se šifrované spojení nepodaří navázat.
I zde je ale zásadní držet se aktuálních doporučení a pravidelně přecházet na modernější způsoby zabezpečení – protože se z původní jednoduchosti SMTP stává v dnešní době zásadní slabina.
Aby se tento problém alespoň částečně řešil, vznikly až později nadstavby a doplňkové technologie jako SPF, DKIM a DMARC, které mají dodatečně kontrolovat, zda je zpráva autentická. Tyto mechanismy ale nejsou všude plně zavedené nebo se dají obejít, a proto je i dnes možné poslat e‑mail, který se tváří, že pochází od důvěryhodné domény – i když odesílatel s ní nemá nic společného. To je přesně podstata e‑mail spoofingu.
Ve výše zmíněné komunikaci lze do příkazu MAIL FROM zapsat libovolnou adresu – třeba info@mojebanka.cz. Pokud SMTP server není chráněn, může takovou zprávu přijmout a doručit dál – správně nakonfigurovaný server ji ale odmítne nebo označí jako nedůvěryhodnou. Pokud doména mojebanka.cz nemá správně nastavené ověřovací mechanismy (např. SPF nebo DMARC), příjemcův server nemá možnost ověřit, zda je zpráva legitimní. Ukázkový příklad navíc využívá jednu z bezpečnostních děr - tzv. open relay. To nastává, když je přijímací SMTP server špatně nakonfigurován a umožňuje komukoli posílat poštu „přes sebe“ kamkoli. Neomezuje se jen na své uživatele nebo vlastní domény, ale přeposílá zprávy i pro úplně cizí adresy, což z něj v podstatě dělá volně dostupný spamovací stroj.
Dnešní SMTP komunikace je složitější a obsahuje nadstavby, které zvyšují zabezpečení přenosové vrstvy, např. autorizace a výše zmíněný implicitní TLS nebo nahrazení příkazu HELO za bezpečnější EHLO. Je ale klíčové dbát na jejich správnou konfiguraci a držet krok s aktuálními doporučeními.
Manipulace s hlavičkou From: nebo Reply-To: v samotné zprávě. To je adresa, kterou vidí uživatel v e‑mailovém klientovi.
Adresu nechá útočník beze změny, ale změní jméno, např.:
From: "Česká pošta" <hacker@free-mail.com>
Uživatel často vidí jen jméno odesílatele a adrese nevěnuje pozornost.
Registrace domén, které vypadají velmi podobně (paypal.com vs. paypaI.com – druhé s velkým i místo l). Nebo využití Unicode znaků (např. cyrilice, která vizuálně připomíná latinku). Tyto domény se v DNS zapisují pomocí tzv. Punycode (xn--...), takže na technické úrovni jsou odlišitelné. V praxi se ale uživateli často zobrazují v „čitelné“ podobě, kde rozdíl není na první pohled patrný – a proto je nelze vždy snadno odhalit pouhým okem.
Pokud útočník získá přístup k reálnému účtu jeho e‑maily vypadají stoprocentně legitimně a projdou všemi kontrolami. U účtů vázaných na organizaci nebo společnost se často jedná o tzv. BEC (Business Email Compromise). Útočníci cíleně oslovují interní zaměstnance s žádostmi o převod finančních prostředků, sdílení citlivých informací nebo provedení akcí, které mohou společnosti způsobit nemalou škodu. Podle zprávy FBI způsobily BEC útoky v roce 2023 ztráty přes 2.9 miliardy dolarů.
V případě otevřeného SMTP relay může útočník odesílat e‑maily přes cizí server. Tyto zprávy mohou vypadat důvěryhodně, ale příjemce může odhalit podvržení kontrolou SPF – pokud IP adresa serveru není povolená pro doménu uvedenou v MAIL FROM, může být e‑mail označen jako podezřelý nebo odmítnut.
Útok, při kterém útočník zachytí legitimní e‑mail z důvěryhodné schránky a přeposláním zneužije jeho DKIM podpis. Příjemce tak může být oklamán, že zpráva pochází od důvěryhodného odesílatele. Často se využívá pro phishing nebo rozesílání malware.
Relativně nová technika, která zneužívá rozdílné interpretace SMTP příkazů mezi jednotlivými servery a dokáže obejít i správně nastavený DMARC. Útočník tím „propašuje“ druhou, skrytou zprávu přes první server – přestože by ji za běžných okolností odmítl.
Pokud organizace zruší službu, ale zapomene odstranit DNS záznam (např. subdoména stále míří na neexistující server), může útočník tuto doménu znovu zaregistrovat nebo převzít kontrolu nad jejím hostitelem. Tím získá možnost odesílat poštu za legitimní subdoménu – a SPF validace projde.
Pokud má firma e‑maily hostované na sdílené infrastruktuře (např. stejný e‑mailový server pro více zákazníků), může útočník využít toho, že SPF záznam povoluje IP adresu celého hostingu. Útočník, který má na stejném serveru vlastní doménu, pak může posílat poštu i za jinou doménu ze stejné IP. SPF to vyhodnotí jako platné.
👉 Poslední dva scénáře (DNS dangling a IP overlap) jsou zvlášť nebezpečné, protože útoky technicky projdou SPF validací a odhalí je až kombinace s DKIM/DMARC nebo důsledné monitorování.
U některých e‑mailů lze podvržení poznat na první pohled – například podle podezřelého jména odesílatele nebo gramatiky zprávy. U lépe provedených zpráv je však nutné podívat se do e‑mailové hlavičky, kde se skrývá skutečná data o původu a cestě zprávy.
Když otevřete e‑mail, vidíte jen část reality. Skutečná data jsou v hlavičkách. Ty obsahují mj.:
Příklad části hlavičky:
Received‑SPF: Fail (gmail.com: domain of info@mojebanka.cz does not designate 185.12.34.56 as permitted sender)
Authentication-Results: dkim=fail; spf=fail; dmarc=fail
Pokud je vidět spf=fail nebo dmarc=fail, jde velmi pravděpodobně o spoofing. U DNS dangling nebo IP overlap ale může SPF projít – proto je důležité, aby byla nasazena kombinace všech tří metod. Výborným pomocníkem pro analýzu hlavičky je například nástroj MXToolbox.
SPF (Sender Policy Framework)
SPF funguje jako seznam povolených odesílacích serverů. V DNS záznamech domény se definuje, které servery mají oprávnění posílat e‑maily jejím jménem. Kontrola se přitom obvykle provádí na technické adrese uvedené v poli MAIL FROM (envelope sender nebo také odesílatel obálky), nikoli na adrese, kterou vidí uživatel v poli From:. Pokud přijde zpráva z jiné IP adresy, přijímající server ji může vyhodnotit jako podezřelou. Samotné SPF ale nestačí – útočníci ho dokáží obejít například při přeposílání. Navíc je potřeba hlídat limit 10 DNS lookups (dotazů) - jejich překročení vede k selhání SPF validace.
SPF Alignment (SPF zarovnání)
SPF Alignment kontroluje, zda doména v poli MAIL FROM souhlasí s doménou zobrazenou v adrese From:, kterou vidí uživatel. Pokud jsou domény odlišné, e‑mail může projít SPF, ale působit podvrženě. Správné zarovnání zvyšuje účinnost DMARC a chrání proti spoofingu tím, že zajišťuje konzistenci mezi skutečným odesílatelem a viditelnou adresou.
DKIM (DomainKeys Identified Mail)
DKIM přidává do odchozí zprávy digitální podpis, který je navázaný na konkrétní doménu definovanou v klíči samotném. Příjemce si podpis ověří pomocí veřejného klíče uloženého v DNS. Pokud se někdo pokusí zprávu cestou pozměnit, podpis přestane sedět a zpráva se odhalí jako podvržená. Je důležité DKIM správně definovat (např. v parametru h= vymezit, co všechno se má kontrolovat), alespoň zdvojit (kvůli DKIM reply útokům) a pravidelně obměňovat - doporučuje se alespoň 2x za rok. V současné době je totiž už možné kratší DKIM klíče hrubou silou prolomit. Mějte klíče o délce alespoň 2048 bitů.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC propojuje SPF a DKIM a dává doménovému správci možnost říct, co se má se zprávami stát, když neprojdou kontrolou – zda je jen reportovat (p=none), přesunout do spamu (p=quarantine), nebo rovnou odmítnout (p=reject).
Kontrola DMARC vyžaduje, aby byla aspoň jedna shoda v doméně SPF (tj. MAIL FROM) nebo v doméně DKIM klíče s doménou, která je uvedené ve viditelném From:.
Příklad:
Nejlepší je pochopitelně poslední nastavení, kdy je dosažen tzv. “full-domain” alignment, tj. jsou shodné všechny použité domény - v tuto chvíli je největší pravděpodobnost, že odeslaný e‑mail je opravdu legitimní a váš.
Nejvyšší ochranu zajistí nastavení p=reject, jeho přímé nastavení je ale vhodné pouze na nových doménách. Pokud nastavujete DMARC na již zavedené doméně, je vhodné postupovat opatrně, začít na p=none a politiku postupně zpřísňovat přes p=quarantine až k p=reject a pohyb na doméně podrobně hlídat.
DMARC navíc umožňuje dostávat reporty o podezřelých zprávách, takže správce domény má přehled o pohybu na doméně. Pro jednodušší zpracování reportů je možné využít služeb jako je DMARC Advisor, dmarcian, Valimail nebo Mailkit.
Od února 2024 zavedli hlavní poskytovatelé e‑mailových schránek jako Google a Yahoo nová, přísnější pravidla pro odesílatele hromadné pošty. To, co bylo dříve jen doporučením, se stalo povinností. Pokud posíláte více než 5 000 e‑mailů denně na jejich adresy, tyto požadavky se vás přímo týkají. Ignorovat je znamená riskovat, že vaše e‑maily nebudou vůbec doručeny. A mezi hlavní požadavky patří právě povinný DMARC.
Pravidelný úklid DNS záznamů
V DNS se mohou objevit neaktuální nebo nepoužívané záznamy – například po starém mailovém serveru či dříve využívané cloudové službě. Takové záznamy otevírají prostor pro útoky typu DNS dangling. Pravidelná kontrola a odstraňování neplatných záznamů proto představuje důležitou prevenci.
Vlastní dedikovaný hosting
Pokud doména sdílí stejnou IP adresu se stovkami dalších zákazníků (což je běžné u levného hostingu), existuje riziko tzv. IP overlap spoofingu. Dedikovaný server nebo cloudové řešení s vlastní IP adresou tento problém eliminuje.
BIMI (Brand Indicators for Message Identification)
BIMI umožňuje zobrazit vedle e‑mailu v inboxu logo odesílající značky. K jeho použití musí být zpráva chráněna platným DMARC nastavením (doporučeně quarantine nebo reject). Díky BIMI uživatel okamžitě vidí, že e‑mail pochází od ověřené značky, což usnadňuje rozpoznání podvržených zpráv a snižuje riziko phishingu. Bohužel v současné době je BIMI vázáno na placené certifikáty a ne vždy se v inboxu zobrazí.
Nespoléhat jen na to, že e‑mail „prošel“ filtrem.
Antispamové a bezpečnostní filtry jsou velmi účinné, ale neomylné nejsou. Sofistikované útoky, zejména cílené spear‑phishing kampaně, dokážou filtrem projít. Pokud se e‑mail tváří podezřele – i když nepadl do spamu – je lepší zpozornět a chovat se obezřetně.
Ověřovat odkazy a přílohy.
Útočníci se často snaží nalákat uživatele na podvržené odkazy nebo škodlivé přílohy. Kliknutí na odkaz, který vede na podvodnou stránku, nebo otevření nebezpečného souboru, může vést k odcizení přihlašovacích údajů či instalaci malwaru. Bezpečnější je vždy se podívat na skutečnou URL adresu, např. najet na odkaz myší (bez kliknutí). Pozor však na zkracovače (url shorteners) a trackované odkazy – i když odkaz může vypadat podivně, nemusí být nutně škodlivý, proto je třeba ověřovat cílovou stránku opatrně.
Nezapomínejte na lokální antiviry
Moderní antiviry často obsahují ochranu prohlížeče a internetový štít, takže i po kliknutí na škodlivý odkaz dokážou zablokovat nebezpečnou stránku a zabránit útoku.
Při pochybnostech ověřit zprávu alternativním kanálem.
Pokud e‑mail vypadá, že přišel od kolegy, banky nebo partnera, ale obsahuje nestandardní požadavek (například poslat peníze, sdílet heslo či otevřít nečekanou přílohu), vyplatí se ověřit pravost jinak. Stačí zvednout telefon, napsat SMS, případně kontaktovat oficiální podporu.
Kontrolovat hlavičky e‑mailu.
Pro technicky zdatnější uživatele je užitečné podívat se na tzv. e‑mailové hlavičky. V nich lze zjistit skutečného odesílatele a cestu, kterou zpráva prošla. Pokud se liší „From“ adresa od „Return-Path“ nebo jsou v hlavičkách vidět podezřelé servery, může jít o podvrh. Mnoho poštovních klientů také ukazuje, zda zpráva prošla ověřením SPF, DKIM a DMARC – to je další vodítko k odhalení spoofingu.
Budoucnost e‑mailu bude vždy částečně o kompromisu – na jedné straně otevřený a univerzální protokol, na druhé straně tlak na bezpečnost. A protože samotné SMTP se už zásadně měnit nebude, zůstává na nás, abychom mu „doplňovali brnění“ v podobě SPF, DKIM a DMARC. Správně nastavené a pravidelně kontrolované záznamy v DNS dnes rozhodují o tom, zda útočník pošle zprávu cizím jménem, nebo skončí na spamovém hřbitově. Není to jednorázový úkol – bezpečnostní standardy se vyvíjejí, stejně jako útoky, které se je snaží obejít.
Pokud se má e‑mail udržet jako spolehlivý komunikační nástroj i do dalších dekád, bude to právě díky tomu, že správci a organizace budou brát ochranné mechanismy vážně, udržovat je aktuální a učit uživatele, proč na nich záleží. E‑mail možná nevznikl s myšlenkou bezpečnosti, ale bezpečnost bude rozhodovat o jeho budoucnosti.
BEC (Business Email Compromise)
Útok, při kterém útočník získá přístup k reálné schránce nebo se za ni důvěryhodně vydává. Často zneužíván k finančním podvodům.
BIMI (Brand Indicators for Message Identification)
Standard umožňující zobrazovat logo značky přímo v inboxu. Funguje jen tehdy, pokud má doména správně nasazený DMARC s politikou quarantine nebo reject.
DKIM (DomainKeys Identified Mail)
Mechanismus, který e-mail podepisuje digitálním podpisem. Příjemce ověřuje podpis pomocí veřejného klíče uloženého v DNS, čímž se zajistí integrita zprávy.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Nadstavba SPF a DKIM, která umožňuje doméně nastavit politiku (označit, přesunout, odmítnout) pro zprávy, které testy neprojdou. Zlepšuje také viditelnost díky reportům.
DNS (Domain Name System)
Telefonní seznam internetu – převádí čitelné doménové názvy (např. example.com) na IP adresy. Zároveň slouží jako úložiště záznamů pro SPF, DKIM nebo DMARC.
From:
Pole v hlavičce e-mailu, které vidí příjemce jako odesílatele. Snadno se podvrhává.
Hlavička e-mailu (e-mail header)
Soubor technických informací připojených ke zprávě (např. From, To, Subject, Received). Obsahuje metadata o cestě e-mailu a jeho odesílateli.
MAIL FROM (envelope sender)
Technická adresa odesílatele uvedená v tzv. SMTP obálce. Slouží k doručování a ke kontrole SPF.
Open relay
Špatně nastavený e-mailový server, který bez omezení přeposílá zprávy komukoli. Útočníci jej mohou snadno zneužít ke spamování.
Return-Path
Pole, do kterého servery zapisují adresu uvedenou v MAIL FROM. Na tuto adresu se vrací chybová hlášení (bounce).
SMTP (Simple Mail Transfer Protocol)
Základní protokol pro přenos e-mailů mezi servery. Navržen v 80. letech, původně bez autentizace a zabezpečení.
SPF (Sender Policy Framework)
Mechanismus, který ověřuje, zda e-mail skutečně poslal server oprávněný doménou v DNS. Typicky se kontroluje proti adrese MAIL FROM.
TLS (Transport Layer Security)
Šifrovací protokol, který chrání komunikaci mezi servery (včetně SMTP). Zabraňuje odposlechu a manipulaci s přenášenými daty.