Antidatiranje emaila: moguće i detektabilno

Antidatiranje emaila: o čemu se zapravo radi?

Pitanje se redovno pojavljuje na forumima za sistemske administratore i u Slack grupama MSP-ova: da li je moguće izmeniti datum emaila nakon slanja? Kratak odgovor je da, tehnički. Ali potpun odgovor je mnogo manje ohrabrujući za svakoga ko bi to pokušao iz sumnjivnih razloga.

Email nije monolitna datoteka. To je kolekcija tekstualnih zaglavlja praćena telom poruke. Među tim zaglavljima, nekoliko nosi informacije o datumu. I neka su lakša za izmenu od drugih.

Tri sloja datiranja postoje u svakom emailu:

• Zaglavlje Date: (RFC 2822), koje piše email klijent u trenutku slanja
• Zaglavlja Received:, koja dodaje svaki server koji prosleđuje poruku
• IMAP INTERNALDATE, metapodatak koji se čuva na serveru, nezavisan od sadržaja poruke

Svaki od ovih slojeva se može izmeniti. Nijedan ne može biti izmenjen bez ostavljanja tragova.

Menjanje zaglavlja Date: : najočigljivija manipulacija

Zaglavlje Date: je običan tekst u .eml fajlu. 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 meni "Prikaži original"), znate da je to čitljivo svakome.

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

Menjanje Date: zaglavlja nakon potpisivanja mehanički poništava DKIM verifikaciju. Bilo koji server primalac može da proveri potpis preuzimanjem javnog ključa iz DNS-a domena pošiljaoca. Ako potpis više ne odgovara, poruka se označava kao izmenjena. Gmail, Outlook.com i svi veliki provajderi ovu proveru rade automatski.

(Inače, ako želite da vidite konkretno kako izgleda DKIM potpis, otvorite sirova zaglavlja bilo kog emaila primljenog od Gmaila ili Office 365: naći ćete liniju DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... koja izgleda kao šum ali je zapravo kriptografski heš cele poruke.)

Rezultat: menjanje Date: zaglavlja na DKIM-potpisanom emailu je kao lomljenje pečata. Izmena je vidljiva svakom administratoru koji zna gde da traži.

Prepisivanje Received: zaglavlja: lanac koji je teško falsifikovati

Zaglavlja Received: prate put koji je email prešao između pošiljaoca i primaoca. Svaki SMTP server koji dodirne poruku dodaje jedno, sa svojim imenom, IP adresom i vremenskim pečatom. Email koji prode kroz dva ili tri releja sadrži dva ili tri Received: zaglavlja složena jedno na drugo.

Da li se mogu izmeniti? Tehnički, da, na sopstvenoj kopiji poruke. Ali evo zamke: primalac takođe ima kopiju. I njegov server je dodao sopstveno Received: zaglavlje kao poslednje. To zaglavlje je pod kontrolom primaoca, ne pošiljaoca. Nemoguće ga je falsifikovati spolja.

Konzistentnost lanca je proverljiva. Ako su vremenski pečati uzastopnih Received: zaglavlja nekonzistentni (recimo, posredni relej je primio poruku pre nego što je pošiljalac uopšte poslao), to je odmah sumnjivo. Alati za forenzičku analizu emaila kao što su MXToolbox ili interni alati bezbednosnih timova proveravaju upravo to.

Zapravo, nije sasvim tačno reći da su Received: zaglavlja potpuno nefalsifikovana: napadač koji kontroliše sopstvenu mail infrastrukturu može da napravi uverljiva zaglavlja za releje koje on kontroliše. Ali nikada ne kontroliše poslednju kariku: server primaoca.

IMAP INTERNALDATE: najtehničkiji slučaj

INTERNALDATE je IMAP metapodatak koji se čuva na serveru. Nije zaglavlje u samoj poruci: to je vrednost koju server asocira sa porukom u svojoj internoj bazi podataka. Ta vrednost je ono što većina email klijenata koristi za sortiranje poruka u sandučetu.

IMAP komanda APPEND omogućava deponovanje poruke na server uz eksplicitno navođenje INTERNALDATE vrednosti. Ovo je legitimna funkcionalnost protokola, dokumentovana u RFC 3501. Alati za migraciju je stalno koriste: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... svi deponuju emailove na odredišni server sa navedenom INTERNALDATE vrednošću.

Teoretski, neko sa IMAP pristupom sopstvenom sandučetu mogao bi da deponuje email sa bilo kojom INTERNALDATE vrednosti. Ali ova manipulacija ne menja zaglavlja poruke. Originalni Date: ostaje netaknut, Received: zaglavlja ostaju netaknuta, DKIM potpis ostaje netaknut. Menja se samo metapodatak za sortiranje na strani servera.

Za stručnjaka koji ispituje sirovu poruku, neslaganje između INTERNALDATE i Date: vrednosti je odmah vidljivo. A ako je poruka potpisana DKIM-om, originalni datum je kriptografski potvrđen.

Message-ID: otisak prsta koji je teško falsifikovati

Svaki email generiše jedinstveni identifikator, zaglavlje Message-ID:. Ovaj identifikator konstruiše SMTP server pošiljaoca u trenutku slanja, kombinujući obično vremenski pečat, nasumični identifikator i ime domena servera.

Tipičan Message-ID izgleda ovako: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Vremenski pečat je često direktno enkodiran u identifikatoru. Menjanje datuma poruke uz ostavljanje Message-ID-a sa nekompatibilnim vremenskim pečatom stvara nekonzistentnost koja se odmah primeti.

Pored toga, Message-ID vrednosti su indeksirane od strane velikih sistema za razmenu poruka. Google, Microsoft i drugi akteri čuvaju logove koji omogućavaju praćenje kada je poruka zaista cirkulisala kroz njihovu infrastrukturu. U pravnom ili forenzičkom kontekstu, ovi logovi su dostupni putem sudskih procedura.

U praksi: ko može da detektuje pokušaj manipulacije?

Postavimo pitanje konkretno. Primili ste email za koji sumnjate da mu je datum izmenjen. Šta može da uradi IT administrator ili advokat sa minimalnim tehničkim znanjem?

• DKIM verifikacija: u Gmailu, meni "Prikaži original" direktno prikazuje rezultat DKIM verifikacije na vrhu stranice. "PASS" potvrđuje integritet poruke od trenutka slanja. "FAIL" ili "SOFTFAIL" signalizira izmenu.
• Analiza zaglavlja: alati kao što su MXToolbox Header Analyzer ili Google Admin Toolbox automatski parsuju lanac Received: zaglavlja i ukazuju na vremenske nekonzistentnosti.
• Konzistentnost Message-ID / Date: analitičar može da uporedi vremenski pečat enkodiran u Message-ID-u sa vrednošću deklarisanog Date: zaglavlja.
• Logovi servera: ako je email prošao kroz server čiji ste administrator, SMTP logovi sadrže stvarni datum i vreme prihvatanja poruke, nezavisno od bilo kog zaglavlja.

Ukratko, alati za detekciju su dostupni, besplatni i ne zahtevaju naprednu forenzičku stručnost. Malo radoznali IT admin može da proveri integritet emaila za manje od dva minuta.

Jedini legitiman slučaj masovne izmene datuma: IMAP migracija

Postoji jedan scenario u kome se stotine hiljada emailova nađe sa pogrešnim datumima bez ikakve zlonamerne namere: IMAP migracija.

Upravo ste završili migraciju 150 Exchange sandučeta na Google Workspace. Ponedeljak ujutru, tiketi počinju da pristižu. Korisnici javljaju da se svi njihovi stari emailovi prikazuju sa istim datumom, datumom vikenda migracije. Njihova sandučeta su nečitljiva.

Ono što se desilo je dokumentovano i predvidljivo: alat za migraciju (BitTitan, CloudM, imapsync, svejedno) deponovao je emailove na Google Workspace putem IMAP APPEND komande. Naveo je INTERNALDATE vrednost koja odgovara datumu migracije, a ne originalnom datumu emaila. Rezultat: Outlook, koji po podrazumevanoj vrednosti sortira po INTERNALDATE, prikazuje datum migracije za sve poruke. Članak Zašto emailovi prikazuju pogrešan datum posle migracije objašnjava ovaj mehanizam u detalje.

Originalno Date: zaglavlje je netaknuto u svakoj poruci. DKIM potpisi su netaknuti. Sadržaj se nije pomerio. Jedino što je pogrešno je INTERNALDATE vrednost na strani servera.

Ovaj problem pogađa BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO i sve alate koji koriste IMAP APPEND bez pravilnog čuvanja INTERNALDATE vrednosti. Članak posvećen BitTitan MigrationWiz-u pokriva specifičnosti tog alata. Kontrolna lista migracije emaila navodi tačke koje treba proveriti pre i posle migracije da bi se izbegao ovakav problem.

Razlika između ispravke i falsifikovanja

Ispravka koju Redate.io vrši suprotna je pokušaju falsifikovanja. Vlasnički mehanizam za ispravku analizira lanac zaglavlja svake poruke, identifikuje originalni datum enkodiran u Date: zaglavlju (RFC 2822) koji se nikada nije pomerio, i koriguje metapodatke datuma kako bi ih uskladio sa tom autentičnom informacijom koja je već prisutna u poruci.

Zaglavlje Date: je izvor istine. Napisao ga je email klijent pošiljaoca u trenutku slanja. Pokriveno je DKIM potpisom. Redate.io ga ne menja. Ono što se ispravlja je neslaganje koje je uveo alat za migraciju, a ne originalni datum.

Ispraviti 47.000 emailova posle neuspele migracije bez gubitka ijednog, bez kvarenja niti konverzacija, bez oštećenja priloga, bez izazivanja 429 greške u 3 ujutru na Google API-ju: to je višefazni analitički pipeline sa upravljanjem rubnim slučajevima (S/MIME, PGP, non-ASCII enkodiranja po RFC 2047, složene multipart strukture). Python skripta od pet linija ne bi preživela prvo produkcijsko sanduče. Da li se datumi emailova mogu ispraviti posle migracije detaljno objašnjava zašto je DIY pristup rizičan na realnim volumenima.

Redate.io skenira sandučeta besplatno, identifikuje emailove sa pogrešnim datumima i ispravlja ih putem pipeline-a za validaciju koji proverava svaku poruku pojedinačno. Originali se čuvaju u vidljivom backup folderu 30 dana. Ako nešto krene naopako, povratak na prethodno stanje je moguć.

Vaša migracija je pomerila datume Vaših emailova? Pokrenite besplatno skeniranje na Redate.io da biste izmerili obim problema pre nego što odlučite šta da preduzmete.