On vuosi 2018 – 36 vuotta sitten alkujaan kehitetty SMTP -protokolla on edelleen käytössä sähköpostin siirtämiseksi. Vaikka nykypäivänä SMTP:n ympärille on kehitetty liuta tekniikoita, joilla sen väärinkäyttöä voidaan vähentää, on monella ylläpitäjällä vielä parantamisen varaa asiassa. Osana ongelmaa on, että tekniikoita ei oteta käyttöön epätietoisuuden tai käyttöönoton hankaluuden takia.
Moni on huomannut, että esimerkiksi Microsoft Exchange On-Premises -ympäristöä ei voi enää pitää tuotannossa ilman, että eteen asennetaan jokin 3. osapuolen sähköpostin suodatuspalvelu. Ilman erillistä suodatusta roskapostin määrä nousee jossain vaiheessa sietämättömäksi.
Myös Office 365 -palvelua käytettäessä moni ylläpitäjä valitsee käyttöönotto vaiheessa Sender Policy Framework sääntöä tehdessä säännöksi ~all (SoftFail), joka ei tuo tarpeeksi suojaa. Yleisin syy tähän valintaan on tiedottomuus siitä, että mistä kaikista sijainneista tai palveluista organisaation sähköpostia oikeasti lähetetään.
Jos SPF, DKIM ja DMARC -tekniikat eivät ole käytössä ja omaan sähköpostijärjestelmään ei muutoin ole tehty sääntöjä oman verkkotunnuksen sähköpostiliikenteen suojaamiseksi, voi kokoonpano hyvin mahdollistaa esimerkiksi paljon puhutun ’Toimitusjohtajahuijauksen’.
’Toimitusjohtajahuijauksessa’ lähetetään esimerkiksi yrityksen kotisivuilta löytyvälle taloushallinnon henkilölle yrityksen toimitusjohtajan nimissä sähköpostia, jossa yleensä pyydetään jonkun kiireellisen laskun maksamista. Vastaavan huijausviestin lähettäminen on joissain tapauksissa naurettavan helppoa. Etenkin, jos kohdeorganisaatio ei ole suojannut omia järjestelmiään tarpeeksi hyvin.
Alla hyvä ja yksinkertainen esimerkki:
telnet jokuyritys-fi.mail.protection.outlook.com 25
HELO mail.jokuyritys.fi
MAIL FROM: <maija.meikalainen@jokuyritys.fi>
RCPT TO: <matti.meikalainen@jokuyritys.fi>
DATA
From: Maija Meikäläinen <maija.meikalainen@jokuyritys.fi>
To: Matti Meikäläinen <matti.meikalainen@jokuyritys.fi>
Reply-To: maija.meikalainen@jokuyritys.com
Subject: Markkinointikumppanin lasku
X-Priority: 2
Mime-Version: 1.0;
Content-Type: text/html; charset="ISO-8859-1";
Content-Transfer-Encoding: 7bit;
<html>
<body>
Hei,
<br><br>
Oheessa kumppanimme laskun tiedot, unohdin toimittaa tämän laskun aikaisemmin,
<br>
joten voitko käsitellä sen samantien:
<br><br>
Marketing Company X LTD
<br><br>
South Street 1 B<br>
London<br>
WC1E 7HX<br><br>
IBAN: GB42 5000 1510 0000 23<br>
BIC: WSATGBAV<br>
REFERENCE: A10289927123
<br>
SUM: 7590,00 EUR
<br><br>
Maija Meikäläinen,
<br>
Toimitusjohtaja
</body>
</html>
.
QUIT
(Jos tätä haluaa testata omassa ympäristössä, kannattaa käyttää PuTTY -ohjelmaa telnet-yhteyteen ja vaihtaa yhteyden translation tilaan: ISO-8859-1, muutoin viesti ei mene läpi ihan vaan merkistöongelmien takia).
Yllä mainittu teksti muodostaa seuraavan sähköpostiviestin vastaanottajalle, jos suojaukset eivät ole käytössä:
Tässä kyseisessä esimerkissä alkuperäiseen viestiin oli määritetty "Reply-To:" -kenttä, jolloin hyökkääjä voi valita vastauksen kohteeksi jonkin oman osoitteensa. Esimerkissä hyökkääjä on luonut jokuyritys.fi -verkkotunnusta hyvin paljon muistuttuvan jokuyritys.com -verkkotunnuksen luomaan lisävaikutetta sähköpostin aitoudesta.
Vastatessa sähköpostiin on hyvin helppo olla huomaamatta, että vastauksen kohdeosoite on eri kun se oli saapuvassa viestissä. Pahimmassa tapauksessa hyökkäyksen uhri käy vuorovaikutteisen keskustelun hyökkääjän kanssa ja suostuu tämän kautta maksamaan laskun, tai kuten esimerkissä, ei kyseenalaista pyyntöä ollenkaan, koska se näyttää tulevan luotetulta taholta.
Hyökkäystä voi tehdä vielä vakuuttavamman näköisesti monella tavalla, kuten esimerkiksi kysymällä yrityksen myynniltä tuotekatalogia ja kopioimalla vastausviesteistä yrityksen sähköpostin allekirjoituspohjan huijausviestiin.
No miten tältä kaikelta voi suojautua?
Prioriteettina tulisi olla, että oman sähköpostipalvelimen asetukset ovat kunnossa, sekä SPF, DKIM ja DMARC määritettynä jokaiselle organisaation sähköpostia kuljettavalle verkkotunnukselle. Huomaa myös, että ei ole huono idea määrittää DMARC käyttöön kaikille verkkotunnuksille vaikka niitä ei käytettäisi sähköpostiliikenteeseen. Täten niitä ei voida käyttää hyväksi roskapostin tai huijausviestien lähetykseen.
Lisäksi on erittäin suositeltavaa, että oman sähköpostipalvelimen tai -palvelun edessä on jokin erillinen sähköpostiliikennettä suojaava tuote, kuten esimerkiksi Cisco Email Security. Cisco Email Security sisältää kaikki modernit suojaustekniikat ja sillä voidaan myös salata ulospäin lähetettävät sähköpostit vahvalla salauksella.
Jos sähköpostin tekniikkaan liittyvät lyhenteet kuulostavat vierailta tai vaikeilta, löytyy meiltä ratkaisu sähköpostin kokonaistietoturvan takaamiseksi.
Me mielellämme opastamme teitä tietoturvaan liittyvissä asioissa, sillä Me BLC Taidolla uskomme maailmaan, jossa tietotyö on helppoa ja työskentely hauskaa sekä turvallista, ota yhteyttä.
PS. Tutustu myös Tietoturvaoppaaseemme.
