E-pasta datuma viltošana: iespējams un atklājams

E-pasta datuma viltošana: par ko īsti runājam?

Šis jautājums regulāri parādās sistēmadministratoru forumos un MSP Slack grupās: vai ir iespējams mainīt e-pasta datumu pēc nosūtīšanas? Īsā atbilde ir jā, tehniski. Bet pilnā atbilde ir daudz mazāk iepriecinoša tam, kurš to vēlētos darīt ļaunprātīgi.

E-pasts nav monolīts fails. Tā ir teksta galveņu kolekcija, kam seko ziņojuma pamatteksts. Starp šīm galvenēm vairākas satur datuma informāciju. Un dažas ir vieglāk modificējamas nekā citas.

Katrā e-pastā pastāv trīs datēšanas slāņi:

• Galvene Date: (RFC 2822), ko pasta klients uzraksta nosūtīšanas brīdī
• Galvenes Received:, ko pievieno katrs serveris, kas relē ziņojumu
• IMAP INTERNALDATE, servera pusē glabāta metadatu vērtība, neatkarīga no ziņojuma satura

Katrs no šiem slāņiem ir modificējams. Neviens no tiem nav modificējams bez pēdām.

Galvenes Date: mainīšana: acīmredzamākā manipulācija

Galvene Date: ir neapstrādāts teksts .eml failā. Tehniski jebkurš heksadecimālais redaktors vai Python skripts to var pārrakstīt dažu sekunžu laikā. Ja esat kādreiz atvēris e-pasta neapstrādātās galvenes Gmail (mazā izvēlne "Rādīt oriģinālu"), jūs zināt, ka tās ir salasāmas ikvienam.

Problēma? Kopš 2004. gada lielākā daļa pasta serveru paraksta izejošos e-pastus ar DKIM (DomainKeys Identified Mail). Šis kriptogrāfiskais paraksts tieši aptver vairākas galvenes, tostarp Date:, From:, Subject:, un ziņojuma pamattekstu. Paraksts tiek glabāts galvenē DKIM-Signature:.

Galvenes Date: mainīšana pēc parakstīšanas mehāniski padara DKIM verifikāciju nederīgu. Jebkurš saņemšanas serveris var pārbaudīt parakstu, iegūstot publisko atslēgu no sūtītāja domēna DNS. Ja paraksts vairs neatbilst, ziņojums tiek atzīmēts kā mainīts. Gmail, Outlook.com un visi lielie pakalpojumu sniedzēji šo pārbaudi veic automātiski.

(Starp citu, ja vēlaties praktiski redzēt DKIM parakstu, atveriet neapstrādātās galvenes kādam e-pastam, kas saņemts no Gmail vai Office 365: tur atradīsiet rindiņu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., kas izskatās kā troksnis, bet patiesībā ir visa ziņojuma kriptogrāfisks jaukteņkods.)

Rezultāts: galvenes Date: mainīšana DKIM parakstītā e-pastā nozīmē zīmoga laušanu. Izmaiņas ir redzamas jebkuram administratoram, kurš prot meklēt.

Received: galveņu pārrakstīšana: grūti viltojama ķēde

Galvenes Received: izseko e-pasta ceļu no sūtītāja uz saņēmēju. Katrs SMTP serveris, kas pieskaras ziņojumam, pievieno vienu ar savu nosaukumu, IP adresi un laika zīmogu. E-pasts, kas iet caur diviem vai trim relejiem, satur tātad divas vai trīs sakrautas Received: galvenes.

Vai tās var mainīt? Tehniski jā, savā ziņojuma kopijā. Taču te ir lamatas: saņēmējam arī ir kopija. Un viņa serveris pats pēdējo pievienoja savu Received: galveni. Šī galvene ir saņēmēja, nevis sūtītāja kontrolē. No ārpuses to nav iespējams viltot.

Ķēdes konsekvenci var pārbaudīt. Ja secīgo Received: laika zīmogi ir nekonsekventi (piemēram, starpposma relejs būtu saņēmis ziņojumu pirms sūtītājs to nosūtīja), tas uzreiz rada aizdomas. Forensiskās e-pasta analīzes rīki, piemēram, MXToolbox vai drošības komandu iekšējie rīki, pārbauda tieši to.

Patiesībā nav gluži precīzi teikt, ka Received: galvenes nav iespējams pilnībā viltot: uzbrucējs, kurš kontrolē savu pasta infrastruktūru, var izgatavot ticamas galvenes relējiem, ko tas kontrolē. Taču pēdējo posmu tas nekad nekontrolē: saņēmēja serveri.

IMAP INTERNALDATE: tehniskākais gadījums

INTERNALDATE ir IMAP metadatu vērtība, kas glabājas servera pusē. Tā nav galvene pašā ziņojumā: tā ir vērtība, ko serveris ziņojumam asociē savā iekšējā datubāzē. Tieši šo vērtību lielākā daļa pasta klientu izmanto, lai kārtotu ziņojumus iesūtnē.

IMAP komanda APPEND ļauj serverī ievietot ziņojumu, tieši norādot INTERNALDATE. Tā ir protokola likumīga funkcionalitāte, kas dokumentēta RFC 3501. Migrācijas rīki to izmanto pastāvīgi: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... visi ievieto e-pastus galamērķa serverī ar norādītu INTERNALDATE.

Teorētiski kāds ar IMAP piekļuvi savai pastkastei varētu ievietot e-pastu ar jebkuru INTERNALDATE. Taču šī manipulācija nemaina ziņojuma galvenes. Oriģinālā Date: paliek neskarta, Received: paliek neskarta, DKIM paraksts paliek neskarts. Mainās tikai servera puses kārtošanas metadati.

Ekspertam, kurš pārbauda neapstrādāto ziņojumu, neatbilstība starp INTERNALDATE un deklarēto Date: ir uzreiz redzama. Un, ja ziņojums ir DKIM parakstīts, oriģinālais datums ir kriptogrāfiski apliecināts.

Message-ID: grūti viltojams pirkstu nospiedums

Katrs e-pasts ģenerē unikālu identifikatoru, galveni Message-ID:. Šo identifikatoru nosūtīšanas brīdī izveido sūtītāja SMTP serveris, parasti apvienojot laika zīmogu, nejaušu identifikatoru un servera domēna nosaukumu.

Tipisks Message-ID izskatās šādi: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Laika zīmogs bieži vien ir tieši kodēts identifikatorā. Ziņojuma datuma mainīšana, atstājot Message-ID ar nesakrītošu laika zīmogu, rada uzreiz pamanāmu nekonsekvenci.

Turklāt Message-ID tiek indeksēti lielo ziņojumapmaiņas sistēmu žurnālos. Google, Microsoft un citi dalībnieki uztur žurnālus, kas ļauj izsekot, kad ziņojums reāli cirkulēja to infrastruktūrā. Juridiskā vai forensiskā kontekstā šie žurnāli ir pieejami ar tiesu procedūru starpniecību.

Praksē: kurš var atklāt manipulācijas mēģinājumu?

Uzdosim jautājumu konkrēti. Jūs saņemat e-pastu, par kuru aizdodaties, ka datums ir mainīts. Ko var darīt IT administrators vai jurists ar minimālu tehnisko pieredzi?

• DKIM pārbaude: Gmail izvēlnē "Rādīt oriģinālu" tieši lapas augšā tiek parādīts DKIM verifikācijas rezultāts. "PASS" apstiprina ziņojuma integritāti kopš nosūtīšanas. "FAIL" vai "SOFTFAIL" signalizē par izmaiņām.
• Galveņu analīze: rīki kā MXToolbox Header Analyzer vai Google Admin Toolbox automātiski parsē Received: ķēdi un atzīmē laika nekonsekvences.
• Message-ID un Date konsekvence: analītiķis var salīdzināt Message-ID kodēto laika zīmogu ar deklarētā Date: vērtību.
• Servera žurnāli: ja e-pasts ir gājis caur serveri, kura administrators esat jūs, SMTP žurnāli satur ziņojuma reālo pieņemšanas datumu un laiku neatkarīgi no jebkādas galvenes.

Īsumā, atklāšanas rīki ir pieejami, bezmaksas un neprasa augstu forensisko eksperta kompetenci. IT administrators ar nelielu zinātkāri var pārbaudīt e-pasta integritāti mazāk nekā divās minūtēs.

Vienīgais likumīgais masveida datumu korekcijas gadījums: IMAP migrācija

Pastāv scenārijs, kurā simtiem tūkstošu e-pastu nonāk ar nepareiziem datumiem bez jebkāda ļauna nolūka: IMAP migrācija.

Tikko pabeidzāt 150 Exchange pastkastīšu migrāciju uz Google Workspace. Pirmdienas rītā sāk ienākt pieteikumi. Lietotāji ziņo, ka visi viņu vecākie e-pasti tiek rādīti ar vienu datumu, migrācijas nedēļas nogales datumu. Viņu iesūtnes ir nelasāmas.

Notikušais ir dokumentēts un paredzams: migrācijas rīks (BitTitan, CloudM, imapsync, neatkarīgi no kura) e-pastus ievietoja Google Workspace, izmantojot IMAP APPEND. Tas norādīja INTERNALDATE, kas atbilst migrācijas datumam, nevis e-pasta oriģinālajam datumam. Rezultāts: Outlook, kas pēc noklusējuma kārto pēc INTERNALDATE, visiem ziņojumiem rāda migrācijas datumu. Kāpēc e-pastiem ir nepareizs datums pēc migrācijas šo mehānismu izskaidro sīkāk.

Oriģinālā galvene Date: katrā ziņojumā ir neskarta. DKIM paraksti ir neskartie. Saturs nav mainījies. Tikai servera puses INTERNALDATE ir nepareiza.

Šī problēma skar BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO un visus rīkus, kas izmanto IMAP APPEND, pareizi nesaglabājot INTERNALDATE. Raksts par BitTitan MigrationWiz aptver šī rīka specifiku. E-pasta migrācijas kontrolsaraksts uzrāda punktus, kas jāpārbauda pirms un pēc migrācijas, lai izvairītos no šāda veida problēmām.

Starpība starp korekciju un viltošanu

Korekcija, ko veic Redate.io, ir pretēja viltošanas mēģinājumam. Patentētais korekcijas dzinējs analizē katra ziņojuma galveņu ķēdi, identificē oriģinālo datumu, kas kodēts galvenē Date: (RFC 2822) un kas nekad nav mainījies, un koriģē datuma metadatus, lai tos saskaņotu ar šo autentisko informāciju, kas jau ir klātesoša ziņojumā.

Galvene Date: ir patiesības avots. To uzrakstīja sūtītāja pasta klients nosūtīšanas brīdī. To aptver DKIM paraksts. Redate.io to nemaina. Tiek koriģēta neatbilstība, ko ieviesa migrācijas rīks, nevis oriģinālais datums.

47 000 e-pastu koriģēšana pēc neveiksmīgas migrācijas, nezaudējot nevienu, nesaraujot diskusiju pavedienus, nesabojājot pielikumus, neizraisot 429 kļūdu pulksten 3 no rīta Google API: tā ir daudzpakāpju analīzes pipeline ar robežgadījumu apstrādi (S/MIME, PGP, RFC 2047 ne-ASCII kodējumi, sarežģītas multipart struktūras). Piecu rindiņu Python skripts neizturētu pirmo ražošanas pastkastīti. Vai e-pastu datumus var labot pēc migrācijas? skaidro, kāpēc pašdarinājums ir riskants reālos apjomos.

Redate.io bezmaksas skenē pastkastītes, identificē e-pastus ar nepareiziem datumiem un koriģē, izmantojot validācijas pipeline, kas katru ziņojumu pārbauda individuāli. Oriģināli tiek saglabāti redzamā dublēšanas mapē 30 dienas. Ja kaut kas noiet greizi, atgriešanās ir iespējama.

Jūsu migrācija pārbīdīja e-pastu datumus? Sāciet bezmaksas skenēšanu Redate.io, lai novērtētu problēmas apmēru pirms lemšanas par turpmāko rīcību.