Antidatiranje emaila: što je moguće i što je vidljivo

Antidatiranje emaila: o čemu zapravo govorimo?

Pitanje se redovito pojavljuje na forumima za sistemske administratore i u Slack grupama MSP stručnjaka: je li moguće promijeniti datum emaila nakon slanja? Kratki odgovor je da, tehnički. Ali potpuni odgovor puno je manje utješan za onoga tko bi to htio učiniti u sumnjive svrhe.

Email nije monolitna datoteka. To je skup tekstualnih zaglavlja iza kojih slijedi tijelo poruke. Među tim zaglavljima, nekoliko ih nosi informacije o datumu. I neka su lakša za izmjenu od drugih.

Tri sloja datiranja koegzistiraju u svakom emailu:

• Zaglavlje Date: (RFC 2822), koje klijent za poštu upisuje u trenutku slanja
• Zaglavlja Received:, koja dodaje svaki server koji prosljeđuje poruku
• IMAP INTERNALDATE, metapodatak pohranjen na strani servera, neovisan o sadržaju poruke

Svaki od ovih slojeva može se modificirati. Nijedan to ne može bez ostavljanja tragova.

Mijenjanje zaglavlja Date: - najočitija manipulacija

Zaglavlje Date: je čisti tekst unutar .eml datoteke. Tehnički, bilo koji hex editor ili Python skripta može ga prepisati za nekoliko sekundi. Ako ste ikada otvorili sirova zaglavlja emaila u Gmailu (mali izbornik "Prikaži original"), znate da je to čitljivo svakome.

Problem? Od 2004. godine, velika većina mail servera potpisuje odlazne emailove s DKIM-om (DomainKeys Identified Mail). Ovaj kriptografski potpis eksplicitno pokriva nekoliko zaglavlja, uključujući Date:, From:, Subject:, i tijelo poruke. Potpis je pohranjen u zaglavlju DKIM-Signature:.

Izmjena Date: zaglavlja nakon potpisivanja mehanički poništava DKIM provjeru. Svaki server primatelja može verificirati potpis dohvaćanjem javnog ključa iz DNS-a domene pošiljatelja. Ako potpis više ne odgovara, poruka se označava kao izmijenjena. Gmail, Outlook.com i svi veliki davatelji usluga ovu provjeru rade automatski.

(Inače, ako želite konkretno vidjeti DKIM potpis, otvorite sirova zaglavlja bilo kojeg emaila primljenog od Gmaila ili Office 365: naći ćete redak DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... koji izgleda kao šum, ali je zapravo kriptografski hash cijele poruke.)

Rezultat: mijenjanje Date: zaglavlja na DKIM-potpisanom emailu znači lomljenje pečata. Izmjena je vidljiva svakom administratoru koji zna gdje tražiti.

Prepisivanje Received: zaglavlja - lanac koji je teško krivotvoriti

Zaglavlja Received: prate put koji je email prešao između pošiljatelja i primatelja. Svaki SMTP server koji dotakne poruku dodaje jedno takvo zaglavlje, sa svojim imenom, IP adresom i vremenskom oznakom. Email koji prođe kroz dva ili tri releja sadrži dakle dva ili tri Received: zaglavlja naslagana jedno na drugo.

Mogu li se modificirati? Tehnički da, na vlastitoj kopiji poruke. Ali evo zamke: primatelj također ima kopiju. I njegov server je dodao vlastito Received: zaglavlje kao zadnje. To zaglavlje je pod kontrolom primatelja, ne pošiljatelja. Nemoguće ga je krivotvoriti izvana.

Dosljednost lanca može se verificirati. Ako su vremenski pečati uzastopnih Received: zaglavlja nedosljedni (primjerice, posrednički relej bi primio poruku prije nego što ju je pošiljatelj uopće poslao), to je odmah sumnjivo. Alati za forenzičku analizu emailova poput MXToolboxa ili interni alati sigurnosnih timova provjeravaju upravo to.

Zapravo, nije sasvim točno reći da je Received: zaglavlja nemoguće u potpunosti krivotvoriti: napadač koji kontrolira vlastitu mail infrastrukturu može fabricirati uvjerljiva zaglavlja za relejeve kojima vlada. Ali zadnju kariku u lancu nikada ne kontrolira: server primatelja.

IMAP INTERNALDATE: najtehničniji slučaj

INTERNALDATE je IMAP metapodatak pohranjen na strani servera. To nije zaglavlje unutar same poruke, nego vrijednost koju server pridružuje poruci u svojoj internoj bazi podataka. Upravo tu vrijednost većina email klijenata koristi za sortiranje poruka u sandučiću.

IMAP naredba APPEND omogućuje pohranu poruke na server s eksplicitno navedenim INTERNALDATE vrijednošću. To je legitimna funkcionalnost protokola, dokumentirana u RFC 3501. Alati za migraciju je neprestano koriste: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... svi pohranjuju emailove na odredišni server s navedenim INTERNALDATE vrijednošću.

Teoretski, netko s IMAP pristupom vlastitom sandučiću mogao bi pohraniti email s bilo kojim INTERNALDATE vrijednošću. Ali ta manipulacija ne mijenja zaglavlja poruke. Izvorno Date: zaglavlje ostaje netaknuto, Received: zaglavlja ostaju netaknuta, DKIM potpis ostaje netaknut. Mijenja se samo metapodatak za sortiranje na strani servera.

Za stručnjaka koji pregledava sirovu poruku, nesklad između INTERNALDATE vrijednosti i Date: zaglavlja odmah je vidljiv. A ako je poruka potpisana DKIM-om, izvoran datum je kriptografski potvrđen.

Message-ID: otisak prsta kojeg je teško krivotvoriti

Svaki email generira jedinstveni identifikator, zaglavlje Message-ID:. Taj identifikator gradi SMTP server pošiljatelja u trenutku slanja, kombinirajući obično vremensku oznaku, nasumični identifikator i naziv domene servera.

Tipičan Message-ID izgleda ovako: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Vremenska oznaka često je kodirana izravno u identifikatoru. Izmjena datuma poruke uz ostavljanje Message-ID zaglavlja s nekompatibilnom vremenskom oznakom stvara nedosljednost koja se odmah primijeti.

Osim toga, Message-ID vrijednosti indeksiraju veliki sustavi za razmjenu pošte. Google, Microsoft i drugi akteri vode logove koji omogućuju praćenje kada je poruka zapravo cirkulirala kroz njihovu infrastrukturu. U pravnom ili forenzičkom kontekstu, ti su logovi dostupni putem sudskih postupaka.

U praksi: tko može otkriti pokušaj manipulacije?

Postavimo pitanje konkretno. Primate email za koji sumnjate da mu je datum izmijenjen. Što može učiniti IT administrator ili odvjetnik s minimalnim tehničkim predznanjem?

• Provjera DKIM-a: u Gmailu, izbornik "Prikaži original" izravno prikazuje rezultat DKIM provjere na vrhu stranice. "PASS" potvrđuje integritet poruke od slanja. "FAIL" ili "SOFTFAIL" signalizira izmjenu.
• Analiza zaglavlja: alati poput MXToolbox Header Analyzera ili Google Admin Toolboxa automatski parsiraju lanac Received: zaglavlja i signaliziraju vremenske nedosljednosti.
• Dosljednost Message-ID / Date: analitičar može usporediti vremensku oznaku kodiranu u Message-ID vrijednosti s deklariranom vrijednošću Date: zaglavlja.
• Serverski logovi: ako je email prošao kroz server čiji ste administrator, SMTP logovi sadrže stvarni datum i sat prihvata poruke, neovisno o bilo kojim zaglavljima.

Ukratko, alati za otkrivanje su dostupni, besplatni i ne zahtijevaju naprednu forenzičku stručnost. IT admin s malo znatiželje može provjeriti integritet emaila za manje od dvije minute.

Jedini legitiman slučaj masovne izmjene datuma: IMAP migracija

Postoji jedan scenarij u kojem se stotine tisuća emailova nađu s pogrešnim datumima bez ikakve zlonamjerne namjere: IMAP migracija.

Upravo ste završili migraciju 150 Exchange sandučića na Google Workspace. U ponedjeljak ujutro, tiketi počinju pristizati. Korisnici javljaju da se svi njihovi stari emailovi prikazuju s istim datumom, onim od vikenda migracije. Njihovi sandučići su nečitljivi.

Ono što se dogodilo dokumentirano je i predvidivo: alat za migraciju (BitTitan, CloudM, imapsync, svejedno koji) pohranio je emailove na Google Workspace putem IMAP APPEND naredbe. Naveo je INTERNALDATE koji odgovara datumu migracije, a ne izvornom datumu emaila. Rezultat: Outlook, koji standardno sortira po INTERNALDATE vrijednosti, prikazuje datum migracije za sve poruke. Zašto emailovi prikazuju krivi datum nakon migracije ovaj mehanizam objašnjava detaljno.

Izvorno Date: zaglavlje netaknuto je u svakoj poruci. DKIM potpisi su netaknuti. Sadržaj se nije pomicao. Jedino što je pogrešno jest INTERNALDATE vrijednost na strani servera.

Ovaj problem pogađa BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO i sve alate koji koriste IMAP APPEND bez ispravnog čuvanja INTERNALDATE vrijednosti. Članak posvećen BitTitan MigrationWizu pokriva posebnosti tog alata. Kontrolni popis za migraciju emailova navodi točke koje treba provjeriti prije i nakon migracije kako bi se izbjegla ovakva vrsta problema.

Razlika između ispravka i krivotvorenja

Ispravak koji Redate.io izvodi suprotan je pokušaju krivotvorenja. Vlasnički motor za ispravak analizira lanac zaglavlja svake poruke, identificira izvoran datum kodiran u Date: zaglavlju (RFC 2822) koje se nikad nije promijenilo, i ispravlja metapodatke datuma kako bi ih uskladio s tom autentičnom informacijom koja je već prisutna u poruci.

Zaglavlje Date: je izvor istine. Upisao ga je klijent pošiljatelja u trenutku slanja. Pokriveno je DKIM potpisom. Redate.io ga ne mijenja. Ono što se ispravlja jest nesklad koji je uveo alat za migraciju, a ne izvoran datum.

Ispraviti 47.000 emailova nakon neuspjele migracije bez gubitka ijednog, bez lomljenja niti razgovora, bez oštećivanja privitaka, bez okidanja greške 429 u 3 ujutro na Google API-ju: to je višefazni pipeline za analizu s upravljanjem rubnim slučajevima (S/MIME, PGP, non-ASCII kodiranja prema RFC 2047, složene multipart strukture). Python skripta od pet redaka ne bi preživjela prvi produkcijski sandučić. Mogu li se datumi emailova ispraviti nakon migracije detaljno objašnjava zašto je DIY pristup riskantan na stvarnim volumenima.

Redate.io besplatno skenira sandučiće, identificira emailove s pogrešnim datumima i ispravlja ih putem validacijskog pipelinea koji svaku poruku provjerava pojedinačno. Originali se čuvaju u vidljivoj sigurnosnoj kopiji 30 dana. Ako nešto krene po zlu, povrat je moguć.

Vaša migracija je pomaknula datume Vaših emailova? Pokrenite besplatno skeniranje na Redate.io i izmjerite opseg problema prije nego što odlučite što učiniti.