El. laiško datos klastojimas: kas įmanoma ir aptinkama

El. laiško datos keitimas: apie ką iš tikrųjų kalbame?

Šis klausimas nuolat kartojasi sistemos administratorių forumuose ir MSP „Slack" grupėse: ar įmanoma pakeisti el. laiško datą jau po išsiuntimo? Trumpas atsakymas - taip, techniškai. Tačiau išsamus atsakymas yra daug mažiau raminantis tiems, kurie norėtų tai padaryti abejotinais tikslais.

El. laiškas nėra monolitinis failas. Tai tekstinių antraščių rinkinys, po kurio eina pranešimo turinys. Tarp šių antraščių kelios perduoda datos informaciją. Ir kai kurias iš jų pakeisti lengviau nei kitas.

Kiekviename el. laiške egzistuoja trys datavimo sluoksniai:

• Antraštė Date: (RFC 2822), kurią pašto klientas įrašo išsiuntimo momentu
• Antraštės Received:, kurias prideda kiekvienas pranešimą perduodantis serveris
• IMAP INTERNALDATE - serverio pusėje saugoma metaduomenų reikšmė, nepriklausoma nuo pranešimo turinio

Kiekvienas iš šių sluoksnių keičiamas. Nė vienas - be pėdsakų.

Antraštės Date: keitimas: akivaizdžiausias manipuliavimas

Antraštė Date: yra paprastas tekstas .eml faile. Techniškai bet koks šešioliktainis redaktorius ar Python scenarijus gali ją perrašyti per kelias sekundes. Jei kada nors atidarėte neapdorotus el. laiško antraštės duomenis Gmail lange (mažas meniu „Rodyti originalą"), žinote, kad tai gali perskaityti bet kas.

Problema? Nuo 2004 metų didžioji dauguma pašto serverių pasirašo siunčiamus laiškus DKIM (DomainKeys Identified Mail) kriptografine parašu. Šis parašas aiškiai apima kelias antraštes, įskaitant Date:, From:, Subject: ir pranešimo turinį. Parašas saugomas antraštėje DKIM-Signature:.

Pasirašytos antraštės Date: keitimas automatiškai panaikina DKIM tikrinimą. Bet kuris gaunantis serveris gali patikrinti parašą, išgaudamas viešąjį raktą iš siuntėjo domeno DNS. Jei parašas nebeatitinka, pranešimas pažymimas kaip pakeistas. Gmail, Outlook.com ir visi didieji tiekėjai šį patikrinimą atlieka automatiškai.

(Beje, jei norite konkrečiai pamatyti DKIM parašą, atidarykite neapdorotus Gmail ar Office 365 el. laiško antraštes: rasite eilutę DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., kuri atrodo kaip triukšmas, bet iš tikrųjų yra viso pranešimo kriptografinis maišos kodas.)

Rezultatas: DKIM pasirašyto laiško antraštės Date: keitimas sulaužo antspaudą. Pakeitimas matomas kiekvienam administratoriui, kuris moka ieškoti.

Antraščių Received: perrašymas: sunku suklastoti grandinę

Antraštės Received: atseka kelią, kurį el. laiškas nukeliavo nuo siuntėjo iki gavėjo. Kiekvienas SMTP serveris, liečiantis pranešimą, prideda vieną, su savo pavadinimu, IP adresu ir laiko žyma. El. laiškas, perėjęs per du ar tris relėjus, turi du ar tris susumuotas antraštes Received:.

Ar galima jas keisti? Techniškai taip, savo paties pranešimo kopijoje. Tačiau čia slypi spąstai: gavėjas taip pat turi kopiją. O jo serveris paskutinis pridėjo savo Received: antraštę. Ši antraštė yra gavėjo, ne siuntėjo kontroliuje. Jos neįmanoma suklastoti iš išorės.

Grandinės nuoseklumą galima patikrinti. Jei einamųjų Received: laiko žymos nenuoseklios (pavyzdžiui, tarpinis relėjas gautų pranešimą anksčiau, nei siuntėjas jį išsiuntė), tai iš karto kelia įtarimą. El. pašto teismo ekspertizės įrankiai, tokie kaip MXToolbox ar saugumo komandų vidiniai įrankiai, tikrina būtent tai.

Tiesą sakant, nėra visiškai tikslu teigti, kad Received: antraščių visiškai suklastoti neįmanoma: užpuolikas, valdantis savo pašto infrastruktūrą, gali sukurti patikimas antraštes relėjams, kuriuos kontroliuoja. Tačiau jis niekada nekontroliuoja paskutinės grandies: gavėjo serverio.

IMAP INTERNALDATE: techniškai sudėtingiausias atvejis

INTERNALDATE yra IMAP metaduomenys, saugomi serverio pusėje. Tai ne antraštė pačiame pranešime, o reikšmė, kurią serveris susieja su pranešimu savo vidinėje duomenų bazėje. Būtent šią reikšmę dauguma pašto klientų naudoja pranešimams rūšiuoti gautuosiuose.

IMAP komanda APPEND leidžia patalpinti pranešimą serveryje aiškiai nurodant INTERNALDATE. Tai teisėta protokolo funkcija, aprašyta RFC 3501. Migracijos įrankiai ja nuolat naudojasi: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... visi patalpina el. laiškus į paskirties serverį su nurodytu INTERNALDATE.

Teoriškai kas nors, turintis IMAP prieigą prie savo pašto dėžutės, galėtų patalpinti el. laišką su bet kokiu INTERNALDATE. Tačiau šis manipuliavimas nekeičia pranešimo antraščių. Originali Date: antraštė lieka nepaliesta, Received: antraštės lieka nepalietos, DKIM parašas lieka nepaliestas. Keičiasi tik serverio pusės rūšiavimo metaduomenys.

Ekspertui, analizuojančiam neapdorotą pranešimą, neatitikimas tarp INTERNALDATE ir Date: matomas iš karto. O jei pranešimas pasirašytas DKIM, originali data kriptografiškai patvirtinta.

Message-ID: sunkiai suklastojamas pirštų atspaudas

Kiekvienas el. laiškas generuoja unikalų identifikatorių - antraštę Message-ID:. Šį identifikatorių sukuria siuntėjo SMTP serveris išsiuntimo momentu, paprastai sujungdamas laiko žymą, atsitiktinį identifikatorių ir serverio domeno vardą.

Tipiškas Message-ID atrodo taip: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Laiko žyma dažnai tiesiogiai koduojama identifikatoriuje. Pakeičiant pranešimo datą ir paliekant Message-ID su nesuderinama laiko žyma, sukuriama iš karto pastebima neatitikimas.

Be to, Message-ID yra indeksuojami didelių pranešimų sistemų. Google, Microsoft ir kiti veikėjai palaiko žurnalus, leidžiančius atsekti, kada pranešimas iš tikrųjų cirkuliavo jų infrastruktūrose. Teisiname ar teismo ekspertizės kontekste šie žurnalai pasiekiami per teisines procedūras.

Praktiškai: kas gali aptikti manipuliavimo bandymą?

Užduokime klausimą konkrečiai. Gavote el. laišką ir įtariate, kad jo data buvo pakeista. Ką gali padaryti IT administratorius ar advokatas, turintis minimalią techninę patirtį?

• DKIM tikrinimas: Gmail meniu „Rodyti originalą" puslapio viršuje tiesiogiai rodo DKIM tikrinimo rezultatą. „PASS" patvirtina pranešimo vientisumą nuo išsiuntimo. „FAIL" ar „SOFTFAIL" signalizuoja apie pakeitimą.
• Antraščių analizė: tokie įrankiai kaip MXToolbox Header Analyzer ar Google Admin Toolbox automatiškai analizuoja Received: grandinę ir praneša apie laiko neatitikimus.
• Message-ID / Date nuoseklumas: analitikas gali palyginti Message-ID koduojamą laiko žymą su deklaruota Date: reikšme.
• Serverio žurnalai: jei el. laiškas perėjo per serverį, kurio administratorius esate jūs, SMTP žurnalai fiksuoja tikrąją pranešimo priėmimo datą ir laiką, nepriklausomai nuo jokių antraščių.

Paprastai tariant, aptikimo įrankiai yra prieinami, nemokami ir nereikalauja pažangios teismo ekspertizės kompetencijos. Šiek tiek smalsus IT administratorius gali patikrinti el. laiško vientisumą per mažiau nei dvi minutes.

Vienintelis teisėtas masinio datų keitimo atvejis: IMAP migracija

Egzistuoja scenarijus, kai šimtai tūkstančių el. laiškų gauna neteisingas datas be jokio kenkėjiško ketinimo: IMAP migracija.

Tarkime, ką tik baigėte 150 Exchange dėžučių migraciją į Google Workspace. Pirmadienio rytą prasideda bilietai. Vartotojai praneša, kad visi jų seni laiškai rodomi ta pačia data - migracijos savaitgalio data. Jų gautuosieji yra neįskaitomi.

Tai, kas įvyko, yra dokumentuota ir nuspėjama: migracijos įrankis (BitTitan, CloudM, imapsync, nesvarbu kuris) patalpino el. laiškus į Google Workspace per IMAP APPEND. Jis nurodė INTERNALDATE atitinkantį migracijos datą, o ne originalią el. laiško datą. Rezultatas: Outlook, pagal nutylėjimą rūšiuojantis pagal INTERNALDATE, visiems pranešimams rodo migracijos datą. Kodėl el. laiškai rodo klaidingas datas po migracijos šį mechanizmą paaiškina išsamiai.

Originali antraštė Date: kiekviename pranešime lieka nepaliesta. DKIM parašai nepaliesti. Turinys nepasikeitė. Neteisinga yra tik INTERNALDATE serverio pusėje.

Ši problema liečia BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO ir visus įrankius, kurie naudoja IMAP APPEND tinkamai neišsaugodami INTERNALDATE. BitTitan MigrationWiz skirtas straipsnis aprėpia šio įrankio ypatumus. El. pašto migracijos kontrolinis sąrašas nurodo, ką reikia patikrinti prieš migraciją ir po jos, kad išvengtumėte tokių problemų.

Skirtumas tarp taisymo ir klastojimo

Redate.io atliekamas taisymas yra priešingas klastojimo bandymui. Patentuotas taisymo variklis analizuoja kiekvieno pranešimo antraščių grandinę, identifikuoja originalią datą, koduojamą antraštėje Date: (RFC 2822), kuri niekada nebuvo pakeista, ir ištaiso datos metaduomenis, suderindamas juos su šia autentiška informacija, jau esančia pranešime.

Antraštė Date: yra tiesos šaltinis. Ją siuntėjo pašto klientas įrašė išsiuntimo momentu. Ji apimama DKIM parašu. Redate.io jos nekeičia. Taisoma yra migracijos įrankio sukurta neatitikimas, o ne originali data.

47 000 el. laiškų taisymas po nepavykusios migracijos neprarandant nė vieno, nesulaužant pokalbių gijų, nesugadinant priedų, neišprovokuojant 429 klaidos 3 val. nakties Google API: tai daugiapakopis analizės konvejeris su kraštutinių atvejų valdymu (S/MIME, PGP, ne-ASCII koduotės pagal RFC 2047, sudėtingos multipart struktūros). Penkių eilučių Python scenarijus neišgyventų pirmoje gamybos dėžutėje. Ar galima pataisyti el. laiškų datas po migracijos paaiškina, kodėl savosios priemonės yra rizikingos su realiais kiekiais.

Redate.io nemokamai nuskaito pašto dėžutes, identifikuoja el. laiškus su neteisingomis datomis ir taiso per tikrinimo konvejeri, kuris kiekvieną pranešimą patikrina atskirai. Originalai saugomi matomame atsarginių kopijų aplanke 30 dienų. Jei kažkas nutiktų ne taip, atstatymas yra galimas.

Jūsų migracija pastumdė el. laiškų datas? Paleiskite nemokamą nuskaitymą Redate.io, kad įvertintumėte problemos mastą prieš nusprendžiant, ką daryti.