Antidatiranje e-pošte: kaj je mogoče in kaj je zaznano

Antidatiranje e-pošte: o čem sploh govorimo?

Vprašanje se redno pojavlja na forumih sistemskih administratorjev in v Slack skupinah MSP-jev: ali je mogoče spremeniti datum e-poštnega sporočila po pošiljanju? Kratek odgovor je da, tehnično gledano. Toda celovit odgovor je precej manj pomirjujoč za tiste, ki bi to počeli z dvomljivimi nameni.

E-poštno sporočilo ni monolitna datoteka. Je zbirka besedilnih glav, ki jim sledi vsebina sporočila. Med temi glavami jih več nosi informacije o datumu. Nekatere je lažje spremeniti kot druge.

V vsakem e-poštnem sporočilu sobivajo tri plasti datiranja:

• Glava Date: (RFC 2822), ki jo odjemalec zapiše ob pošiljanju
• Glave Received:, ki jih doda vsak strežnik pri posredovanju sporočila
• IMAP INTERNALDATE, metapodatek shranjen na strežniku, neodvisen od vsebine sporočila

Vsako od teh plasti je mogoče spremeniti. Nobene brez sledi.

Sprememba glave Date: najočitnejša manipulacija

Glava Date: je navadno besedilo v datoteki .eml. Tehnično jo lahko kateri koli hex urejevalnik ali Python skripta prepise v nekaj sekundah. Če ste kdaj odprli surove glave e-pošte v Gmailu (majhen meni "Pokaži original"), veste, da je to berljivo komur koli.

Problem? Od leta 2004 velika večina poštnih strežnikov podpisuje odhodna sporočila z DKIM (DomainKeys Identified Mail). Ta kriptografski podpis izrecno pokriva več glav, vključno z Date:, From:, Subject: in vsebino sporočila. Podpis je shranjen v glavi DKIM-Signature:.

Sprememba Date: po podpisovanju mehanično razveljavi preverjanje DKIM. Kateri koli sprejemni strežnik lahko preveri podpis tako, da pridobi javni ključ iz DNS domene pošiljatelja. Če se podpis ne ujema, je sporočilo označeno kot sprenjeno. Gmail, Outlook.com in vsi večji ponudniki to preverjanje izvajajo samodejno.

(Mimogrede, če želite videti podpis DKIM v praksi, odprite surove glave e-poštnega sporočila, prejetega od Gmaila ali Office 365: našli boste vrstico DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., ki je videti kot šum, v resnici pa je kriptografska zgoščena vrednost celotnega sporočila.)

Rezultat: sprememba Date: na e-pošti, podpisani z DKIM, zlomi pečat. Sprememba je vidna vsakemu administratorju, ki ve, kje iskati.

Prepisovanje glav Received: veriga, ki jo je težko ponarediti

Glave Received: sledijo poti, ki jo e-poštno sporočilo prevozi med pošiljateljem in prejemnikom. Vsak SMTP strežnik, ki se dotakne sporočila, doda eno z imenom, IP naslovom in časovnim žigom. Sporočilo, ki potuje skozi dva ali tri posrednike, vsebuje dva ali tri zložene Received:.

Ali jih je mogoče spremeniti? Tehnično da, na lastni kopiji sporočila. Toda tukaj je past: prejemnik ima prav tako kopijo. In njegov strežnik je nazadnje dodal svojo lastno glavo Received:. Ta glava je pod nadzorom prejemnika, ne pošiljatelja. Ni je mogoče ponarediti od zunaj.

Usklajenost verige je preverljiva. Če so časovni žigi zaporednih Received: nekoherentni (recimo, posredniški strežnik bi sporočilo prejel, preden ga je pošiljatelj sploh poslal), je to takoj sumljivo. Orodja za forenzično analizo e-pošte, kot sta MXToolbox ali notranja orodja varnostnih ekip, preverjajo točno to.

Pravzaprav ni povsem točno reči, da glav Received: sploh ni mogoče ponarediti: napadalec, ki nadzoruje lastno poštno infrastrukturo, lahko ustvari verodostojne glave za posrednike, ki jih obvladuje. Toda zadnje člen verige, strežnik prejemnika, nikoli ne nadzoruje.

IMAP INTERNALDATE: najbolj tehnični primer

INTERNALDATE je metapodatek IMAP, shranjen na strežniku. Ni glava v sporočilu samem: to je vrednost, ki jo strežnik poveže s sporočilom v svoji interni bazi podatkov. To vrednost večina e-poštnih odjemalcev uporablja za razvrščanje sporočil v nabiralniku.

Ukaz IMAP APPEND omogoča shranjevanje sporočila na strežnik z izrecno določitvijo INTERNALDATE. To je legitimna funkcija protokola, dokumentirana v RFC 3501. Orodja za selitev jo nenehno uporabljajo: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... vsa shranjujejo e-pošto na ciljni strežnik z določeno INTERNALDATE.

Teoretično bi nekdo z IMAP dostopom do lastnega nabiralnika lahko shranil e-pošto s katerim koli INTERNALDATE. Toda ta manipulacija ne spreminja glav sporočila. Izvirni Date: ostane nedotaknjen, glave Received: ostanejo nedotaknjene, podpis DKIM ostane nedotaknjen. Spremeni se samo metapodatek za razvrščanje na strežniku.

Za strokovnjaka, ki pregleda surovo sporočilo, je neskladnost med INTERNALDATE in Date: takoj očitna. In če je sporočilo podpisano z DKIM, je izvirni datum kriptografsko potrjen.

Message-ID: prstni odtis, ki ga je težko ponarediti

Vsaka e-pošta pridobi edinstven identifikator, glavo Message-ID:. Ta identifikator ustvari pošiljateljev SMTP strežnik ob pošiljanju, pri čemer navadno združi časovni žig, naključni identifikator in ime domene strežnika.

Tipičen Message-ID je videti takole: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Časovni žig je pogosto neposredno kodiran v identifikator. Sprememba datuma sporočila ob ohranitvi Message-ID z nezdružljivim časovnim žigom ustvari neskladnost, ki jo je takoj mogoče zaznati.

Poleg tega so Message-ID-ji indeksirani pri večjih sistemih za sporočanje. Google, Microsoft in drugi akterji vodijo dnevnike, ki omogočajo sledenje, kdaj je sporočilo dejansko krožilo po njihovi infrastrukturi. V pravnem ali forenzičnem kontekstu so ti dnevniki dostopni po sodnih postopkih.

V praksi: kdo lahko zazna poskus manipulacije?

Postavimo vprašanje konkretno. Prejmete e-pošto, pri kateri sumite, da je bil datum spremenjen. Kaj lahko stori IT administrator ali odvetnik z osnovno tehnično podlago?

• Preverjanje DKIM: v Gmailu meni "Pokaži original" neposredno prikazuje rezultat preverjanja DKIM na vrhu strani. "PASS" potrjuje celovitost sporočila od pošiljanja. "FAIL" ali "SOFTFAIL" signalizira spremembo.
• Analiza glav: orodja, kot sta MXToolbox Header Analyzer ali Google Admin Toolbox, samodejno razčlenijo verigo Received: in opozorijo na časovne neskladnosti.
• Usklajenost Message-ID / Date: analitik lahko primerja časovni žig, kodiran v Message-ID, z vrednostjo navedenega Date:.
• Dnevniki strežnika: če je e-pošta potovala skozi strežnik, katerega administrator ste, dnevniki SMTP vsebujejo dejanski datum in uro sprejema sporočila, neodvisno od katerih koli glav.

Skratka, orodja za zaznavanje so dostopna, brezplačna in ne zahtevajo napredne forenzične strokovnosti. Radoveden IT admin lahko v manj kot dveh minutah preveri celovitost e-poštnega sporočila.

Edini legitimni primer množičnega popravljanja datumov: selitev IMAP

Obstaja scenarij, v katerem se stotine tisoč e-poštnih sporočil znajde z napačnimi datumi brez kakršnega koli zlonamernega namena: selitev IMAP.

Pravkar ste zaključili selitev 150 nabiralnikov Exchange v Google Workspace. V ponedeljek zjutraj začnejo prihajati prijave. Uporabniki poročajo, da se vsa stara e-poštna sporočila prikazujejo z istim datumom, datumom vikenda selitve. Njihovi nabiralniki so neberljivi.

Kar se je zgodilo, je dokumentirano in predvidljivo: orodje za selitev (BitTitan, CloudM, imapsync, kjerkoli) je e-pošto naložilo v Google Workspace prek IMAP APPEND. Določilo je INTERNALDATE, ki ustreza datumu selitve, ne izvirnemu datumu e-pošte. Rezultat: Outlook, ki privzeto razvršča po INTERNALDATE, prikazuje datum selitve za vsa sporočila. Članek Zakaj e-pošta prikazuje napačen datum po selitvi ta mehanizem podrobno pojasnjuje.

Izvirna glava Date: je v vsakem sporočilu nedotaknjena. Podpisi DKIM so nedotaknjeni. Vsebina se ni spremenila. Napačna je samo INTERNALDATE na strani strežnika.

Ta težava prizadene BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO in vsa orodja, ki uporabljajo IMAP APPEND brez pravilnega ohranjanja INTERNALDATE. Članek o BitTitan MigrationWiz pokriva posebnosti tega orodja. Kontrolni seznam selitve e-pošte navaja točke, ki jih je treba preveriti pred in po selitvi, da bi se izognili tovrstnim težavam.

Razlika med popravljanjem in ponarejanjem

Popravek, ki ga izvaja Redate.io, je nasprotje poskusa ponarejanja. Lastniški mehanizem za popravek analizira verigo glav vsakega sporočila, identificira izvirni datum, kodiran v glavi Date: (RFC 2822), ki se ni nikoli spremenil, in popravi metapodatke datuma, da se uskladijo s to avtentičnimi informacijami, ki so že prisotne v sporočilu.

Glava Date: je vir resnice. Napisal jo je odjemalec pošiljatelja ob pošiljanju. Pokrita je s podpisom DKIM. Redate.io je ne spreminja. Kar se popravi, je neskladnost, ki jo je uvedlo orodje za selitev, ne izvirni datum.

Popraviti 47.000 e-poštnih sporočil po neuspešni selitvi brez izgube enega samega, brez zloma niti pogovorov, brez poškodb prilog, brez sprožitve napake 429 ob treh zjutraj na Google API: to zahteva večstopenjski analitični pipeline z upravljanjem robnih primerov (S/MIME, PGP, nekodiranja ne-ASCII po RFC 2047, kompleksne večdelne strukture). Python skripta s petimi vrsticami ne bi preživela prvega produkcijskega nabiralnika. Članek Ali se datumi e-pošte lahko popravijo po selitvi podrobno razlaga, zakaj je DIY pristop tvegan pri realnih količinah.

Redate.io brezplačno pregleda nabiralnike, identificira e-poštna sporočila z napačnimi datumi in popravi prek validacijskega pipeline-a, ki vsako sporočilo preveri posebej. Izvirniki so shranjeni v vidni varnostni kopiji 30 dni. Če gre kaj narobe, je povrnitev v prejšnje stanje mogoča.

Je vaša selitev zamaknila datume vaše e-pošte? Zaženite brezplačno skeniranje na Redate.io in ocenite obseg težave, preden se odločite, kaj storiti.