Antidatovanie emailu: čo je možné a čo je detekovateľné

Antidatovanie emailu: o čom presne hovoríme?

Táto otázka sa pravidelne objavuje na fórach systémových administrátorov a v Slack skupinách MSP: je možné po odoslaní emailu zmeniť jeho dátum? Krátka odpoveď je áno, technicky. Ale úplná odpoveď je oveľa menej upokojujúca pre kohokoľvek, kto by to chcel robiť na pochybné účely.

Email nie je monolitický súbor. Je to kolekcia textových hlavičiek, za ktorými nasleduje telo správy. Medzi týmito hlavičkami je niekoľko, ktoré obsahujú informácie o dátume. A niektoré sa menia ľahšie než iné.

V každom emaili koexistujú tri vrstvy datovania:

• Hlavička Date: (RFC 2822), ktorú píše poštový klient v čase odoslania
• Hlavičky Received:, pridávané každým serverom, ktorý správu preposúva
• IMAP INTERNALDATE, metadáta uložené na strane servera, nezávislé od obsahu správy

Každú z týchto vrstiev je možné upraviť. Žiadnu bez zanechania stôp.

Zmena hlavičky Date: najočividnejšia manipulácia

Hlavička Date: je čistý text v súbore .eml. Technicky ju dokáže prepísať ľubovoľný hex editor alebo Python skript za pár sekúnd. Ak ste niekedy otvorili nezmenené hlavičky emailu v Gmaile (malé menu "Zobraziť originál"), viete, že ich prečíta ktokoľvek.

Problém? Od roku 2004 podpisuje veľká väčšina mailových serverov odchádzajúce emaily pomocou DKIM (DomainKeys Identified Mail). Tento kryptografický podpis explicitne pokrýva niekoľko hlavičiek vrátane Date:, From:, Subject: a tela správy. Podpis je uložený v hlavičke DKIM-Signature:.

Zmena Date: po podpise mechanicky zneplatní overenie DKIM. Každý prijímací server môže podpis overiť získaním verejného kľúča z DNS domény odosielateľa. Ak podpis nesedí, správa je označená ako pozmenená. Gmail, Outlook.com a všetci veľkí poskytovatelia toto overenie vykonávajú automaticky.

(Mimochodom, ak chcete konkrétne vidieť DKIM podpis, otvorte nezmenené hlavičky emailu prijatého z Gmailu alebo Office 365: nájdete tam riadok DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., ktorý vyzerá ako šum, ale v skutočnosti je kryptografickým hashom celej správy.)

Výsledok: zmena Date: v DKIM podpísanom emaily znamená prelomenie pečate. Úprava je viditeľná pre každého administrátora, ktorý vie čo hľadať.

Prepísanie hlavičiek Received: reťazec, ktorý sa ťažko falšuje

Hlavičky Received: sledujú cestu, ktorú email prešiel od odosielateľa k príjemcovi. Každý SMTP server, ktorý sa správy dotkne, pridá jednu s názvom servera, IP adresou a časovou pečiatkou. Email, ktorý prechádza cez dva-tri relé, obsahuje dva-tri navrstvené hlavičky Received:.

Dajú sa upraviť? Technicky áno, na vlastnej kópii správy. Ale tu je pasca: príjemca má tiež kópiu. A jeho server pridal vlastnú hlavičku Received: ako poslednú. Táto hlavička je pod kontrolou príjemcu, nie odosielateľa. Z vonku ju nie je možné falšovať.

Konzistentnosť reťazca je overiteľná. Ak sú časové pečiatky po sebe idúcich Received: nekonzistentné (napríklad by intermediárne relé prijalo správu skôr, než ju odosielateľ odoslal), je to okamžite podozrivé. Nástroje na forenzickú analýzu emailov ako MXToolbox alebo interné nástroje bezpečnostných tímov overujú práve toto.

Vlastne to nie je úplne presné tvrdenie, že hlavičky Received: sa nedajú celkovo sfalšovať: útočník, ktorý kontroluje vlastnú poštovú infraštruktúru, môže vyrobiť dôveryhodné hlavičky pre relé, ktoré ovláda. Nikdy však nekontroluje posledný článok: server príjemcu.

IMAP INTERNALDATE: najtechnickejší prípad

INTERNALDATE je metadáta IMAP uložené na strane servera. Nie je to hlavička v samotnej správe: je to hodnota, ktorú server priradí správe vo svojej internej databáze. Práve túto hodnotu väčšina poštových klientov používa na triedenie správ v doručenej pošte.

Príkaz IMAP APPEND umožňuje uložiť správu na server s explicitne zadanou hodnotou INTERNALDATE. Je to legitímna funkcia protokolu, zdokumentovaná v RFC 3501. Migračné nástroje ju používajú neustále: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... všetky ukladajú emaily na cieľový server so zadanou hodnotou INTERNALDATE.

Teoreticky by niekto s prístupom IMAP k vlastnej schránke mohol uložiť email s ľubovoľnou hodnotou INTERNALDATE. Táto manipulácia však nemení hlavičky správy. Pôvodná hlavička Date: zostáva neporušená, hlavičky Received: zostávajú neporušené, DKIM podpis zostáva neporušený. Mení sa iba metadáta triedenia na strane servera.

Pre experta, ktorý preskúmava nezmenené správy, je nesúlad medzi INTERNALDATE a Date: okamžite viditeľný. A ak je správa podpísaná DKIM, pôvodný dátum je kryptograficky osvedčený.

Message-ID: odtlačok, ktorý sa ťažko falšuje

Každý email generuje unikátny identifikátor, hlavičku Message-ID:. Tento identifikátor vytvára odosielateľský SMTP server v čase odoslania, zvyčajne kombináciou časovej pečiatky, náhodného identifikátora a doménového názvu servera.

Typický Message-ID vyzerá takto: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Časová pečiatka je do identifikátora často priamo zakódovaná. Zmena dátumu správy pri zanechaní Message-ID s nekompatibilnou časovou pečiatkou vytvára nezrovnalosť, ktorú okamžite odhalíte.

Navyše, Message-ID sú indexované veľkými poštovými systémami. Google, Microsoft a ďalší aktéri vedú logy, ktoré umožňujú spätne sledovať, kedy správa skutočne prechádzala ich infraštruktúrou. V právnom alebo forenznom kontexte sú tieto logy dostupné prostredníctvom súdnych postupov.

V praxi: kto môže odhaliť pokus o manipuláciu?

Položme si otázku konkrétne. Dostanete email, o ktorom máte podozrenie, že mu bol zmenený dátum. Čo môže urobiť IT administrátor alebo právnik s minimálnou technickou výbavou?

• Overenie DKIM: v Gmaile menu "Zobraziť originál" zobrazuje priamo výsledok overenia DKIM v hornej časti stránky. "PASS" potvrdzuje integritu správy od odoslania. "FAIL" alebo "SOFTFAIL" signalizuje zmenu.
• Analýza hlavičiek: nástroje ako MXToolbox Header Analyzer alebo Google Admin Toolbox automaticky parsujú reťazec Received: a upozorňujú na časové nezrovnalosti.
• Konzistentnosť Message-ID a Date: analytik môže porovnať časovú pečiatku zakódovanú v Message-ID s hodnotou deklarovaného Date:.
• Serverové logy: ak email prechádzal serverom, ktorého ste administrátor, SMTP logy obsahujú skutočný dátum a čas prijatia správy, nezávisle od akejkoľvek hlavičky.

Skrátka, detekčné nástroje sú dostupné, zadarmo a nevyžadujú pokročilú forenzickú expertízu. Trochu zvedavý IT admin dokáže overiť integritu emailu za menej ako dve minúty.

Jediný legitímny prípad hromadnej zmeny dátumov: migrácia IMAP

Existuje scenár, kde sa stovky tisíc emailov ocitnú s nesprávnymi dátumami bez akéhokoľvek zlého úmyslu: migrácia IMAP.

Práve ste dokončili migráciu 150 Exchange schránok do Google Workspace. V pondelok ráno začínajú prichádzať tikety. Používatelia hlásia, že všetky ich staré emaily sa zobrazujú s rovnakým dátumom, tým z víkendu migrácie. Ich doručené schránky sú nečitateľné.

Čo sa stalo, je zdokumentované a predvídateľné: migračný nástroj (BitTitan, CloudM, imapsync, nech je to čokoľvek) uložil emaily do Google Workspace cez IMAP APPEND. Zadal hodnotu INTERNALDATE zodpovedajúcu dátumu migrácie, nie pôvodnému dátumu emailu. Výsledok: Outlook, ktorý predvolene triedi podľa INTERNALDATE, zobrazuje pre všetky správy dátum migrácie. Článok Nesprávne dátumy emailov po migrácii vysvetľuje tento mechanizmus podrobne.

Pôvodná hlavička Date: je v každej správe neporušená. DKIM podpisy sú neporušené. Obsah sa nepohol. Nesprávna je iba hodnota INTERNALDATE na strane servera.

Tento problém postihuje BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO a všetky nástroje, ktoré používajú IMAP APPEND bez správneho zachovania INTERNALDATE. Článok venovaný BitTitan MigrationWiz popisuje špecifiká tohto nástroja. Checklist migrácie emailov uvádza body, ktoré treba skontrolovať pred a po migrácii, aby ste sa vyhli tomuto typu problémov.

Rozdiel medzi opravou a falšovaním

Oprava, ktorú vykonáva Redate.io, je pravým opakom pokusu o falšovanie. Proprietárny opravný engine analyzuje reťazec hlavičiek každej správy, identifikuje pôvodný dátum zakódovaný v hlavičke Date: (RFC 2822), ktorý sa nikdy nepohol, a opraví metadáta dátumu tak, aby zodpovedali tejto autentickej informácii, ktorá je v správe už prítomná.

Hlavička Date: je zdrojom pravdy. Napísal ju poštový klient odosielateľa v čase odoslania. Je pokrytá DKIM podpisom. Redate.io ju nemení. Čo sa opravuje, je nesúlad zavedený migračným nástrojom, nie pôvodný dátum.

Opraviť 47 000 emailov po nepodarenom migrácii bez straty jediného, bez rozbitia vlákien konverzácií, bez poškodenia príloh, bez spustenia chyby 429 o 3:00 ráno na Google API: to je viacstupňový analytický pipeline so spracovaním hraničných prípadov (S/MIME, PGP, non-ASCII kódovania podľa RFC 2047, zložité multipart štruktúry). Python skript o piatich riadkoch by neprežil prvú produkčnú schránku. Článok Ako opraviť dátumy emailov po migrácii podrobne vysvetľuje, prečo je DIY prístup riskantný pri reálnych objemoch.

Redate.io skenuje poštové schránky zadarmo, identifikuje emaily s nesprávnymi dátumami a opravuje ich cez validačný pipeline, ktorý overuje každú správu individuálne. Originály sú počas 30 dní uchovávané v záložnom priečinku, ktorý je viditeľný. Ak niečo nevyjde, rollback je možný.

Vaša migrácia posunula dátumy emailov? Spustite bezplatné skenovanie na Redate.io a zistite rozsah problému skôr, než sa rozhodnete, čo robiť.