On vuosi 2020 – 38 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, sillä 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öönottovaiheessa Sender Policy Framework -sääntöä tehdessään säännöksi ~all (SoftFail), joka ei tuo tarpeeksi suojaa. Yleisin syy tähän valintaan on tiedottomuus siitä, 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ä, eikä sähköpostijärjestelmään muutoin ole tehty sääntöjä oman verkkotunnuksen sähköpostiliikenteen suojaamiseksi, voi lopputuloksena olla sähköpostihuijaus.  Esimerkiksi paljon puhutussa toimitusjohtajahuijauksessa lähetetään yrityksen kotisivuilta löytyvälle taloushallinnon henkilölle yrityksen toimitusjohtajan nimissä sähköpostia, jossa yleensä pyydetään jonkun kiireellisen laskun maksamista. Sähköpostihuijaus on joissain tapauksissa naurettavan helppo tehdä – varsinkin, jos kohde organisaatio ei ole suojannut omia järjestelmiään tarpeeksi hyvin.

Alla hyvä 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ä:

Sähköpostihuijaus2

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 jää helposti huomaamatta, että vastauksen kohdeosoite on eri kuin 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.

sähköpostihuijaus1

Hyökkäystä voi tehdä vielä vakuuttavamman näköisesti monella tavalla, esimerkiksi kysymällä yrityksen myynniltä tuotekatalogia ja kopioimalla vastausviesteistä mahdollisesti löytyvän 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ällöin 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. Se sisältää kaikki modernit suojaustekniikat. Sillä voidaan myös salata ulospäin lähetettävät sähköpostit vahvalla salauksella.

Parhaiten sähköpostin turvallisuudesta voi huolehtia sopivan IT-kumppanin avulla.

Katso myös webinaarimme aiheesta:

Latest posts by Ville Hirvonen (see all)

Kaipaatko lisätietoa aiheesta? Ota yhteyttä!