Sähköpostin päivämäärän väärentäminen: mahdollista ja havaittavissa

Sähköpostin päivämäärän muuttaminen: mistä oikein on kyse?

Kysymys nousee toistuvasti järjestelmäadminien foorumeilla ja MSP-yhteisöjen Slack-ryhmissä: voiko sähköpostin päivämäärää muuttaa lähetyksen jälkeen? Lyhyt vastaus on kyllä, teknisesti. Mutta täysi vastaus on huomattavasti vähemmän rohkaiseva sille, joka aikoo tehdä sen epärehellisiin tarkoituksiin.

Sähköposti ei ole monoliittinen tiedosto. Se on kokoelma tekstipohjaisia otsikkokenttiä (headers), joita seuraa viestin runko. Näistä otsikoista useat sisältävät päivämäärätietoja. Ja jotkut niistä on helpompi muuttaa kuin toiset.

Jokaisessa sähköpostissa on kolme päivämääräkerrosta:

• Otsikko Date: (RFC 2822), jonka sähköpostiohjelma kirjoittaa lähetyshetkellä
• Otsikot Received:, jotka jokainen viestia välittävä palvelin lisää
• IMAP INTERNALDATE, palvelinpuolen metatietoja joka on riippumaton viestin sisällöstä

Jokainen näistä kerroksista on muokattavissa. Yksikään ei ole muokattavissa ilman jälkiä.

Date-otsikon muuttaminen: ilmeisin manipulointikeino

Otsikko Date: on pelkkää tekstiä .eml-tiedostossa. Teknisesti mikä tahansa heksaeditori tai Python-skripti voi kirjoittaa sen uudelleen muutamassa sekunnissa. Jos olet koskaan avannut sähköpostin raakaotsikoita Gmailissa (pieni valikko "Näytä alkuperäinen"), tiedät että se on kaikkien luettavissa.

Ongelma? Vuodesta 2004 lähtien suurin osa postipalvelimista allekirjoittaa lähtevät viestit DKIM:llä (DomainKeys Identified Mail). Tämä kryptografinen allekirjoitus kattaa nimenomaisesti useita otsikkoja, kuten Date:, From:, Subject: ja viestin rungon. Allekirjoitus tallennetaan otsikkoon DKIM-Signature:.

Otsikon Date: muuttaminen allekirjoituksen jälkeen mitätöi DKIM-tarkistuksen automaattisesti. Mikä tahansa vastaanottava palvelin voi tarkistaa allekirjoituksen hakemalla julkisen avaimen lähettäjädomainin DNS-tietueista. Jos allekirjoitus ei enää täsmää, viesti merkitään muutetuksi. Gmail, Outlook.com ja kaikki suuret sähköpostipalveluntarjoajat tekevät tämän tarkistuksen automaattisesti.

(Muuten, jos haluat nähdä konkreettisesti DKIM-allekirjoituksen, avaa Gmailista tai Office 365:stä vastaanotetun viestin raakaotsikoita: löydät rivin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... joka näyttää kohinalta mutta on oikeasti koko viestin kryptografinen tiiviste.)

Tulos: DKIM-allekirjoitetun sähköpostin Date:-otsikon muuttaminen rikkoo sinetin. Muutos on jokaisen etsivän IT-admininstrator havaittavissa.

Received-otsikoiden väärentäminen: ketju jota on vaikea väärentää

Otsikot Received: seuraavat sähköpostin kulkemaa reittiä lähettäjältä vastaanottajalle. Jokainen SMTP-palvelin joka käsittelee viestiä lisää oman merkintänsä: palvelimen nimen, IP-osoitteen ja aikaleiman. Kahden tai kolmen välityspalvelimen kautta kulkevassa sähköpostissa on siis kaksi tai kolme päällekkäistä Received:-otsikkoa.

Voiko niitä muuttaa? Teknisesti kyllä, omasta viestin kopiosta. Mutta tässä on ansa: vastaanottajalla on myös oma kopio. Ja hänen palvelimensa lisäsi oman Received:-otsikkonsa viimeiseksi. Tämä otsikko on vastaanottajan hallinnassa, ei lähettäjän. Sitä on mahdoton väärentää ulkopuolelta.

Ketjun johdonmukaisuus on tarkistettavissa. Jos peräkkäisten Received:-otsikoiden aikaleimät ovat ristiriitaisia (esimerkiksi välityspalvelin olisi vastaanottanut viestin ennen kuin lähettäjä lähetti sen), se on välittömästi epäilyttävää. Forensiset sähköpostianalyysityökalut kuten MXToolbox tai tietoturvatiimien sisäiset työkalut tarkistavat juuri tätä.

Tarkasti ottaen ei ole aivan oikein sanoa, että Received:-otsikoita on mahdoton väärentää kokonaan: hyökkääjä joka hallitsee omaa sähköpostiinfrastruktuuriaan voi luoda uskottavat otsikot hallitsemilleen välityspalvelimille. Mutta viimeistä lenkkiä hän ei koskaan hallitse: vastaanottajan palvelinta.

IMAP INTERNALDATE: teknisesti vaativin tapaus

INTERNALDATE on IMAP-palvelimen tallentama metatietoarvo. Se ei ole otsikko itse viestissä: se on arvo, jonka palvelin yhdistää viestiin omassa sisäisessä tietokannassaan. Useimmat sähköpostiohjelmat käyttävät tätä arvoa viestien lajitteluun saapuneet-kansiossa.

IMAP-komento APPEND mahdollistaa viestin tallentamisen palvelimelle määrittämällä INTERNALDATE eksplisiittisesti. Tämä on protokollan laillinen ominaisuus, dokumentoitu RFC 3501:ssä. Migraatiotyökalut käyttävät sitä jatkuvasti: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... kaikki tallentavat sähköpostit kohdepalvelimelle määritetyllä INTERNALDATE-arvolla.

Teoriassa jollakin, jolla on IMAP-pääsy omaan postilaatikkoonsa, voisi tallentaa viestin millä tahansa INTERNALDATE-arvolla. Mutta tämä manipulointi ei muuta viestin otsikoita. Alkuperäinen Date: pysyy koskemattomana, Received:-otsikot pysyvät koskemattomina, DKIM-allekirjoitus pysyy koskemattomana. Vain palvelinpuolen lajittelumetatietoarvo muuttuu.

Asiantuntijalle joka tutkii raakaviestia, ristiriita INTERNALDATE:n ja Date:-otsikon välillä on välittömästi nähtävissä. Ja jos viesti on DKIM-allekirjoitettu, alkuperäinen päivämäärä on kryptografisesti todistettu.

Message-ID: vaikeasti väärentettävä sormenjälki

Jokainen sähköposti saa yksilöllisen tunnisteen, otsikon Message-ID:. Lähettävä SMTP-palvelin rakentaa tämän tunnisteen lähetyshetkellä yhdistämällä tyypillisesti aikaleiman, satunnaisen tunnisteen ja palvelimen verkkotunnuksen.

Tyypillinen Message-ID näyttää tältä: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Aikaleima on usein koodattu suoraan tunnisteeseen. Viestin päivämäärän muuttaminen jättäen Message-ID:hen yhteensopimaton aikaleima luo välittömästi havaittavan epäjohdonmukaisuuden.

Lisäksi suuret viestintäjärjestelmät indeksoivat Message-ID:t. Google, Microsoft ja muut toimijat ylläpitävät lokeja joiden avulla voidaan jäljittää milloin viesti on todellisuudessa liikkunut heidän infrastruktuurissaan. Oikeudellisessa tai forensisessa asiayhteydessä nämä lokit ovat saatavilla oikeudellisten menettelyjen kautta.

Käytännössä: kuka voi havaita manipulointiyrityksen?

Asetetaan kysymys konkreettisesti. Saat sähköpostin jonka päivämäärää epäilet muutetun. Mitä IT-admin tai vähänkään teknistä taustaa omaava lakimies voi tehdä?

• DKIM-tarkistus: Gmailissa "Näytä alkuperäinen" -valikko näyttää suoraan DKIM-tarkistuksen tuloksen sivun yläosassa. "PASS" vahvistaa viestin eheyden lähetyksestä alkaen. "FAIL" tai "SOFTFAIL" viittaa muokkaukseen.
• Otsikoiden analyysi: Työkalut kuten MXToolbox Header Analyzer tai Google Admin Toolbox jäsentävät automaattisesti Received:-ketjun ja merkitsevät ajalliset epäjohdonmukaisuudet.
• Message-ID:n ja Date:n johdonmukaisuus: Analyytikko voi verrata Message-ID:hen koodattua aikaleimaa ilmoitetun Date:-otsikon arvoon.
• Palvelinlokit: Jos sähköposti on kulkenut palvelimen kautta jonka admin olet, SMTP-lokit sisältävät viestin todellisen vastaanotto-päivämäärän ja -kellonajan, riippumatta mistään otsikosta.

Lyhyesti sanottuna, havaintotyökalut ovat saatavilla, ilmaisia, eivätkä vaadi edistynyttä forensista asiantuntemusta. Hieman utelias IT-admin voi tarkistaa sähköpostin eheyden alle kahdessa minuutissa.

Ainoa laillinen joukkomuokkauksen tapaus: IMAP-migraatio

On olemassa skenaario jossa sadat tuhannet sähköpostit päätyvät vääriin päivämääriin ilman mitään pahantahtoista aikomusta: IMAP-migraatio.

Olet juuri saanut valmiiksi 150 Exchange-postilaatikon migraation Google Workspaceen. Maanantaiaamuna tikettejä alkaa tulla. Käyttäjät ilmoittavat, että kaikki vanhat sähköpostit näyttävät saman päivämäärän, migraatioviikonlopun päivämäärän. Heidän saapuneet-kansionsa ovat käyttökelvottomia.

Tapahtunut on dokumentoitu ja ennakoitavissa: migraatiotyökalu (BitTitan, CloudM, imapsync, mikä tahansa) tallensi sähköpostit Google Workspaceen IMAP APPEND -komennolla. Se määritti INTERNALDATE-arvoksi migraatiopäivämäärän eikä sähköpostin alkuperäistä päivämäärää. Tulos: Outlook, joka lajittelee oletuksena INTERNALDATE:n mukaan, näyttää kaikille viesteille migraatiopäivämäärän. Miksi sähköpostit näyttävät väärän päivän migraation jälkeen selittää tämän mekanismin yksityiskohtaisesti.

Alkuperäinen Date:-otsikko on koskemattomana jokaisessa viestissä. DKIM-allekirjoitukset ovat koskemattomia. Sisältöä ei ole muutettu. Ainoastaan palvelinpuolen INTERNALDATE on väärä.

Tämä ongelma koskee BitTitan MigrationWiziä, CloudM Migratea, imapsynciä, GSMMOta ja kaikkia työkaluja jotka käyttävät IMAP APPEND -komentoa tallentamatta INTERNALDATE-arvoa oikein. BitTitan MigrationWizille omistettu artikkeli kattaa tämän työkalun erityispiirteet. Sähköpostimigraation tarkistuslista luettelee asiat joita kannattaa tarkistaa ennen migraatiota ja sen jälkeen tämäntyyppisten ongelmien välttämiseksi.

Korjaamisen ja väärentämisen ero

Redate.io:n suorittama korjaus on täysin päinvastainen kuin väärennysyritys. Omistusoikeudellinen korjausmoottori analysoi jokaisen viestin otsikkoketjun, tunnistaa alkuperäisen päivämäärän Date:-otsikosta (RFC 2822) joka ei ole koskaan muuttunut, ja korjaa päivämäärämetatiedot vastaamaan tätä aitoa, viestissä jo olevaa tietoa.

Otsikko Date: on totuuden lähde. Lähettäjän sähköpostiohjelma kirjoitti sen lähetyshetkellä. DKIM-allekirjoitus kattaa sen. Redate.io ei muuta sitä. Se mitä korjataan, on migraatiotyökalun aiheuttama ristiriita, ei alkuperäinen päivämäärä.

47 000 sähköpostin korjaaminen epäonnistuneen migraation jälkeen menettämättä yhtäkään, rikkomatta viestiketjuja, turmelematta liitteitä, aiheuttamatta 429-virhettä kello 3 aamulla Google-rajapinnassa: se vaatii monivaiheisen analyysiputkiston reunatapausten hallinnalla (S/MIME, PGP, ei-ASCII-koodaukset RFC 2047:n mukaan, monimutkaiset multipart-rakenteet). Viiden rivin Python-skripti ei selviä ensimmäisestä tuotantopostilaatikosta. Voidaanko päivämäärät korjata migraation jälkeen kertoo yksityiskohtaisesti miksi itse tekeminen on riskialtista todellisilla volyymeilla.

Redate.io skannaa postilaatikot ilmaiseksi, tunnistaa väärillä päivämäärillä olevat sähköpostit, ja korjaa ne validointiputkistolla joka tarkistaa jokaisen viestin yksitellen. Alkuperäiset viestit säilytetään näkyvässä varmuuskopiointikansiossa 30 päivän ajan. Jos jokin menee pieleen, palautus on mahdollinen.

Migraatio siirsi sähköpostiesi päivämäärät väärään? Käynnistä ilmainen skannaus Redate.io:ssa ongelman laajuuden selvittämiseksi ennen kuin päätät mitä tehdä.